Skip to content

Process

Six phases, the same order, every time

A tight deadline changes how deep each phase goes — never whether it happens. Skipping the understanding phase is how projects end up beautifully solving the wrong problem.

01 Understand02 Structure03 Design04 Validate05 Hand off06 Refine
01

Understand

We agree on the problem before anyone proposes a solution.

Most failed design projects were solving a problem nobody had confirmed. This phase ends with a written statement of the goal, the user, the constraints and how we will know it worked — signed off by you before anything else starts.

3–7 days

What happens

  • Kickoff workshop with whoever owns the outcome
  • Stakeholder interviews to surface conflicting expectations early
  • User interviews and support-ticket review
  • Competitive and convention teardown
  • Technical constraint review with the engineers who will build it

You receive

  • Problem statement & success metrics
  • User and persona notes
  • Competitive teardown
  • Constraint list
  • Agreed scope and timeline

I need from you

  • Access to two or three real users
  • Whatever analytics and support data already exists
  • One decision-maker who can approve direction
02

Structure

The skeleton gets argued over while it is still cheap to change.

Flows, information architecture and low-fidelity wireframes. Deliberately unstyled — grey boxes stop the conversation drifting to colour before the structure is right, and they make gaps impossible to hide.

1–2 weeks

What happens

  • User flow mapping for every primary and recovery path
  • Information architecture and navigation model
  • Low-fidelity wireframes for key screens
  • Content and terminology decisions
  • Early review with engineering for feasibility

You receive

  • Flow diagrams
  • Site / app map
  • Low-fidelity wireframes
  • Content model & terminology

I need from you

  • Fast feedback — this phase moves quickly
  • Real content examples rather than lorem ipsum
03

Design

Every screen, and every state that screen can be in.

High-fidelity UI built on a tokenised system from the first screen. Empty, loading, error, offline, permission-denied, first-run and too-much-data states are designed as part of the work — not discovered by an engineer at midnight.

2–5 weeks

What happens

  • Visual direction and design tokens
  • High-fidelity screens for all primary flows
  • Every state for every screen
  • Component library with variants and auto-layout
  • Motion and interaction specification
  • Accessibility validation as each component is built

You receive

  • High-fidelity UI
  • Complete state coverage
  • Component library & tokens
  • Motion specification

I need from you

  • Brand assets, if a brand already exists
  • One consolidated round of feedback per review, not five separate messages
04

Validate

Real people use it before your engineers build it.

A clickable prototype put in front of users who have never seen the product. Five sessions find most of what is wrong, and every one of those findings is cheaper to fix now than after a sprint.

1–2 weeks

What happens

  • Clickable prototype assembly
  • Usability testing with 5–8 participants
  • Session synthesis and severity rating
  • Design revisions from what was learned
  • Stakeholder walkthrough of the tested prototype

You receive

  • Interactive prototype
  • Usability findings, rated by severity
  • Revised designs

I need from you

  • Help recruiting participants, or approval to recruit externally
  • Willingness to change something the testing contradicts
05

Hand off

Engineers get answers, not a link and a wave.

A structured handoff: annotated screens, documented components, specified behaviour and a live walkthrough. Then I stay reachable, because the questions that matter always arrive during the build.

2–4 days

What happens

  • Annotated specs for spacing, behaviour and edge cases
  • Component documentation with usage rules
  • Live walkthrough with the engineering team
  • An open channel for build-time questions
  • Asset export in the formats the team actually uses

You receive

  • Annotated handoff file
  • Component documentation
  • Exported assets
  • Recorded walkthrough

I need from you

  • The engineering team in the walkthrough — all of them, once
  • A staging environment I can reach
06

Refine

It ships looking like the design, then gets better with usage.

Design QA against staging, then iteration based on what real usage shows. The gap between a design file and a shipped product is where quality is usually lost — this phase exists to close it.

Ongoing

What happens

  • Design QA pass on staging, filed as specific tickets
  • Post-launch analytics review against the success metrics we agreed in phase one
  • Prioritised improvement backlog
  • System updates as new patterns emerge

You receive

  • Design QA report
  • Post-launch findings
  • Prioritised improvement backlog

I need from you

  • Access to analytics after launch
  • A slot in the roadmap for the fixes worth making

Principles

The rules behind the phases

The process is the visible part. These are the positions that decide what happens inside it.

Clarity beats cleverness

If a pattern needs explaining, it is a prototype for a better pattern. Novelty is a cost the user pays.

The edge cases are the product

Anyone can design the happy path. The difference between a good app and a frustrating one lives in the empty, slow and broken states.

Constraints are information

A tight deadline, a legacy API or a small team tells me what the real solution space is. Designs that ignore constraints do not get built.

Accessible is not optional

Contrast, target size, focus order and text scaling are part of done. Designing them in costs nothing; retro-fitting them costs a quarter.

Show the reasoning

Every meaningful decision comes with the problem it solves, the option it beat and how we will know if it worked.

Design until it ships

Handoff is a milestone, not an exit. I review staging, file the QA tickets and see the release land.

Tooling

What I work in

Figma for most things. The rest earn their place by doing something Figma cannot.

Design & prototyping

FigmaFigJamAdobe XDSketchFramerProtoPieInVision

Research & testing

MazeUseberryGoogle FormsNotionMiroOtter

Visual & motion

Adobe PhotoshopAdobe IllustratorAfter EffectsLottieBalsamiqAxure RP

Handoff & collaboration

Figma Dev ModeZeplinJiraSlackTrelloClickUp
See the full skills breakdown

Want to run this on your product?

Tell me where you are — an idea, a half-built app, or something live that is underperforming. I will map it onto these phases and tell you where to start.

Start a projectSee the services
madnansakhi@gmail.com