The Brief Was Wrong

The client brief was clear: build a portal for Applied Behavioral Analysis practitioners. Map the workflows. Design the interface. Make it easier for clinicians to manage their caseloads.

We did that work. But somewhere in the research, something shifted.

When you map a service journey across multiple stakeholder types — guardians, administrators, clinicians, technicians, caregivers — patterns emerge that no brief anticipates. In this case, the pattern was unmistakable: caregivers were doing an enormous amount of coordination work. Scheduling. Insurance navigation. Treatment plans. Session prep. Homework. And almost none of the existing tooling was built for them.

The practitioner portal was real and necessary. But it wasn’t the whole story.

Why briefs are hypotheses, not requirements

Clients come in with a problem they’ve already framed. Sometimes the framing is right. More often it’s partially right — accurate about the surface, incomplete about the system.

The brief is a starting point. It tells you where the client is feeling the pain. It doesn’t always tell you where the pain originates.

Good product research doesn’t just answer the question in the brief. It asks whether the question is the right one. Service blueprints, stakeholder swim lanes, and cross-role journey mapping aren’t just documentation artifacts — they’re tools for surfacing what you didn’t know to ask.

What changed

The reframe didn’t invalidate the original brief. We still designed for practitioners. But the caregiver insight changed the product direction in meaningful ways — what information surfaced where, how notifications were structured, what workflows got prioritized in the first release.

That’s usually how it goes. You don’t throw out the brief. You hold it more loosely while you do the work to understand the actual system you’re designing for. The best product decisions come from teams that treat the brief as a hypothesis worth testing — not a contract that closes off inquiry.