Where this service fits
A prototype makes an idea easier to question. Instead of discussing isolated screens, your team can follow the sequence from an entry point to a completed task. We use that sequence to check whether the next action is clear, whether the user has enough information and whether the proposed experience supports the product’s purpose.
The level of detail follows the question being tested. Early prototypes can focus on structure and language, while later versions explore interface behaviour and visual direction. We document the limits of the prototype so reviewers understand what is simulated. Findings feed back into the flows and specifications before development proceeds.
What the work can include
We agree the deliverables around your product and existing setup. A focused engagement can include the following work.
- An agreed set of journeys and review questions
- Connected Figma screens at the appropriate fidelity
- Review sessions and a record of design decisions
- Revisions and next-stage implementation guidance
Planning your project
The scope depends on the number of journeys, their branching states and the fidelity required. If the main uncertainty is technical, a functional engineering prototype may also be needed. We distinguish that work from a clickable design prototype and agree how the two inform each other.
The estimate should identify the work, assumptions and responsibilities on both sides. We can shape a first phase around the highest-priority outcome, with additional work planned separately once the relevant decisions have been made.
Share your starting pointDesign the states behind the polished screen
A finished interface needs to account for more than ideal sample content. We consider empty states, long names, validation errors, loading, unavailable actions and successful completion. Responsive behaviour, readable contrast and clear focus states should be part of the specification. These details help the design remain useful when it meets real data.
The handover connects the visual language to components developers can build. Depending on the scope, that may include semantic tokens, reusable patterns, annotated interactions and an organised component library. We can review the implementation with your team and resolve the practical questions that emerge as the interface becomes a working application.
How delivery works
Understand the work
We start with your users, business model and current constraints. Bring an idea, a running product or a workflow that causes friction. Together we identify what needs to change and what a useful first outcome looks like.
Shape a practical scope
We connect the user journey to the design, engineering and operational work it needs. Assumptions, dependencies and responsibilities are discussed early, so you can make informed decisions about the first release and the work that follows.
Build with visible progress
Designs, prototypes and working features give us something concrete to discuss. We review progress with you, resolve questions as they arise and test the important journeys. Changes to priorities are considered against the agreed scope.
Launch and keep improving
Release preparation includes the agreed testing, deployment and handover. We make support responsibilities clear and can continue as your product team, improving the experience as you learn from real use and plan the next release.
U4RIA brings multiple wellness experiences into one product. Its case study explores the journeys and interface decisions behind helping people find their next useful activity.
Explore related workFrequently asked questions
Is a clickable prototype a working app?
No. It demonstrates the intended experience and may simulate interactions without a live backend. It is useful for design decisions and feedback. A functional prototype is a separate engineering scope when real data or integrations need to be tested.
Can this be a focused engagement within our existing product?
Yes. We can scope this work around an existing product after reviewing the relevant design, code or operating setup. We identify the dependencies and agree what is included, who provides access and how the change will be reviewed. If another part of the product also needs work, we explain that before expanding the scope.