Three weeks in. We had wireframes, a dev estimate, and alignment on the IA. What we didn't have was the right problem.
The unease had started earlier. A user interview that felt incomplete. An assumption everyone accepted without saying it aloud. A spreadsheet of feature requests that might have been solving the wrong thing entirely. By week three, I couldn't ignore it anymore.
A Fintech Forecasting Problem
The brief was tight. Small business owners struggled with cash flow. User data showed abandonment of the forecasting feature. Redesign it. Make it intuitive. That was the work.
In the fourth user interview, a bakery owner named Maria showed me her workflow. Three spreadsheets. A calculator app. A notes app. When I asked why she didn't use the forecasting tool, she said: "I don't trust it. I don't understand where the numbers come from."
Not a usability problem. A trust problem. The algorithm made assumptions about seasonality and growth that were invisible to users. Maria needed transparency. She needed to verify the logic before betting her business on the predictions.
I brought this back to the team at week three. The product lead had committed to a timeline. The developer had wireframes ready. Suggesting we'd been solving the wrong problem felt like admitting failure. There was defensiveness. The data showed users weren't engaging. Wouldn't a better interface fix it?
Six more interviews confirmed it. The pattern was consistent. Users needed explainability, not prettier layouts. They wanted to see the assumptions and adjust parameters.
Instead of redesigning the interface, we spent the next four weeks making the algorithm transparent. Added explainability. Let users see the underlying assumptions and tweak them. Adoption of that feature tripled in three months.
What Changed
The obvious problem is rarely the real one. It sits underneath an assumption everyone made without saying it aloud. That unease—the one that arrives around week three—usually points toward it.
Most design work happens inside someone else's frame. You get a brief. You solve it. You move on. But if you're willing to move upstream, to question the problem itself, the work becomes different. Not faster. But more connected to what actually matters.
It means sitting with discomfort. It means asking questions when there's pressure to commit. It means noticing when the obvious solution doesn't match what users are actually struggling with. None of it requires permission. Just attention.
The right problem is hiding in the details of how people actually work. In Maria's spreadsheets. In the assumptions everyone agreed on without debate. Designers can catch those moments. But only if they're willing to slow down when the rest of the team wants to accelerate.
