Service · Product definition and UX

Resolve the product before
committing to production.

A disciplined way to define a digital product, resolve its essential journeys and create a convincing functional prototype before committing to production engineering.

S·03 · Engagement terms

Engagement terms

From price
From £1,500
Typical timeline
6–10 weeks
Scope basis
Quoted after scope
Ideal client condition

Internal teams with a valuable product idea that remains difficult to explain, evaluate or fund.

Primary deliverables
  • Product definition
  • Journey and state model
  • Interface system
  • Functional prototype

The working window is indicative, not a delivery promise. Final timing depends on scope, content readiness, integrations, access and the speed of consolidated decisions.

01 · Fit and business case

For a real commercial change,
not a surface refresh.

Who it is for
  • Internal teams with a valuable product idea that remains difficult to explain, evaluate or fund.
  • Companies replacing a manual or fragmented workflow before committing to a full software programme.
  • Teams exploring a bounded AI-assisted experience that needs explicit sources, limits and human control.
The business problem

The idea is being discussed as a feature list rather than a coherent product. Critical assumptions, user journeys, data boundaries and technical dependencies remain unresolved, making a production estimate unreliable and stakeholder confidence difficult to earn.

The intended outcome

A defined product direction, prioritised core flows, authored interface system and convincing functional prototype that can support validation, stakeholder alignment, investment or a more accurate production phase.

02 · Typical scope

A connected system,
defined before production.

Every proposal names the exact deliverables. These are the usual workstreams, not an unlimited checklist.
  1. 01

    Product definition

    Objective, audience, jobs, assumptions, boundaries and the decision the prototype must make easier.

  2. 02

    Journey and state model

    Core flows, information architecture, system states, permissions and failure or handoff points.

  3. 03

    Interface system

    A representative responsive UI language for the highest-value product surfaces.

  4. 04

    Functional prototype

    A convincing browser-based prototype of the agreed flows, with simulated or bounded data where disclosed.

  5. 05

    Validation material

    A structured walkthrough, test questions and evidence needed for the next decision.

  6. 06

    Production roadmap

    Known dependencies, risks, staged build recommendation and an explicit account of what remains unbuilt.

03 · Relevant public work and projects

Evidence with its
status intact.

Live delivery, planned client engagements, prototypes and self-initiated concepts are deliberately not presented as equivalent evidence.

04 · Working sequence

Decisions first.
Production with a reason.

  1. 01

    Frame

    Agree the product question, audience, assumptions, constraints and validation threshold.

  2. 02

    Model

    Map the essential journey, content, states, decision points and operational handoffs.

  3. 03

    Prioritise

    Select the smallest flow capable of proving the intended product value.

  4. 04

    Prototype

    Design and implement the agreed experience with its simulated and functional parts labelled.

  5. 05

    Evaluate

    Use realistic walkthroughs or testing to identify confusion, missing states and unsupported assumptions.

  6. 06

    Recommend

    Deliver the next-phase roadmap, risks and production questions without presenting the prototype as a finished application.

05 · Responsibilities and boundaries

Clarity protects
the quality of the work.

Risks and exclusions

Not included unless a proposal names it explicitly.

  • A production-ready application, complete backend, live model, persistence or infrastructure unless explicitly contracted.
  • Unbounded feature discovery or an attempt to represent an entire future platform.
  • Security, compliance or regulatory certification.
  • Large-scale data migration, enterprise integrations or production operations.
  • Claims of product validation without representative testing or market evidence.

What the client prepares

The engagement moves well when these inputs are available.

  • Access to subject-matter experts and the people who own the operational process.
  • A defined decision the sprint must support.
  • Source material, data examples and policies needed to model realistic states.
  • Fast, consolidated review at the agreed decision points.

06 · Frequently asked

Useful questions,
answered directly.

01Is the result a production application?

Not by default. The engagement covers definition, UX and a convincing functional prototype. Production engineering, infrastructure, live data and operational readiness are separately scoped.

02How functional will the prototype be?

Functional enough to evaluate the agreed product question. Some states may use illustrative or simulated data, and every non-production boundary is documented rather than disguised.

03Can the prototype become the production foundation?

Sometimes, but it should not be assumed. The prototype optimises for learning and clarity; the roadmap explains what can be retained and what needs production engineering.

04Can AI be included?

Yes when the use case is bounded and its sources, uncertainty, permissions and human handoff can be made visible. A scripted interaction is never presented as a running model.

S·03 · Studio review

If this is the right starting point,
bring the actual constraint.

Share the business objective, audience, present condition, investment range and any fixed deadline.
Discuss this engagement
Back to top