The approved screen does not show what happens when the data fails.
The layout looks finished, but one user has two roles, the table has no rows, a name runs long, the save is delayed, and the integration rejects a change. Engineering invents each missing state under deadline. The released product no longer behaves like the design system the team approved.
Product design is the work of resolving those decisions before users and developers inherit them.
Documented product outcomes
- growth in self check-ins after a booking-platform redesign
- 7x
- City Break Apartments case record
- documented QR checkout flow
- <15 seconds
- Bella Skin Institute medspa product
- starting point for one critical design journey
- $15K
- Indicative scope, fixed after discovery
These are project-specific records, not promises for another product. The City Break Apartments outcome followed a broader product and operational change, so design cannot claim sole causation. The Bella Skin Institute time describes a delivered flow under its conditions, not a universal checkout target. Each new engagement defines its own baseline, task measures, constraints, and attribution limits.
Design works when the team can test and implement decisions
A fit01A critical user task, new product, redesign, or design system needs evidence, interaction detail, visual coherence, and engineering alignment.
02Representative users or credible proxies, product owners, engineers, content, data, and subject-matter reviewers are available.
03The team can implement, instrument, release, and measure the designed change rather than treating Figma approval as the finish line.
Not a fit01You need a quick visual reskin while product, information architecture, content, and workflow decisions remain out of scope.
02The expectation is guaranteed conversion, adoption, retention, accessibility conformance, growth, or stakeholder agreement.
03You only need evidence about an existing problem, a disposable prototype, brand identity, or frontend implementation without a product-design scope.
A UX audit diagnoses a live experience and prioritises evidence; it does not deliver the whole redesign. A prototype tests one uncertain direction; it is not a complete product specification. A targeted redesign resolves a known journey. Full product design covers the broader role, information, workflow, visual, system, and handoff needs. Choose the smallest engagement that creates the next reliable decision.
Decision guide
Match design scope to the uncertainty
| Engagement | Best when | Primary output |
|---|
| UX audit | A live product has measurable friction but causes and priority are unclear | Evidence, severity, recommendations, and validation plan |
|---|
| Prototype | One flow, concept, or feasibility question needs a test | Limited test artefact, observations, and decision |
|---|
| Targeted redesign | Evidence identifies a critical journey that needs resolution | Tested flow, UI, components, states, and implementation support |
|---|
| New-product UX/UI | Users and product boundary are clear enough to design a production experience | Architecture, journeys, system, screens, prototype, and handoff |
|---|
The first slice should cover entry, orientation, the core task, decision points, permissions, errors, recovery, confirmation, and the next step for one representative user. It should demonstrate how the information architecture, interaction model, visual language, content, accessibility, and component system work together before they expand across the product.
Scope
A focused product design engagement
- 01
Research and product evidence
Existing analytics, support and sales themes, interviews or observations, domain context, current journeys, competitive patterns, assumptions, research limits, task measures, and a clear record of what evidence supports.
- 02
Information architecture and interaction
Objects, relationships, navigation, terminology, hierarchy, search, filters, permissions, task flows, decision points, state transitions, notifications, errors, recovery, and the service work behind the interface.
- 03
Prototype and usability testing
Appropriate fidelity, representative tasks and participants, facilitation, observations, task success, errors, comprehension, accessibility considerations, counter-evidence, revisions, limitations, and decisions.
- 04
Visual UI and design system
Typography, colour, spacing, grid, responsive behaviour, components, variants, tokens, data density, icons, motion guidance, visual hierarchy, brand fit, and accessibility-aware states without claiming automatic conformance.
- 05
Engineering handoff and review
Figma source, sample content and data, dimensions, assets, components, states, behaviour, acceptance, design decision log, engineering review, implementation questions, device checks, and measured-release plan.
From user evidence to implemented product experience
- Phase 1
01Define users and decisions
Map product goals, user groups, jobs, evidence, current behaviour, critical tasks, content, constraints, systems, accessibility needs, measures, owners, and acceptance.
- Phase 2
02Prove structure and flow
Create information architecture, journeys, states, wireframes, and a testable prototype, then observe representative users and record findings, limitations, trade-offs, and revisions.
- Phase 3
03Design the product system
Deliver approved visual direction, responsive screens, components, tokens, content, interactions, permissions, errors, empty and loading states, accessibility notes, and implementation specifications.
- Phase 4
04Support implementation
Work with engineers through build review, resolve design gaps, test representative devices and tasks, record accepted changes, and hand over design-system, measurement, and maintenance ownership.
Risk
What a polished handoff can still miss
- The prototype tests the wrong people
- Record recruitment, role, context, device, task, facilitation, exclusions, and limitations. Five convenient colleagues do not represent an entire market.
- Accessibility is reduced to contrast
- Design keyboard, focus, structure, labels, errors, zoom, motion, touch targets, content, and assistive-technology considerations, then verify the implemented product separately.
- Components ignore domain states
- Test real content, permissions, empty data, high density, latency, failure, conflict, correction, destructive changes, and unusual but credible records.
- Design success is credited for every metric change
- Define the hypothesis, baseline, release cohort, instrumentation, concurrent changes, guardrails, and attribution limits before interpreting adoption or conversion.
Scope and price
One critical product-design journey starts at $15,000.
Start with evidence, architecture, flow, tested prototype, responsive UI, components, states, developer-ready specifications, implementation support, and named measures.
This is an indicative starting point, not a quote or a guarantee of adoption, conversion, retention, accessibility conformance, growth, delivery cost, or implementation quality. Outcomes are measured after release.
Starting investment
Starts at $15,000
A focused product-design engagement usually takes 6 to 10 weeks. Several roles, platforms, broad research, brand identity, content design, or a coded system add work.
The handoff includes the awkward states
Permissions, loading, empty, error, success, recovery, responsive behaviour, content, and accessibility notes are part of the agreed journey.
Design stays involved through implementation
Eight weeks of support are included for engineering questions, build review, accepted changes, and the measured-release plan.
Related product design and validation services