Process

Every successful product begins with understanding the problem.

My process combines business strategy, user research, product thinking, interaction design, visual systems, testing and continuous iteration, so every decision supports both users and business goals.

  1. 01

    Discover

    Stakeholder and user interviews, market and competitor review, analytics and support data. Understand the domain before proposing anything.

  2. 02

    Define

    Frame the problem, agree the constraints and set the success metrics with the people accountable for them.

  3. 03

    Design

    Information architecture, flows, interaction and UI — built on a design system rather than one-off screens.

  4. 04

    Validate

    Prototypes tested with real users and technical spikes with engineering, before the expensive work starts.

  5. 05

    Build

    Design inside delivery: refinement, acceptance criteria, pairing with engineers and QA of the implemented UI.

  6. 06

    Measure

    Instrument the flows that matter, then read adoption, drop-off and task success against the metrics agreed up front.

  7. 07

    Improve

    Iterate on what the data and the users show, and fold the learning back into the system so it compounds.

Philosophy

Good design isn’t decoration. It’s making the right decisions before making beautiful ones.

The best products are built where business goals, user needs, engineering constraints and thoughtful execution meet.

Inside an engagement

What the steps look like in practice on a typical engagement.

01 · Week 1

Framing

Agree on the problem, the constraints and what success looks like — before anything is designed.

  • Stakeholder interviews across product, engineering, sales and support
  • Audit of the current product, analytics and support tickets
  • Constraint mapping: tech, compliance, budget, timeline
  • Success metrics defined with the people accountable for them
  • Problem statement
  • Success metrics
  • Constraint map

02 · Weeks 2—3

Discovery

Talk to the people who use the product and the people who sell it. Turn the mess into a model everyone can argue with.

  • User and domain-expert interviews, shadowing real workflows
  • Jobs, journeys and failure points mapped end to end
  • Competitive and adjacent-market teardown
  • Domain model and shared vocabulary drafted with engineering
  • Journey map
  • Domain model
  • Prioritised opportunity list

03 · Weeks 3—4

Direction

Two or three credible directions, trade-offs explicit. A business decision, not a taste debate.

  • Concept directions explored at low fidelity, fast
  • Trade-off matrix: effort, risk, differentiation, time to value
  • Interactive prototype for the strongest direction
  • Validation with users and a technical spike with engineering
  • Chosen direction
  • Clickable prototype
  • Roadmap slices

04 · Weeks 4—8

Systems

Build the system that makes the rest cheap: tokens, components, patterns and the rules for using them.

  • Design tokens, type scale, spacing and colour built for theming
  • Component library in Figma, mirrored in code with engineering
  • Interaction, empty, loading and error patterns documented
  • Accessibility baseline set and tested (WCAG AA)
  • Design system
  • Coded component library
  • Usage guidelines

05 · Ongoing

Delivery

No handover moment. Design at the pace of the sprint, and make the small calls that decide whether it feels finished.

  • Design embedded in refinement, planning and review
  • Slice-by-slice specs, edge cases resolved in the ticket
  • Design QA on every release candidate
  • Trifecta rituals: design, product and tech deciding together
  • Shipped increments
  • Design QA log
  • Zero-handover flow

06 · Post-launch

Compounding

Measure what shipped, fix what missed, hand over ownership deliberately.

  • Instrumentation reviewed against the metrics set in framing
  • Usability testing and iteration on the weakest flows
  • System governance: contribution model and review rituals
  • Coaching and hiring support for the in-house design team
  • Measured impact
  • Governance model
  • Team that owns it