Mobile app screen map: where logic diverges
A mobile app screen map is not a list of pages, but a contract between product, design, and development: which screens exist, what opens them, which states they support, and where the user returns after each step.
While the transition diagram lives in the mockup and describes only the happy path, it seems the app's navigation structure is agreed. Divergence in screen logic appears later and not where expected.
The first typical place is nested and modal branches: payment confirmation, address selection, entering a code from an email. In the mockup these are separate layers, but in the screen map they have no return point, and after cancellation the user ends up not where they started.
The second is external entries: following a link from an email or notification, opening the app after a connection loss. A transition diagram built from the home screen simply does not describe such scenarios.
The third is navigation bottlenecks inside the screens themselves.
A junction screen starts to know about five scenarios at once and decides where to go next; after that, an edit in one flow breaks the neighboring one, and the tester describes the defect as “navigation behaves strangely.”
The cost of divergence is measured not by the beauty of the diagram, but by the number of edits: one transition has to be fixed in three places, and some errors surface after release. We look at how this is closed.
What a described transition structure provides before development starts
An agreed transition structure shows, before the first line of code, how many screens the product actually needs.
Extra steps — duplicate forms, intermediate confirmations, “just in case” screens — are cut in the diagram, where an edit costs minutes rather than reworking finished code.
In our practice, the list of screens after such a review shrinks by 15–25%, and each removed screen no longer drags along a state, error handling, and a separate set of checks.
Unified logic for platforms is described once: the transition framework is set as routes with entry and exit points, and differences are reduced to navigation patterns from platform guidelines, e.g. Material Design.
Teams on both platforms implement one scenario, not two gradually diverging versions of the product: a change in structure is applied everywhere at once.
When the route and screen states — empty list, loading, network error, no permissions — are described in advance, estimation stops depending on discoveries during work. The developer receives a screen contract: what comes in, what goes out, which branches must be covered.
Development speed increases, and edits after the first release are reduced by about a third: inconsistent transitions are identified before assembly.
The result is a predictable release schedule: the number of screens and connections is known, the estimate is made up of understandable units, and the risk of changing navigation mid-work almost disappears. It is cheaper to rewrite the structure in a diagram than in a built app.
Formats for describing the structure: state table, diagram, prototype
The format for describing the structure determines what exactly the team will see: a list of screens, connections between them, or the scenario itself in action.
One product can be described by a screen state table, a transition diagram, or an interactive prototype — the difference is which errors each format catches and which it misses.
The limitations of formats are not about quality, but about when they are used. A table does not show the rhythm of the interface, a diagram does not convey failure behavior, a prototype does not describe rare branches and diverges from implementation if only it is updated.
| Format | When it fits | Limitations |
|---|---|---|
| Screen state table | Capturing logic: roles, permissions, loading and error states, transition conditions | Not readable as a whole during review; requires updating after every edit |
| Transition diagram | Checking integrity: no dead ends, every screen has an exit and a return path | Does not convey screen content and access rules |
| Interactive prototype | Testing the scenario with users: clarity of steps, form size, order of actions | Does not cover emergency branches; quickly diverges from implementation |
| Textual screen description | Handing off the task to development and support: a single vocabulary of names and areas | Becomes outdated without being tied to the table and diagram; allows different interpretations |
In practice, formats do not replace each other: the state table remains the source of truth, the transition diagram is for integrity checks during review, and the prototype is for testing the scenario. Divergence between them is the first sign that the structure needs to be reassembled.
Stages of designing an app structure and transitions
We start with inventory: we collect all screens, modals, loading and error states that exist in the app or are laid out in mockups. We assign an identifier and type to each node — this keeps the diagram readable when there are more than a hundred screens.
Then we describe transitions and conditions: what opens a screen, under what events it closes, where the system “back” button leads on each platform.
- Audit existing screens. We compare mockups, the working app, and analytics: we find duplicate screens, dead ends without an exit, places where the user loses context. We record discrepancies between platforms — often the same scenario on different systems is structured differently for no reason.
- Assembling a draft structure. We arrange screens into branches: entry and registration, core scenario, settings, payments, support, service states. We check that every action has a predictable return path.
- Aligning the diagram with product. We walk through the map together with the product owner and design: where to shorten steps, which branches to move to the next release, what is critical at launch. We resolve disputed points on the diagram, not in code.
- Checking transitions. We simulate scenarios: payment interruption, connection loss, re-entry, deep links, returning from background mode. Each such path must lead to a clear state, not an empty screen.
- Handing the structure off to development. We hand over the map with screen descriptions, navigation parameters, and priorities — the team uses it to estimate the scope of stages and does not interpret requirements in its own way.
- Keeping it up to date. We agree on who updates the diagram and when, so it does not diverge from the product after the first edits.
The screen map lives together with the product: when adding a feature, we update it before development starts. Describe the task — we will come back with an estimate and work plan.
What we hand over to the team: artifacts, diagrams, and regulations
The screen map is a working document, not an illustration for a presentation. After the work is completed, it remains with the client as a set of artifacts that a new team can use to continue development without reconstructing the logic from code. Below is what is included in the handover.
- Transition diagram: all screens, navigation branches, returns, and dead-end states, with notes on which transitions are blocked until a condition is met.
- Screen state diagrams: for each screen — loading, empty list, error, partial data, no network; exactly what the user sees in each case.
- Description of transitions and parameters: what data is passed between screens, what is required, what happens if it is missing or outdated.
- Screen naming rules: a single template according to which a screen, event, and parameter are named the same in the diagram, analytics, and code — no discrepancies arise during reconciliation.
- App structure documentation: hierarchy of sections, shared blocks, reusable states and their owners.
- Diagram update regulations: who edits the map and at what stage, how a change gets into it before development starts, not after release.
- Relationship matrix “screen — requirement — check”: it shows which paths are covered by automated tests and which remain manual.
We hand everything over in a form that is versioned alongside the code: edits are visible in history and are not lost in chat.
Case study: how transition structure reduced rework in an app
Before: navigation was assembled during development
An app with 40+ screens was designed from mockups: each screen was drawn separately, and transitions between them were thought through in code.
By the third iteration, three different return paths from the cart, two duplicate registration flows, and a modal with no way out to checkout had surfaced.
By the first build, the team had accumulated more than 60 navigation edits — some of them broke scenarios that had already been tested.
What was changed: a screen map before the first line of code
We assembled a screen map: for each screen — entries, exits, states (empty / loading / error / no permissions), modal branches, and return rules. We separately described end-to-end flows — checkout, access recovery, payment — with points where the user can leave and return.
We assembled a prototype of transitions in Figma so the return state could be checked by clicking, not by reading a description, and aligned the map before development started.
After: metrics
Navigation edits after development started — 8 instead of 60. We reworked 3 screens instead of 20: transitions had been agreed in advance, and developers did not have to reassemble scenarios on the fly.
The share of transitions with an explicitly described return state grew from 45% to 100%, so testers checked scenarios against the map instead of guessing about them.
Screen consistency rested on one document: the designer, developer, and tester looked at one source of truth instead of three interpretations. The app release timeline did not shift — the five-week delay that was predicted after the first build was not needed.
How transition structure differs from an interactive prototype
A screen map is a diagram of nodes and transitions: which screen, where users get to it from, where they go, and under what condition. It sets the scope of the product: how many screens and states, what we show when the list is empty or the connection drops. An interactive prototype answers a different question — how the scenario feels in action.
The difference is in completeness. A prototype is assembled along one “happy” path: entry, main action, result. The map covers branches — no permissions, offline, request error, empty state, deletion confirmation.
Therefore, a prototype without a map loses a noticeable share of states, and they are found in the built app, where edits are more expensive.
| Option | When it fits | Limitations |
|---|---|---|
| Textual screen map | Capturing scope, estimating timelines, setting tasks for development | Does not convey visual rhythm and hierarchy |
| Interactive prototype | Testing a disputed scenario, showing it to the client | Covers one or two paths; the rest are white spots |
| Map plus prototype of key scenarios | Regular product development | Requires two passes and synchronization between them |
The map is primary. Navigation, test scenarios, and effort estimates are derived from it, while the prototype is a derivative of the agreed structure. If you start with pictures, the structure grows out of mockups and sprawls: two similar screens live by different rules.
The prototype comes first in one case: when the dispute is about the mechanics itself, not the details, and the hypothesis needs to be tested with people. Then we assemble two or three scenarios, and restore the map afterward.
In Figma, the map and prototype live in one file, but they are different artifacts with different value.
Doubts about structure: screen duplicates, states, transitions
Screen duplicates almost never appear due to carelessness — they are generated by different entry scenarios. The same list opens from search, from favorites, and from a notification, and in the map these are different routes with different filter states.
Deciding in advance what is reused as a component and what lives as a separate screen with its own context is cheaper than later fixing diverging twins separately.
The second point of tension is screen states: empty list, loading, network error, partially outdated data. In the diagram they are described as branches of one screen, and return transitions lead back to where the user came from — otherwise navigation has to be redone at release. Below are doubts that most often surface before starting work on the structure.
We already have an app. Will the map have to be assembled from scratch?
No. We capture the current structure as it is: we go through screens, record transitions and states, and mark duplicates. Then we fix things point by point — usually this means merging duplicate screens and a unified contract for navigation parameters.
Who is responsible for return transitions and system gestures?
Navigation is recorded in the map as a rule, not a wish: for each screen it states where return leads and what happens to saved state. We describe behavior when a scenario is interrupted in the same way — a call, minimizing, connection loss.
What will happen to the structure after release?
The map remains a working document: a new screen or state branch first appears in it, then in code. This keeps navigation from sprawling and allows a duplicate to be seen before it gets into the build.
Let's discuss the task and come back with an estimate and plan
To come back with an estimate and work plan, we need inputs: a list of screens in any form — table, screenshots, sketches — a description of user roles, and access to the current prototype or repository. That is enough to analyze the current state and not rewrite what already works.
As a result, you get:
- an analysis of the current state: which screens duplicate each other and where transitions lose user context
- a screen map with roles and states — empty, loading, error, no network
- a navigation diagram with return points and exits from dead-end branches
- a list of screens to merge and those that actually need to be added
- an estimate and stage-by-stage work plan: order, dependencies between screens, checkpoints
- rules for maintaining the app structure — how a new screen fits in without breaking navigation
- team composition and reporting format throughout the work
The estimate is based on your scope of screens and scenarios, not on average figures: externally similar apps differ in the number of states by multiples.
If some inputs are missing, we will analyze the product together with your team and assemble a screen map based on your scenarios.
Describe the task — we will come back with an analysis, estimate, and work plan.