There's a version of product design that looks like this: a problem gets described in a meeting, a designer opens Figma, and a few days later there's a beautiful flow to review. It photographs well in a portfolio. It also, in my experience, is the version most likely to ship something nobody can prove worked.
I've now run this experiment three times, on three very different products, and the pattern keeps repeating.
The tab nobody understood
At RD Saúde, the Mais Saúde tab inside the Raia and Drogasil apps had a real activation problem — 18% activation, weak click-through, and qualitative feedback that kept using the same word: generic. It would have been easy to jump straight to redesigning the home screen. Instead, the team defined three hypotheses and, for each one, the exact metric that would prove or kill it — before any screen existed. H1 was about activation and had a number attached: first-click rate. H2 was about relevance and had a number attached: profile completion and CTR on recommendations. H3 was about recurrence and had a number attached: D7/D30 return.
That sequencing — metric first, screen second — changed the conversations that followed. When a stakeholder pushed for a feature that didn't map to one of the three metrics, the question wasn't "do we like this idea," it was "what does this move." The eventual redesign took CTR for users with a complete profile from 13% to 70%. That number was defined months before the interface that produced it.
The 30 days we didn't spend in Figma
At Dentsu, on the L'Oréal Brasil account, the instinct after a chaotic platform migration was to start fixing the obvious: misaligned components, broken search, a checkout that looked assembled by five different teams (because it was). We didn't. The first 30 days went into desk research, heuristic analysis and competitive benchmarking — building a case solid enough that recommendations wouldn't get relitigated in every meeting.
That patience is uncomfortable. It looks, from the outside, like nothing is happening. But the eventual recommendations — search improvements, a new product page, intelligent kit recommendations — landed with almost no pushback, because by the time we presented them, the client had already seen the data that made them inevitable. The intelligent-recommendations work alone lifted conversion 1.6%, the best result across five brands. The metric that mattered was decided long before the wireframe.
What happens when you skip this step
The counter-example is instructive too. At Hurb, we had three hypotheses about why cross-sell and upsell were invisible to travelers, and we validated them properly — seven interviews, then a 1,109-respondent survey that made the priority obvious: 38.6% of travelers wanted a better hotel, more than double the next-highest request. We built the case correctly. What didn't survive was the roadmap itself — a company-wide staff reduction meant only the first layer, a contextual extras modal, actually shipped. It worked, revenue moved, but the travel planner and hotel upsell system stayed on paper.
The lesson there isn't about metrics — it's that a senior designer's job doesn't stop at validated hypotheses. It includes watching the business context closely enough to know when the roadmap itself is at risk, and negotiating scope down to what can actually survive the quarter.
The habit, not the framework
None of this is a call for more process. Plenty of teams write KPIs into a doc that nobody reopens. The difference is sequencing: deciding what "working" looks like, in a number, before the first mockup — not as documentation, but as the thing that will make or break the coming argument with a stakeholder, a PM, or your own attachment to a nice-looking screen.
If I can't say what number would tell me I'm wrong, I'm not ready to open Figma yet.