Product development → Prototyping and UX

Prototyping and UX

We map the user scenario, build an interactive prototype and test whether users understand the product before costly development.

Discuss your project

Overview

What a prototype tests

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.

Focus
key user path
Format
interactive prototype
Validation
user behavior
Output
user scenario and MVP scope
In plain words

What it is and why it matters

What it is
We build a clickable model of the product's key scenario and test it with future users: do they see the value and can they complete the path before development starts.
Who it is for
An IT team whose customer problem is confirmed but the scenario is still unclear, and a logic mistake would mean expensive rework in code.
What you get
A tested user scenario, a section structure, layouts of key screens, an interactive prototype, user test findings and a preliminary scope for the first product version.
Where to start
Describe the product and the scenario you are least sure about. We will define the main risk the prototype should test and suggest a format.

Solution architecture

How we build and test a prototype

We move from the scenario boundaries to a user test and a technically sound scope for the first version.

01

Discover

Define the critical risk

We pin down which value, action, data or commitment the prototype must test.

02

Design

Build the structure

We design the user flow, information architecture, roles and states of the key scenario.

03

Deploy

Build an interactive prototype

We put together wireframes, content and transitions detailed enough for users to go through on their own.

04

Drive

Test with users

We give each participant a task, observe their behavior and separate recurring problems from personal preferences.

05

Dominate

Refine the scope

We update the scenario, bring in a technical estimate and decide on the next test or on development.

Unit economics and ROI

How a prototype cuts development costs

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.

What it protects
development budget
What it tests
behavior before code
Technical result
preliminary scope
Decision
test again or build

Result

What you get

You end up with a validated scenario and requirements for the first working version.

  • Critical user flow
  • Information architecture
  • Wireframes of key screens
  • Interactive prototype
  • User test script
  • Observations and decisions made
  • Errors, empty states and roles
  • Preliminary technical MVP scope

Comparison of approaches

Prototype or straight to UI development

The format depends on whether the logic of the key scenario is confirmed.

ApproachWhat it testsLimitationWhen it fits
Static designVisual compositionDoesn't show behavior and transitionsThe scenario is already clear
Interactive prototypeLogic and product understandingNot a production systemUX is still uncertain
Straight to developmentReal-world useCore logic is expensive to changeRisks are already resolved

Limitations and risks

What a prototype is not

A prototype is a decision-making tool, not a promise of a finished product.

Not a production product

It does not prove the system's performance, security or technical readiness.

Not a substitute for Discovery

If it's unclear who needs the product and why, a polished scenario won't test the underlying value.

Not just the happy path

Without errors, empty states, roles and recovery, the development estimate will be wrong.

A good fit

When this stage fits

  • The problem is confirmed, but the scenario is still unclear
  • You need to align the product with users and developers
  • A UX mistake would mean expensive rework
  • You need to test several roles and complex states

Not a fit

When to choose another approach

  • Problem and target segment are not confirmed
  • You only need the final visual design
  • The scenario already works in an existing product
  • The main risk is technical and requires proof of concept

Terms in plain words

User flow
sequence of user actions
Information architecture
structure of sections, data and relationships
Wireframe
a screen layout without final visual design
Happy path
ideal scenario without errors and exceptions
Scope
the boundary of features and states in the first version
Interactive prototype
A clickable model of the product without real code or data. Users walk through a scenario, and the team sees where they make mistakes or hesitate.
Empty state
What a screen shows before any data exists, for example for a new user. If it is ignored, the development estimate will be off.
Proof of concept
A technical experiment with real data or complex logic, used when the main risk is feasibility rather than user understanding.

Frequently asked questions

Prototyping and UX: questions

Which tool do you use to build the prototype?

Most often in Figma. For real data or complex logic, a functional proof of concept may be required.

Do we need full visual design?

The level of detail depends on the question. To test the logic, a clean and clear prototype is enough.

Can we use the prototype in an investor presentation?

Yes, as long as you make it clear that it is a concept demo, not a finished product.

What happens after testing?

The team updates the scenario and decides whether to run another test, do a technical experiment or move on to development.

How much does an interactive app or service prototype cost?

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.

How long does prototyping take?

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.

What is the difference between a prototype and an MVP?

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.

How many users are needed to test a prototype?

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.

Is prototyping suitable for a mobile app?

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.

Product development