Essay · November 2026
Building empathy in the terminal
AI coding tools let you go from an idea to something live without ever meeting a user. This is how dwic puts empathy back into that loop, inside the terminal: by reading your code for what it assumes about people, and questioning you without ever inventing a user.
Empathy
Understanding who you’re building for. AI can summarise what people say; it can’t tell you what matters to them.
With Claude Code you can go from an idea to something live in an afternoon, and nothing in that loop asks who it’s for. This is how I tried to put that step back inside the terminal, without letting the AI pretend to be the user.
What empathy means in product work
Not feeling for someone. Indi Young calls the useful kind cognitive empathy: understanding how another person thinks. In A New Way to Listen, she asks people to recall what went through their mind during something they did, and listens for the whys, not their opinions. Her line for the listener: “It’s her mind, and you’re the tourist.”
So empathy isn’t how sure you feel about your users. It’s how much you know about how they think, and how much of that came from them.
That’s also why AI can’t do it for you. When Nielsen Norman Group compared synthetic and real users, the synthetic answers clustered around the average and lost the unusual ones, which is often where the real problem is. And personas, AI-made or not, can’t be checked for accuracy. So dwic’s first rule: never invent a user, a quote or an interview.
How it’s meant to work, and how it actually goes
In the textbook version, you listen to people first, find the patterns, then design, then test with people again. Building with an AI tool skips all of it. You’re often the designer, researcher and developer at once, with no notes and no users yet. Who it’s for is whatever was in your head when you typed the prompt.
A loop. People come first, and come back every round.
A straight line. You asked nobody outside your head.
My first version assumed the textbook: it organised interview notes most people don’t have. What I wanted was something that helps you build empathy from wherever you are. Then I noticed everyone does have evidence of one thing: what they believe about their users. It’s in their code.
Your code already says who you think your users are
We don’t read our own code as claims about people, because we wrote it. That’s the curse of knowledge. In a Stanford study, people tapping famous songs expected listeners to name half; listeners named about 1 in 40 (Heath and Heath, HBR). Designers reading their own forms are the tappers.
<input name="phone" required />→
Everyone has a phone number, and will give it to us before seeing anything.
const STEPS = [5 steps] // all required before first invoice→
People will push through all five before they get any value.
"You entered an invalid phone number."→
When something goes wrong, it’s the user’s mistake.
Take one flow. For every required field, step, default and error message, write a sentence starting “This assumes people…”. Circle the three you’d least like to be wrong about.
That’s what /design-empathy does with you. Point it at one flow and it lists what the code assumes about people, with the file and line, then asks you about the riskiest three.
Questioning yourself without wearing yourself out
Being questioned about your assumptions is useful and tiring. Advait Sarkar warns in AI Should Challenge, Not Obey that an AI that keeps challenging you wears you out. So dwic asks three questions, each narrower than the last and each about a moment that already happened, since people are poor at predicting their own behaviour. Then it stops:
If there’s still no real person after three, it says so and records the belief as an assumption. And every question carries one line explaining why it asked, so you learn to ask it yourself.
Say how you know what you know
What would make me wince is Claude Code inventing users or quotes, calling it evidence, and recording it without anyone confirming. So dwic proposes, and you decide what gets written.
And every point is labelled by how it’s known, a habit worth stealing for any research doc:
| Label | What it means | Example |
|---|---|---|
| observed | You saw them do it. | Watched her skip the bank step on a call. |
| reported | They told you, in their own words. | “I found out a client was a month late only when I checked my bank.” |
| public | Real people, but not your users. | A competitor’s app-store review. |
| recalled | Your memory of a real moment. | “A photographer I demoed to quit at the bank step.” |
| assumed | No source yet. | “Users want it simple.” |
“Recalled” matters most. A real moment you remember is more than a guess, but nobody can check it. Without its own label, memories quietly become evidence.
The why belongs to the user
Knowing what someone did is half of it. The why decides what you build:
But as a builder you usually don’t know the why, and pushing you would only produce a guess. So dwic asks once, “Did she say why?” If not, it records why: unknown and turns it into Young’s question for the real person: what was going through your mind?
Why do this in the terminal, with dwic
You could do all of this with a notebook. In practice, few of us do. dwic helps because:
- It shows assumptions you can’t see in your own code, with the file and line.
- It asks the follow-ups you’d skip on yourself, and stops after three.
- It won’t let a guess pass as a fact, and writes nothing until you say yes.
- It works before you have users. It can search public reviews and forums for what real people say, check each quote is on its page, and label it public. That runs on your own Claude account, so it asks first.
- What you learn gets used: dwic’s copy and form commands read
.dwic/EMPATHY.md.
dwic is free as a Claude Code plugin:
/plugin marketplace add imsaif/design-with-claude /plugin install design-with-claude@design-with-claude /reload-plugins
Then run /design-with-claude:design-empathy the signup flow. If you try it, I’d like to hear where it felt wrong.
Sources
- Anthropic, AI Fluency for Builders. academy.claude.com
- Indi Young (2015), A New Way to Listen, A List Apart. alistapart.com
- Webb and Sheeran (2006), Does changing behavioral intentions engender behavior change? eprints.whiterose.ac.uk
- Nielsen Norman Group, Synthetic Users vs Human Respondents. nngroup.com
- Chapman and Milham (2006), The personas’ new clothes. quantuxbook.com
- Heath and Heath (2006), The Curse of Knowledge, Harvard Business Review. hbr.org
- Camerer, Loewenstein and Weber (1989), The curse of knowledge in economic settings. doi.org
- Advait Sarkar (2024), AI Should Challenge, Not Obey. arxiv.org