They Built Exactly What You Asked For

Last month, a therapy EMR company reached out. 20-year-old platform serving 1000+ practices. Therapists hated parts of it but stuck with it because switching costs.

They'd done everything right:

• Interviewed 30 therapists about pain points
• Built exactly what therapists requested
• Beta tested with the same therapists
• Got positive feedback

Launch: 18% of therapists used new features regularly.

The CEO asked: "We built what they told us they needed. Why aren't they using it?"

The U in UX is more crucial than one would think. Discovery has to be strategic. Here is what I did. I spent a week watching therapists actually work. Not asking what they need. Watching what they actually do.

What they said they needed: "Better templates for session notes. Easier billing."

What they actually needed: A way to document 8 therapy sessions at the end of the day when they're exhausted and can barely remember which client said what.

The templates were beautiful. Exactly what they asked for. And completely unusable for batch-documenting 8 sessions at 7pm when you're fried.

When you ask a physician "What would make your workflow better?", they answer based on:

1. 1.What they think is possible
2. 2.What sounds professional
3. 3.What they remember consciously

What they can't tell you:

• The workarounds they've developed that they don't even notice
• The context they access through muscle memory
• The cognitive shortcuts their brain takes
• The things that only matter at 2am on hour 14

You can't build good clinical software from interviews alone. You have to watch them work. Discover their latent needs.

Disconnect #1: Stated Needs vs. Actual Workflow

What they say: "I need better search functionality"

What they actually do: Navigate by visual memory. "That patient is usually third in the list when I filter by..."

Improving search doesn't help because that's not how they actually find things.

Disconnect #2: Ideal Workflow vs. Reality

What sounds professional: "Document each patient immediately after session"

What actually happens: Batch-document 8 patients at 7pm while trying to remember who said what.

Software designed for real-time documentation fails when used for batch documentation.

Disconnect #3: Professional vs. Practical

What they ask for: "Comprehensive assessment tools"

What they actually use: Whatever is fastest.

The comprehensive tool gets abandoned for sticky notes because sticky notes are faster under pressure.

Back to that therapy platform.

We watched 15 therapists for a full week. In their actual practices. During actual chaos.

Discovery: Therapists don't think about "patients" the way the software organized information.

They think: "I have 8 sessions today. What do I need for my 2pm? What happened in their last session?"

The system was organized by patient records. (Makes sense if you're building a database.)

But therapists don't open it thinking "let me look up John Smith's record." They open it thinking "what do I need for my 2pm session?"

Completely different mental model.

We redesigned the information architecture around sessions, not patients. Same data. Different organization.

Result: Therapists completed daily workflow 40% faster because the software matched how their brain already worked.

They didn't ask for "session-centric design." They would never have known to ask for that. But once they had it, adoption jumped.

If your clinical software has low adoption, the problem is usually:

Not: "We built the wrong features." Actually: We built features for the stated workflow instead of the actual workflow.

Not: "Our UI is bad." Actually: Our information architecture doesn't match their mental model.

Not: "We need more training." Actually: The software requires behavior change instead of fitting existing behavior.

Forget the roadmap for two weeks.

Week 1: Watch 10 users actually use your product in their real environment for a full day. Don't ask questions. Just observe.

Week 2: Map the gaps between:

• What they said vs. what you saw them need
• The workflow you designed for vs. the workflow they have
• The context you optimized for vs. where they actually use it

Then decide: New features, or reorganize what you already built?

Usually it's the second one. And that's way cheaper.