Milestone map
Milestone map
3 milestones
Define the app concept, research user needs, and produce wireframe flows
2 weeks
Before any visual design work, define the core problem the app solves, identify the target user, and conduct lightweight research (3–5 user interviews or a structured competitive analysis of 3–5 similar apps). The research output informs the information architecture and prevents designing solutions to assumed problems. Produce a complete set of wireframe flows covering all primary user journeys — wireframes should communicate the information architecture and user flow, not the visual design.
Proof required
Submit your research summary (3–5 user interview notes or competitive analysis of 3 apps with feature comparison table), a user flow diagram covering the primary journeys (sign-up, core feature, and at least one secondary flow), and wireframes for all screens in those flows. Wireframes must show the information on each screen and how screens connect; visual design choices (colour, typography, imagery) are explicitly excluded at this stage.
What gets checked
- Research informs at least one specific design decision — not 'I interviewed 3 people' but 'I interviewed 3 people and all three mentioned that they abandon apps that require registration before trying the core feature; the wireflow therefore shows a guest mode entry point'
- User flow diagram covers at minimum 3 flows (sign-up, core feature, one secondary) and shows every screen transition and decision point
- Wireframes communicate information hierarchy without visual design — all text is real content (no 'lorem ipsum'), layout shows relative prominence of elements, navigation is shown
Common mistakes
- Starting with visual design before defining the information architecture — colour and typography decisions made before the content hierarchy is settled must often be undone when the structure changes
- Conducting interviews without a specific design question in mind — open-ended 'tell me about your experience with X apps' produces stories; structured interviews around specific design hypotheses produce actionable insights
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter to walk through the user flow from app open to completing the core action — tests that the flow is coherent and that every transition is deliberate.
- Ask what the most important insight from the research was and how it changed a design decision — tests genuine integration of research into design.
- Ask what they decided not to include and why — 'what we cut' is often the most revealing design decision.
Build the high-fidelity UI design with mobile-specific patterns
2–3 weeks
Convert the wireframes into a complete high-fidelity UI design using real visual design decisions. Mobile-specific patterns must be applied correctly: touch targets ≥44pt on all interactive elements, platform navigation patterns (tab bar or bottom navigation, not desktop hamburger menus), platform-appropriate type scale, safe area insets, and appropriate use of system components versus custom components. The design must be component-based — repeated elements are built as shared components, not duplicated frames.
Proof required
Submit a shareable link to your Figma (or equivalent) file or a PDF export of all screens. The design must show: all screens from the wireframe flows in high fidelity with real typography, colour, and imagery or illustration, a component library section showing the reusable components you built, a colour and typography style guide, and the prototype connections showing the interactive flow. Include an annotation layer or a separate document noting where mobile-specific constraints (touch targets, safe areas, keyboard avoidance) influenced specific design decisions.
What gets checked
- All interactive elements are ≥44pt / ≥44px — the minimum touch target size is not a guideline; elements smaller than this consistently fail usability on a physical device
- Design uses a consistent 8-point grid — spacing and sizing choices that are not multiples of 8 (or 4 for smaller values) produce visual inconsistency that is visible at the finished design stage
- Component library accounts for at minimum 5 reusable components — buttons in all states (default, disabled, pressed), input fields, navigation bar, and the most-used content card or list item
Common mistakes
- Designing for a desktop viewport and then scaling down — mobile-first design starts with the constraints of a phone screen (small viewport, touch input, variable network, portrait orientation); designing desktop-first produces layouts that are crammed rather than designed for mobile
- Inconsistent component usage — if the same button style appears in three different sizes with three different border radii across the design, the component library is not being used; fix in the library, not screen by screen
Resources
What a verifier looks for
- Ask the submitter to show any interactive element and state its touch target size — tests that the 44pt rule was actively applied, not assumed.
- Ask why they chose the specific colour palette and typography — tests that visual design decisions are intentional, not default.
- Ask to see the component library and explain which components were the most difficult to design — tests genuine engagement with the component abstraction challenge.
Write design rationale and present for designer Q&A
1 week to write rationale and schedule review
Document the key design decisions in a design rationale document and present the complete design to a UI/UX designer or product designer for a Q&A that challenges specific decisions. The Q&A must probe the rationale behind information architecture, visual hierarchy, and platform pattern choices — not only whether the design is visually polished. The reviewer must present at least one alternative approach to a key decision and ask the submitter to evaluate the trade-off.
Proof required
Submit your design rationale document (800–1200 words covering: the problem the app solves, three key design decisions and the alternatives considered for each, one decision you made that goes against a common pattern and why, and one area of the design you would prioritise changing in a second iteration) plus a Q&A record documenting: the reviewer's challenge to at least one design decision, an alternative approach the reviewer proposed, the submitter's evaluation of that alternative, and the reviewer's assessment. The reviewer must be named and their UI/UX or product design background stated.
What gets checked
- Design rationale addresses alternatives, not just the chosen approach — 'I chose a tab bar because it is a common mobile pattern' is weaker than 'I chose a tab bar over a bottom navigation drawer because the app has exactly 4 primary destinations and all are equally important to frequent users'
- Q&A record shows genuine design thinking exchange — the reviewer proposes an alternative approach that the submitter evaluates with trade-offs, not just accepts or dismisses
- Reviewer has UI/UX or product design experience — a developer who has not done user-facing design work is not qualified to challenge information architecture decisions at the level this outcome requires
Common mistakes
- A design rationale that justifies every decision as 'industry standard' without examining the trade-offs — standard patterns should be used critically (when do I deviate from standard patterns and why) not as a substitute for design thinking
- Choosing a reviewer who is a friend rather than a practitioner — the Q&A must challenge specific design decisions; a reviewer who completes the review without pushing back on anything is not providing a credible evaluation
Resources
What a verifier looks for
- Propose a specific alternative to one navigation or information architecture decision and ask the submitter to explain the trade-off — the best design reviews challenge the structure, not just the visual execution.
- Ask what the design would look like on an older device with a smaller screen — tests awareness of the device diversity constraint.
- Ask what the most important interaction in the app is and whether the design makes it the most prominent thing on the screen — tests visual hierarchy thinking.