Why a static mockup does not replace an interactive prototype
A static mockup shows how a screen looks, but not what happens between screens. An interactive prototype answers the second question: it brings together scenario validation — from first launch and authorization to payment and going back.
Without this, disputed transitions are discussed in words, and each participant imagines them differently.
This is most costly when it comes to screen states. An empty list, network error, a role lacking permissions, repeated form submission — on a static mockup they simply do not exist, and they surface during the build, when navigation is already hardwired.
Then any edit drags along neighboring screens and rewritten checks, and the scope of rework grows with each connected transition.
Our engineers put it this way: “A transition that costs one edit on the prototype costs a navigation rework and three neighboring screens in the build.” That is why we assemble transition logic and states in Adobe XD as a working scenario with live transitions — so it can be clicked through, not just viewed.
Scenario validation on a prototype is not “sign-off on pictures,” but the first run of logic: where the user gets stuck, what states are missing, how role-based access works. Next, we'll look at how this is addressed in development.
What changes in the project before development starts
An interactive prototype is assembled before the first line of code: screens are linked by transitions, button states, modals, and role branches.
Sign-off is based not on static mockups but on a clickable scenario — the client goes through the path “login → action → result” and sees exactly the screens that the user will see.
The prototype in Adobe XD is assembled on the same layers as the mockup, so changing the scenario does not require rebuilding the document from scratch.
Speed of decision sign-off
A dispute about wording or element placement is resolved by running the scenario in a couple of minutes, not by several days of correspondence.
Sign-off timelines compress from multi-day cycles to one or two runs: decisions are made at the meeting while the prototype is open, and do not go into a new round of mockups.
User roles are checked immediately — you can see what is available to an administrator, to a regular user, and to a guest, and where permissions overlap.
Fewer edits after handoff to development
Navigation errors — dead-end transitions, lost back paths, buttons with no reaction — are caught during the run, not in the assembled app.
The number of edits after handoff to development falls: an edit in the prototype takes minutes, while the same edit in code means reworking the screen, logic, and checks.
Readiness for development becomes measurable: scenarios are passed, states are described, edge cases and empty screens are recorded.
Interactive prototype: modes and depth of detail
A prototype is not a single format but a scale: from a set of static screens to a connected scenario that runs on a phone from launch to the target action.
Prototype modes are chosen for the question being validated at a given moment: composition, user route, or interface behavior on real data.
| Option | When it fits | Limitations |
|---|---|---|
| Static screens | Sign off composition, copy, hierarchy | Transitions are not visible; navigation dead ends surface in development |
| Linked screens without states | Validate route and return points | Loading, empty, and error states are not checked |
| Linked scenario with transition animations | Testing with people, disputed interface areas | More expensive to maintain: edits are also made synchronously in the mockups |
Depth of state detail
Limiting yourself to the “happy path” is risky: an empty list, loading, network error are half of the product's screens. In the prototype they are set as separate states of one screen, and captions, button sizes, and going back are checked on them. Transition animation here works not for beauty, but to assess whether the user loses context.
Where prototype ends and development begins
The prototype answers “how it works,” but does not describe markup, timings, or failure handling at the code level. We record confirmed states and transitions in the specification — from that point the scenario becomes a development task, not a mockup.
Procedure for assembling prototype and validating scenarios
An interactive prototype is not assembled “by eye” but along a route where each stage has an input, a result, and a readiness criterion. Below is the workflow from the initial task review to acceptance.
- Task and role review. We record who uses the app, what tasks they solve, and what constraints matter — authorization, offline mode, access rights. The output is an agreed list of scenarios that the prototype must cover.
- Screen map. We assemble a list of screens, their states (loading, empty, error), and transitions between roles. The map is agreed before drawing: an edit here is cheaper than rework after assembly.
- Assembling links. We configure transitions, modals, back actions, and the behavior of the system “Back” button. Every active area leads where the user expects it, including edge branches.
- Scenario run. We walk through the prototype on real data: long names, large numbers, empty lists. This surfaces truncated captions and dead-end transitions that are invisible on static mockups.
- Handoff and training. We show the team how to open the file, change copy, and add states so edits do not wait for us.
- Result acceptance. The client walks the key paths themselves using the scenario checklist and confirms readiness.
How we record the result of each stage
After each step an artifact remains: an agreed map, an assembled prototype, a list of found edits. This allows returning to any point in the route without retelling and bringing the prototype to a working interface.
Set of materials the client keeps
We hand over not a folder of pictures but a working set that development can continue without us. Everything is in the design environment and project repository: with change history, edits tied to date and author, no “final_version_2.”
- Prototype file — source with all screens, components and states: editable layers, not a set of static snapshots.
- Transition and state map — diagram of links between screens: which action leads where, where logic branches, what the loading screen and empty list look like.
- Role-based access rules — “role → screen → action” matrix: what a guest, authorized user, support agent, and administrator see.
- Edit policy — procedure for making changes: who signs off, what counts as a new iteration, how a rejected option is recorded.
- Scenario documentation — step-by-step description of user paths with the expected result and behavior on network and service failures.
- Instructions for the development team — mapping screens to business logic, requirements for field states, list of mandatory checks on the application side.
Documentation structure and its media
Materials are divided into living and reference. Living — the prototype file and transition map: they change together with the mockup, so they are stored in the design environment, not exported as archives.
Reference — edit policy, access matrix, scenario descriptions: they live in the project repository next to the code and are updated by versions.
The acceptance criterion is simple: an engineer who did not participate in the project deploys the prototype, walks the main scenario using the map, and takes the first screen into work without additional explanations. If this requires a call to the author — the set is incomplete.
How prototype affected timelines and number of edits
Client — grocery delivery service Корзинка: two platforms, a release every two weeks, and a constant race between design and development. An interactive prototype was assembled, but only as a demo for management: it did not match what went into the build.
Initial situation
Assembling one prototype took 8–10 days, and a quarter of the time went to redrawing screens after edits. The states that the user encounters most often — empty list, connection loss, action confirmation — were not shown in the prototype.
Therefore edits surfaced after release: four out of ten refinements in the first release concerned navigation and unclosed states, not logic.
Result after scenario validation
We reassembled the prototype as a set of linked scenarios: every transition, failure, return, and intermediate state became a separate screen with real behavior. Assembly time dropped from 9 to 4 days — a screen is reused between scenarios, and an edit lives in one place. At acceptance we checked 30 scenarios instead of 12, before any code was written.
After implementation, the share of post-launch edits dropped from four out of ten to one, and the first release shipped without postponement.
Client feedback: “Scenario review before code removed the main pain — we stopped arguing about how it should work already at the assembly stage.”
How to validate screen logic when design is already approved
Yes, scenario validation can be restored even on an approved style. An interactive prototype is assembled on top of the approved design: mockups are not redrawn; transitions, states, and return logic are added to them. Behavior is checked, while the visual layer remains what was approved.
The validation procedure does not depend on the stage of work. First the screen map and entry points, then the main paths to the goal, then the states of each screen — empty, loading, failure, partial data.
Finally interruptions: going back, backgrounding, re-entering, canceling an action midway. Each path is run as a sequence of taps.
Rework of scenarios on coded screens is limited to navigation and reusable blocks. An extra step is removed by changing a transition, not markup; a missing state is added to an existing template. Edits remain local, so the layout does not fall apart.
Rework risks grow not from validation but from its absence. A late find — a conflict between two flows or data loss on return — drags along rewriting linked screens and repeat acceptance. Approved design does not cancel such a find: the style is correct, but the scenario is not. Therefore we fix the validation order before coding new screens and repeat after each refinement.
An interactive prototype remains a working document: it shows where logic diverges from expectations, and an edit costs a few transitions, not a new sign-off cycle.
Common technical questions before starting work
Before starting, clients ask roughly the same questions — about scope, access, and result acceptance. Below are our engineers' answers without generalities.
How many scenarios should be included in an interactive prototype?
Usually 3-5 key paths: first launch, main action, request or payment, return to an unfinished action, access recovery. Within a path we link screens with transitions and states — empty list, loading, error. If more are needed, we split into stages and validate the hypothesis on the main scenario.
How much is our team needed in the work?
At specific points: one person who knows the product and confirms the logic in short reviews. We assemble and run the prototype ourselves, and bring you the finished result for review — without daily calls.
What are the limitations of the prototyping tool?
The tool covers transitions, states, overlays, and scrolling, but does not show real network, payment, and notification behavior. The prototype answers logic and navigation questions, while behavior under load is checked during the application build.
What access do you need from us?
Mockups, if the interface is already designed, and a test environment or real data export. If there is no access, we start on approved mockups, but some scenarios will remain assumptions.
How do we accept the result?
The criterion is passing the agreed scenarios on a device: transitions, returns, states. We fix the list before work starts, and acceptance follows it; discrepancies are reviewed and edits are closed.
Let's discuss your task and come back with an estimate
The initial task review takes one conversation, but the entire scope estimate depends on it.
We do not count “screens in a vacuum”: an interactive prototype is assembled for specific scenarios, so first we clarify what exactly needs to be validated before development — navigation logic, transitions between states, or interface reaction to input errors.
- Goal: which user scenario should become clear to the team and the client based on the prototype results.
- Audience and roles: who opens the app and in what context, which screen states are critical for them.
- Scenario composition: main path, dead-end branches, empty and error states.
- Input data: artifacts and materials from previous iterations, copy, visual requirements, platform constraints.
- Platforms: iOS, Android or both, whether adaptation for tablets, dark theme, and different screen sizes is needed.
- References: examples of apps whose behavior you like or categorically dislike.
- Checkpoints: by what date the prototype is needed for a demo and who accepts the result.
After the review we come back with a work plan and scope estimate: which scenarios we cover, how many link iterations we include, what is included in the handoff to the development team.
Once the composition is agreed, the project starts from the prototype, not from a static mockup, so disputed areas in logic surface before the first lines of code.