The Six-Week Visual Refresh Request
Vaulted is a 14-person personal-finance startup whose budgeting app has 40,000 monthly active users. Sign-up completion sits at 38%, and the funnel shows the largest drop inside identity verification: users abandon after being asked to photograph their ID, and 61% of those never return to that screen. The CEO has told the designer, hired three weeks ago, to "redo the visuals so the app feels premium" before a funding demo in six weeks. The product manager wants to add a savings-goals feature. There is no researcher on staff, support tickets repeatedly ask "why do you need my passport", and the team has never written a success metric for sign-up. Two engineers are available, and anything built must ship before the demo. The designer is also the only person who has read the accessibility standard the company contractually agreed to meet.
1. The CEO asks the designer to spend the next two weeks on a visual refresh. Write the response you would give in the meeting and state what you would do in those two weeks instead. Justify it in terms the CEO cares about.
Read the worked answer
Start by separating the two things being conflated. UX design is the whole experience - whether a user can complete a goal at all; UI design is the surface that carries it. A visual refresh changes the surface. The evidence points at a structural problem: people stop at a permission request they do not trust, and 61% of them do not come back. Premium typography will not fix a trust failure, so the refresh would spend the two weeks without touching the largest revenue leak.
Then reframe in the CEO's terms: the demo is about traction. Moving sign-up completion from 38% to 50% is a more persuasive slide than a new palette, and it is achievable in six weeks because the problem is localized to one step.
Proposed two weeks, with the visual work scoped to a light pass:
- Days 1–3: segment the existing funnel by device, browser, and step; tag 90 days of support tickets.
- Days 4–6: five 20-minute sessions with people who abandoned at the ID step.
- Week 2: one problem statement, two or three concepts for that step, a prototype, and a small test.
Close with the constraint nobody has named: the contractual accessibility requirement. A visual refresh done before contrast and target-size checks creates rework, so the surface work should follow the structural fix, not precede it.
2. What is the risk of skipping the empathize phase under this deadline, and what is the minimum credible evidence you would gather in week 1? Be specific about method, sample, and what you would do with the output.
Read the worked answer
The risk is not "we did less research". It is that the team substitutes its own assumptions for the user's and then spends six weeks building on them - and that the loudest stakeholder's mental model wins by default. With a fixed demo date the real question is what evidence is cheapest per unit of uncertainty reduced, not whether to do research.
Minimum credible set, roughly three days of work:
- Behavioural data you already own. Step-level funnel segmented by device and browser. Costs hours, and can immediately separate a mechanical failure (camera permissions on older Android) from a motivational one.
- Support tickets. Tag the last 90 days by complaint type. This is qualitative data at zero recruitment cost and often tells you the exact wording users object to.
- Five short moderated sessions with people who abandoned at the ID step, recruited by email. Twenty minutes each, task-based, think-aloud. Five is enough to surface recurring qualitative patterns; it is not enough to estimate a rate.
- A heuristic and accessibility pass on that one screen, since nobody has done one.
Output: an affinity map, one written problem statement, and a ranked list of candidate causes with the evidence attached to each. Explicitly label what is still an assumption so the team can see the gaps rather than inherit them.
3. The PM proposes adding a four-screen in-app tutorial to improve sign-up. How do you decide between that and reworking the verification step?
Read the worked answer
Treat this as a question about where the failure is, not about which feature is nicer. The funnel says abandonment is concentrated at one step; a tutorial is a cost paid by every user to compensate for a problem experienced by a subset. Unless the evidence shows that people fail because they do not understand what happens after verification, a tutorial will not move the number - and it adds translation, accessibility, and maintenance burden.
A workable decision process:
- Hypothesis check. Do support tickets and session notes show confusion about the process (supports a tutorial) or distrust and friction at the upload (supports reworking the step)? These imply different fixes.
- Cheapest diagnostic first. Test the current step with five abandoners before building either. If three or more fail on the same element, that element is the problem.
- Cost comparison. A tutorial is four screens of new content in every locale plus a dismissal pattern. Reworking one screen is a copy change, a clearer explanation of why the ID is needed, a manual-entry fallback, and better camera handling.
- Measure at step level. Define completion of the verification step as the metric, not overall sign-up, so the effect is attributable.
If a tutorial is still wanted, scope it to the single moment of confusion, make it dismissible, and never use it to paper over a broken control - users learn to skip those, and the underlying failure remains for everyone who does.