The App Onboarding Screen Under Deadline
A designer is asked to produce a mobile onboarding flow for a budgeting app in 5 working days. The flow has 4 screens: welcome, account setup, a permissions request for notifications, and a first-budget screen. Usability testing is not scheduled. Stakeholders include a product manager who wants the permissions request on screen 1 ('to capture users early'), a legal reviewer who needs a clear consent statement, and an engineer who says the notification permission can only be requested after account creation on the current build. Target users include people with low digital confidence. The designer has time for one round of internal critique only.
1. Where should the notification permission request go, and how should the designer handle the stakeholder conflict?
Read the worked answer
The permission request should go after account setup and before or on the first-budget screen, not on screen 1. Reasons:
- Engineer's constraint is decisive: the build cannot request permission before account creation, so screen 1 is not implementable without rework. That alone rules out the PM's position on this build.
- Low-digital-confidence users are more likely to grant a permission they understand. A request at screen 1, before any context, reads as an unexplained interruption and invites refusal - and on iOS/Android a refusal is often permanent for that install.
- Consent quality: asking after the user has seen what the app does produces a more informed, legally cleaner consent than a cold ask.
The designer should not simply overrule the PM. The productive move is to reframe the PM's goal - 'capture users early' - as reduce drop-off, and show that a well-timed, well-explained request serves that goal better than an early one that gets denied. Bring the engineer's constraint into the conversation as a shared fact, not as the designer's opinion. The internal critique is the moment to pressure-test this with the legal reviewer present.
2. With no usability testing and one critique round, how should the designer de-risk the flow?
Read the worked answer
Without formal testing, the designer should rely on heuristic review and a lightweight guerrilla check rather than shipping blind:
- Run the one critique as a structured heuristic walkthrough - have a colleague narrate each screen aloud as a first-time, low-confidence user, flagging where they hesitate or cannot predict what happens next.
- Do 3–5 quick hallway tests (colleagues or friends outside the team) on the prototype, watching where they tap and stall. This is not rigorous but catches gross errors cheaply.
- Design for reversibility: make permissions skippable where the platform allows, keep the consent statement plain-language and visible, and ensure the first-budget screen has an obvious 'skip for now' so low-confidence users are not trapped.
- Document assumptions explicitly for the next iteration, since 5 days precludes validation.
The judgement being tested is recognising that 'no testing scheduled' does not mean 'no feedback' - the designer engineers the cheapest available signal and protects users from the highest-cost failure (a permanently denied permission or an abandoned signup).