Discover
Define the critical riskWe pin down which value, action, data or commitment the prototype must test.


Product development → Prototyping and UX
We map the user scenario, build an interactive prototype and test whether users understand the product before costly development.
Discuss your projectOverview
A prototype shows whether users grasp the value, can complete the key path and have enough information, and where they make mistakes or hesitate. Before we start, we pick one critical risk instead of trying to show the whole future product.
Solution architecture
We move from the scenario boundaries to a user test and a technically sound scope for the first version.
We pin down which value, action, data or commitment the prototype must test.
We design the user flow, information architecture, roles and states of the key scenario.
We put together wireframes, content and transitions detailed enough for users to go through on their own.
We give each participant a task, observe their behavior and separate recurring problems from personal preferences.
We update the scenario, bring in a technical estimate and decide on the next test or on development.
Unit economics and ROI
Changing a scenario in a prototype is faster and cheaper than changing it once architecture, data and dependencies exist in code. The savings come from catching logic gaps and costly states early.
Developers get involved before the design is final: they check data availability, integrations and platform constraints. The team knows the cost of a solution before it turns into technical inertia.
Result
You end up with a validated scenario and requirements for the first working version.
Comparison of approaches
The format depends on whether the logic of the key scenario is confirmed.
| Approach | What it tests | Limitation | When it fits |
|---|---|---|---|
| Static design | Visual composition | Doesn't show behavior and transitions | The scenario is already clear |
| Interactive prototype | Logic and product understanding | Not a production system | UX is still uncertain |
| Straight to development | Real-world use | Core logic is expensive to change | Risks are already resolved |
Limitations and risks
A prototype is a decision-making tool, not a promise of a finished product.
It does not prove the system's performance, security or technical readiness.
If it's unclear who needs the product and why, a polished scenario won't test the underlying value.
Without errors, empty states, roles and recovery, the development estimate will be wrong.
A good fit
Not a fit
Frequently asked questions
Most often in Figma. For real data or complex logic, a functional proof of concept may be required.
The level of detail depends on the question. To test the logic, a clean and clear prototype is enough.
Yes, as long as you make it clear that it is a concept demo, not a finished product.
The team updates the scenario and decides whether to run another test, do a technical experiment or move on to development.
The cost depends on the number of roles, key scenarios and states to be shown, and on the user testing format. A prototype of one key path is simpler than a prototype of a product with several roles and complex logic. We provide an estimate once the critical risk the prototype must test has been defined.
The timeline depends on the complexity of the scenario, the number of roles and the number of testing rounds. We limit the prototype to one critical risk, so this stage is usually shorter than building the first version. If the scenario changes after testing, a further round is planned separately.
A prototype tests product understanding and the logic of the key scenario without production code or real data. An MVP is a working first version used by real customers, with architecture, integrations and analytics. A prototype helps refine the MVP scope before changes become expensive.
There is no universal number. We look for repeated problems: when new participants run into the same difficulties, the signal is considered sufficient. If the product has several roles, each key role is tested with separate participants.
Yes. For a mobile app it is especially important to test navigation on a small screen, onboarding, permission requests, notifications and offline behavior. Developers get involved before the design is finalized to account for iOS and Android platform constraints.
