Good UX doesn’t happen by accident. It follows a repeatable process that surfaces the right questions, resolves them systematically, and produces designs that work for real users — not just in demos.

This checklist covers each stage of a UX project. Not every item applies to every project, but missing items from the first half (discovery and research) usually creates problems in the second half (design and launch).

Stage 1: Project Kickoff

Before designing anything:

  • Define the problem statement. What user problem are you solving? Write it down in one sentence. If you can’t, you don’t understand the problem yet.
  • Identify stakeholders. Who has a say in decisions? Who needs to be informed? Who will sign off?
  • Document success metrics. How will you know the design worked? Task completion rate? Conversion rate? Support ticket volume?
  • Clarify constraints. Technical constraints (what the platform can do), time constraints, brand constraints.
  • Align on scope. What is in scope for this design iteration? What is explicitly out of scope?
  • Review existing research. Before commissioning new research, review what’s already known. Analytics data, previous usability studies, customer support logs.

Stage 2: User Research

  • Identify research questions. What do you need to learn? Don’t conduct research without a list of specific questions to answer.
  • Choose appropriate research methods. Exploratory questions → qualitative research (interviews, contextual inquiry). Validation questions → quantitative (surveys, analytics analysis, A/B testing).
  • Recruit representative participants. Your user interviews should include people who match your actual or target users, not just whoever is convenient.
  • Conduct interviews. Aim for 5–8 interviews per distinct user group. Use semi-structured interview guides — questions prepared but room to follow interesting threads.
  • Document findings systematically. Recordings, notes, and synthesis artefacts. Don’t rely on memory.
  • Synthesise into insights. Group findings by theme. Identify patterns. Turn observations into actionable insights.

Stage 3: Information Architecture

  • Define user goals. What are users trying to accomplish? Map goals to tasks.
  • Map existing IA (for redesigns). Document the current structure before proposing changes.
  • Conduct card sorting (for navigation-heavy projects). Let users group content the way they think about it.
  • Create a site map or flow map. Visualise the structure before wireframing individual screens.
  • Validate the IA. Tree testing lets you check whether users can find things before you’ve built anything.

Stage 4: Wireframing

  • Start low-fidelity. Resist the temptation to jump into high-fidelity tools. Rough wireframes are faster to iterate and harder to get attached to.
  • Design for the key flows first. What are the 2–3 tasks that users will do most often? Get those right before edge cases.
  • Account for all states. Empty states, loading states, error states, and edge cases (very long names, no results, permissions variations).
  • Annotate decisions. Why is something designed this way? Annotations save time in design reviews.
  • Review with stakeholders. Get feedback at low fidelity, before investing in high-fidelity work.

Stage 5: Prototyping and Testing

  • Build a clickable prototype of key flows. Figma, Framer, or even a stitched-together PDF.
  • Define usability testing tasks. Give participants realistic scenarios, not step-by-step instructions.
  • Conduct usability tests. 5 participants will surface most critical usability issues. Test early and often.
  • Observe, don’t guide. During testing, resist the urge to explain what users are confused by. Their confusion is the data.
  • Synthesise findings. Prioritise issues by frequency and severity.
  • Iterate. Fix the critical issues. Test again. Don’t skip this step.

Stage 6: High-Fidelity Design

  • Establish a design system or align with an existing one. Colours, typography, spacing, components. Consistency is not aesthetic — it reduces cognitive load.
  • Design at real content scale. Design with real (or realistic) content, not lorem ipsum. Designs that look great with placeholder text often break with real data.
  • Accessibility compliance. WCAG AA at minimum. Colour contrast, touch target size, keyboard navigation, screen reader support.
  • Responsive design. Design for all target breakpoints. Don’t design desktop and assume mobile will figure itself out.
  • Internal design review. Present to the design team before going to engineering. A second pair of eyes catches inconsistencies.

Stage 7: Developer Handoff

  • Prepare assets. Export icons, images, and illustrations in the correct formats and sizes.
  • Annotate interactions. Document animations, transitions, hover states, and conditional logic.
  • Provide a component library. Engineers should be able to reference every component and its states.
  • Be available during implementation. Designs always raise questions during development. Plan for this.
  • Review implementation. QA the developed product against designs. Catch discrepancies before launch.

Stage 8: Post-Launch

  • Monitor analytics. Are users completing the flows you designed? Where are they dropping off?
  • Collect qualitative feedback. Customer support tickets, user interviews, NPS responses.
  • Document lessons learned. What would you do differently? Feed this back into the next project.
  • Plan iteration. Launch is not the end of UX work. Plan the next round of improvements based on real-world data.

This checklist won’t make every design decision easy, but it will help you avoid the most common process failures: designing without understanding users, skipping usability testing, and handing off designs that developers can’t implement.

If you’re working on a product that needs UX from scratch or a redesign, talk to us about your project.