Experience prototypes
Explore navigation, information hierarchy and the steps in a user journey. Use realistic tasks and content so feedback concerns the actual work, rather than reactions to a polished empty interface.
Rapid PrototypingResolve the uncertainty
Resolve the uncertainty
before the larger build.
Focused prototypes that test an experience, an AI behaviour or a technical dependency before you commit more capital.
Our position
A prototype should produce a decision.
We begin with the uncertainty that matters most. Can a user complete the task? Can the model work with the available information? Can a critical integration support the intended interaction? The prototype is designed around the evidence needed to answer that question.
This is deliberately different from building an unfinished version of every feature. We choose a narrow slice, make the assumptions visible and agree how the findings will influence the next step. A decision to change direction can be as useful as a decision to proceed.
What we configure
A specific scope, built around your work.
AI proofs of concept
Assess a specific behaviour using representative inputs. Examine quality, source coverage, response consistency and what happens when the model cannot produce a useful result.
Technical experiments
Test a dependency such as data access, an external API, a model interaction or a performance constraint. Record what was tested, under which conditions, and what remains unproven.
How we workHypothesis.
Hypothesis.
Evidence. Decision.
The sequence is shaped around Rapid Prototyping, with scope and responsibilities agreed before implementation.
- 01Hypothesis
- 02Smallest test
- 03Observed evidence
- 04Next investment decision
Revise the hypothesis when the evidence changes.
Write the hypothesis
State the decision the prototype supports and the assumption behind it. Define a testable question, the people or inputs involved and a clear stopping point.
Choose the smallest useful form
Use a clickable journey, a working technical slice or an AI experiment according to the uncertainty. Production infrastructure is included only where it is necessary to obtain meaningful evidence.
Test with relevant evidence
Observe tasks, inspect outputs and capture failures as well as successful paths. Distinguish what the prototype demonstrates from what was simulated or left outside scope.
Turn findings into a next step
Document the conclusion, unresolved risks and recommended changes. If a production build follows, establish its architecture, access controls, operational requirements and acceptance criteria separately.
Explore the approach
Choose what you need to learn.
A different uncertainty calls for a different prototype. Select a question to see the evidence we would seek.
1Task2Prototype3Observe4Revise
Evidence: task completion and points of confusion
Build a focused interactive journey and ask representative users to complete a realistic task. Observe where they hesitate, what information is missing and whether they can reach a useful outcome.
The implementation scopeWhat the work
What the work
leaves with you.
These are the delivery components we define together. The depth, access and handover arrangements follow the agreed engagement.
Prototype brief
The hypothesis, assumptions, test method and scope boundary.
Testable artefact
A focused interactive prototype or working technical experiment.
Findings record
Observed behaviour, limitations and remaining uncertainty.
Next-phase scope
A revised concept, a build recommendation or a reason to pause.
Capital & operation
Buy evidence before buying scope.
A prototype creates value when it changes a capital decision. We prioritise uncertainties that could invalidate the experience, alter the architecture or materially change operating cost. The work has an explicit boundary so exploratory effort does not quietly become an unplanned product build. A prototype is not represented as production-ready software, and its findings do not imply that every future use case has been validated.
Before we begin
Practical questions.
Is a prototype an MVP?
Not necessarily. A prototype tests a question and may simulate parts of the experience. A minimum viable product is an operational release for real use and needs the appropriate production foundations.
How do we prevent endless iteration?
Agree the learning objective, test boundary and decision criteria before starting. New questions become deliberate changes to scope, rather than an open-ended sequence of visual revisions.
Can the prototype become the product?
Some components may be reusable. We assess that explicitly; production work may require different architecture, permissions, testing and operational support.
Define the first piece of workPrepare a useful
Prepare a useful
project brief.
Capture the objective, current process and first boundary. Download a working brief or copy it for a project discussion.
This tool runs in your browser. It does not submit or store your information.