Skip to content

Decide how it works before deciding how it looks.

Research, flows, prototypes, design systems and interaction design.

Service Product Design & UI/UX

01 — Problems

You are probably here
because of one of these.

  • A product users abandon at the same screen every time.
  • A design that looks right in a mockup and falls apart at real data lengths.
  • Every screen slightly different because there is no system underneath.
  • A handoff that leaves engineers guessing at spacing and states.
  • An interface nobody has checked for contrast or keyboard access.

02 — Capability

What we actually do.

How we picture it: A wireframe evolving into a finished interface.

  • User research and journey mapping
  • Information architecture and flows
  • Wireframes and clickable prototypes
  • Interface systems and component libraries
  • Interaction and motion design
  • Accessibility review to WCAG AA

03 — Scope

What is in, and what is not.

The right-hand column is the one most studios leave out. Naming the exclusions up front is how a fixed price stays fixed.

Deliverables

  • Research findings and prioritised problems
  • User flows and information architecture
  • Clickable prototype of the critical paths
  • Component library with states and tokens
  • Empty, loading, error and offline states specified
  • Engineering handoff with measurements and behaviour notes

Not included

  • Brand identity and logo design, unless scoped separately
  • Photography and video production
  • Illustration at volume
  • Unlimited revision rounds — the number is agreed up front

05 — Technical approach

What we build it with.

Chosen per project against your constraints — not a fixed house stack, and not a logo wall. The test is what your team can maintain after we hand it over.

Design

  • Figma
  • Design tokens
  • Component libraries

Research

  • User interviews
  • Journey mapping
  • Usability testing

Prototype

  • Clickable prototypes
  • Motion specification

Quality

  • WCAG AA contrast
  • Keyboard paths
  • Responsive rules

How this gets proved

  • We design the states nobody demos — empty, loading, error, offline — because those decide whether a product feels finished.
  • Every handoff includes behaviour, not just appearance, so engineering is not guessing.
  • Accessibility is checked during design rather than raised as a defect after launch.

06 — Delivery

Checkpoints and timelines.

You sign off at each of these

  1. Research You approve the problems we are solving
  2. Flows You approve the structure before any visual work
  3. Prototype You click through the critical paths yourself
  4. System You approve the component library and handoff

Typical timelines

Focused product or feature
2–4 weeks
Full app or platform design
4–8 weeks
Design system with research
8–14 weeks

Ranges, not promises. Your actual timeline is fixed in writing in the proposal once the scope is agreed.

08 — Questions

The ones people actually ask.

Yes. The deliverable is a documented system another engineering team can build from — measurements, states, tokens and behaviour. That is the point of designing it properly.

Project qualification

Get a fixed-price proposal.

Tell us the problem, the stage you are at and the budget band. You get a discovery call, then a written proposal with exact scope, milestones and a final number — within 24 hours.

Response
Fixed-price proposal within 24 hours
Confidentiality
Mutual NDA signed before any project detail is discussed

Prefer to just talk? WhatsApp is answered fastest during studio hours.