Almost every engagement starts the same way. Someone on the team says, “we need a dashboard” for the trial pipeline, for site performance, for participant recruitment. It’s a reasonable-sounding request. It’s also, almost never, the actual problem.
We call this the costume problem: a real, specific need wearing the costume of a generic solution, because “dashboard” is the shape that requests take when a team doesn’t have a design or product function to translate them properly. It’s not a failure of the person asking. It’s a gap in the pipeline between “something is wrong” and “here is what to build.”
What’s usually underneath. In our experience, a dashboard request is standing in for one of a handful of real problems:
- A decision that keeps getting made on stale or incomplete information. The need is a decision support tool, not a dashboard.
- A status update that three people manually assemble every week. The need is automation of a reporting ritual, not a dashboard.
- A coordination gap between teams who don’t trust each other’s numbers. The need is a shared source of truth, which may not need a UI at all.
- Anxiety about a process no one can see into. The need is visibility into a specific decision point, not a full analytics surface.
These four things share a family resemblance to “dashboard,” but they have almost nothing in common as builds. A decision-support tool needs to be opinionated and narrow. A shared source of truth might just need a better data pipeline and a spreadsheet. Build the wrong one and you’ll ship something technically correct that nobody opens twice.
Why this matters more in research settings. Health research teams are especially prone to the costume problem, for a good reason: the people closest to the pain are scientists, not product people, and they’ve learned to describe problems in terms of the artifact they’ve seen work elsewhere. “The pharma company we partner with has a dashboard” becomes the reference point, even when the underlying need is completely different.
What we do instead. Before we accept the word “dashboard” as a brief, we ask three questions:
- What decision does this change, and who makes it?
- What happens today without this, badly, slowly, or manually?
- If this existed, what would you stop doing?
The answers usually relocate the problem entirely. Sometimes what’s needed is a page. Sometimes it’s a Slack notification. Sometimes, honestly, it’s a dashboard, but now we know why, and we can build the right one instead of a generically correct one nobody uses.
This is the first thing our Discover and Define phases are built to catch. It’s a small habit, and it saves months.