Material Design 3: why layout diverges from the mockup
A mockup in Material Design 3 is not a picture but a set of rules: color roles, typographic scale, grid step, component states. While the screen lives in the editor, everything matches.
The divergence begins where the rendering of Android screens reproduces only the "ideal" state of an element, and draws the rest by intuition.
States of buttons and fields are the first point of divergence. An input field has rest, focus, filled value, error, disabled; a button has rest, pressed, held, disabled, waiting for response.
If only the rest state is drawn in the mockup, the developer selects shades and stroke thicknesses themselves, and on a live screen the error hint looks different from the prototype.
Second — spacing. The designer aligns to the optical center, the engineer — to a numeric value. Without a common multiple scale and without size tokens tied to roles, gaps between blocks start to diverge, and the heading "floats" relative to the caption.
Third — the adaptive screen grid. A small screen compresses columns, a large one adds a second panel; meanwhile long button labels wrap to two lines, and fixed heights cut off text.
The difference is visible not in the editor but on devices — and edits after that are more expensive than a grid laid down from the start.
Next we analyze how to link states, spacing, and grid so that the finished screen matches the mockup on the first build, not after a series of reworks.
A unified component library: what it speeds up
While screens are laid out separately, each new section pulls along newly assembled buttons, fields, and lists.
After two or three releases, the app contains three different spacings, two loading behaviors, and four variants of the same card — and a mockup edit turns into a revision of the entire interface.
Speed of assembling a new screen
A library based on Material Design 3 is components with pre-described states: colors, typography, and spacing come from a single source, rather than being selected for each mockup.
A new screen is assembled from ready-made blocks: for us, a typical catalog or profile section goes from mockup to build in 1-2 days instead of a week, and layout edits after review become about three times fewer — one component changes, not ten of its copies.
A unified set of states
Loading, empty list, network error, offline, and slow response are described once and inherited by all sections.
The engineer does not reinvent behavior on each screen but plugs in a ready one — the share of reused blocks in new code reaches 70-80%, and the regression area after improvements remains local.
For release timelines, this gives predictability: an update with a new section goes into release in one cycle, rather than stretching over several iterations of layout approval.
Methods of screen rendering: comparison of approaches
The rendering method determines not the appearance but which platform requirements are covered by ready-made tools and which the team carries for years.
Below are four interface rendering options among which people actually choose at the start or when rewriting screens under Android platform constraints.
The boundary runs along the line of "ready-made system behavior versus our code": the further from system components, the greater the freedom and the more expensive the maintenance — accessibility, gestures, dark theme, and behavior when screen density changes stop updating on their own.
| Option | When it fits | Limitations and maintenance cost |
|---|---|---|
| Platform system components (Material Design 3) | Product scenarios where predictability, accessibility, and updates together with the system matter | Style is set by the platform, hard to stand out; some states and transitions have to be assembled from ready-made blocks |
| Own component library | Recognizable style, many similar screens, several products on a common foundation | The entire cycle is on us: accessibility, dark theme, transitions between system versions; the amount of work grows with each platform branch |
| Cross-platform interface | One team and shared logic on Android and iOS, timelines more important than platform precision | Custom gestures and system transitions feel different; support for new platform capabilities arrives with a delay |
| Hybrid screens | Rapidly changing content, forms, sections with frequent edits inside a native shell | The junction of navigation and gestures is synchronized manually; on weak devices, responsiveness drops are noticeable |
In practice, a combination wins: a native framework and system components for key scenarios, hybrid screens for content that changes every week. We fix the boundaries before development and verify on a prototype so as not to revisit the decision after several releases.
Implementation stages: from screen audit to handoff to the team
Implementing a design system is not "repainting buttons" but a sequence of steps where each result is verifiable. We start with an inventory of what already lives in the app, and finish with a library that the client's team works with without us. Below is the order of work as we conduct it on projects.
-
App interface audit. We collect all screens and states, mark homemade buttons, fields, dialogs, and navigation, and count how many variations of one element are duplicated in the markup.
The output is a map of divergences and a list of what goes into the system and what remains a local exception.
-
Component scheme. We reduce repetitions to a base set: button, input field, card, list, dialog, navigation panel. For each, we describe states — normal, pressed, disabled, loading, error — and nesting rules with spacing so that new screens are assembled without inventiveness.
-
App theme setup. We move colors, typography, radii, and shadows into a single layer of values: light and dark schemes are described by meaning — "surface", "accent", "error" — rather than specific shades. Changing the palette becomes editing one set, not going through hundreds of screens.
-
Library assembly. We implement elements as reusable modules with a single entry point: appearance and behavior come from the theme, screen layout from components. This way a system update arrives in all apps at once.
-
Phased replacement on live screens. We do not rewrite the app entirely: we migrate screen by screen, releases continue to ship, and rollback to the previous build remains possible.
-
Testing on real devices. We run on a device fleet: different screen sizes and densities, system versions, dark theme, enlarged system font, navigation gestures. We look not only at appearance but also at the smoothness of scrolling long lists.
-
Handoff of the library to the team. Documentation on components, live examples, rules for adding a new element, team training — after that the client leads the system, and we join on a spot basis.
Work results: component library and documentation
The result of the work is not a set of laid-out screens but a portable interface layer that your team develops without our participation.
Everything listed remains in the app's code repository and in accompanying documentation, so a new developer joins the edits according to instructions, not from the previous contributor's memory.
- Component library for Android — buttons, input fields, cards, lists, dialogs, navigation, and loading states are assembled into a separate module. A screen is assembled from ready-made blocks, so the same element does not diverge in spacing and behavior across different screens.
- App theme — colors, typography, corner radii, shadows, and grid step are moved into common value sets on top of Material Design 3. Changing the brand shade or interface density is done in one place and spreads across all screens at once.
- Element state rules — for each component, it is fixed how it looks and behaves at rest, when pressed, in focus, during loading, on error, and when data is unavailable. This removes the inconsistency that makes identical lists on different screens react differently.
- Interface documentation — a component catalog with usage examples, limitations, and anti-patterns: where a block must not be used and what to replace it with.
- Layout edit regulations — the procedure for changing a common component: who approves, how the impact on already released screens is assessed, in which cases an edit goes into a separate block rather than the common one.
- Team instructions — how to set up the project, where theme values are stored, how to add a screen using a template, and what checks are performed before release.
This composition removes the main maintenance risk: an edit in one place does not break neighboring screens, and interface expansion comes from ready-made blocks, not new layout from scratch.
At acceptance, this is verified live — we change a component and show the result on all screens where it is used.
Case study: a unified component library for frequent releases
Before: every screen was assembled anew
A product with weekly releases and several teams in one codebase. Every new screen was laid out from scratch: spacing, radii, button states, and field highlighting on error were set anew.
Assembling a typical screen took 3–4 days, and about half the time went into aligning to the mockup after the first review. Design review consistently returned 12–15 divergences per screen, and repeat edits came after release.
After: a shared component library
We described repeating elements once — themes, color and typography tokens, component states: normal, pressed, loading, error, empty list. We took the current branch of Material Design 3 as the foundation so that grids and behavior match across all teams.
Assembling a new screen turned into a composition of ready-made blocks and took 1–1.5 days. Divergences from the mockup at review remained 2–4, and almost all were about patterns that were not yet in the library.
What changed in metrics
After several releases, the share of repeated interface edits after a version release fell by about three times, and defects like "button of a different size" or "field does not highlight an error" stopped reaching users.
The library is versioned separately: the team updates it and gets verified components immediately across all screens, without manually going through mockups.
Material Design or your own design system: what to choose
The choice comes down to who pays for the rendering. Material Design provides ready-made components, pressed and focused states, light and dark theme, gesture behavior, and accessibility — this is already debugged, and the team does not spend weeks reinventing it.
Limitations begin where the brand requires its own: grid, typography, button shape, transition animation.
The system allows theme and some settings but does not change component logic — component customization turns into a layer of overrides that must be rechecked with each platform update.
| Option | When it fits | Limitations |
|---|---|---|
| Material Design 3 | standard scenarios, quick start, internal services | brand dissolves in system aesthetics; deep edits run into component behavior |
| Own design system | strong interface branding, multiple platforms, repeatable scenarios | needs a system owner: tokens, versioning, review, migrations |
| Hybrid | core on the system, own layer on top | the boundary between own and system constantly shifts |
The practical rule is simple: if unique screens are less than a third — take the system and customize the theme.
If more — calculate the cost of maintaining a design system: it pays off over the long haul and across several products but requires a dedicated owner and an update process. In the project breakdowns below, we show how this choice looked on real apps.
Platform limitations and common layout doubts
The platform itself sets the boundaries: screen density varies threefold, some devices run in dark theme, users have system font scaling enabled, and system components change appearance with every major update.
Therefore we build layout not on fixed values but on theme tokens and adaptive grids — then the interface remains predictable regardless of device model.
Below are the doubts that most often come up at acceptance and how we address them technically. Each answer relies on Material Design 3: the specification sets unified rules for sizes, contrast, and component states, so there are noticeably fewer disputable points in layout.
How does the interface behave at different screen sizes?
The layout is tied to width breakpoints: on compact screens, blocks go in one column, on wide ones — in two, and the list is supplemented by a side panel. There are no fixed spacings, so the layout does not break on either foldable devices or tablets.
Is a separate mockup needed for dark theme?
Dark theme is not a color inversion but a separate set of roles: background, surfaces, accents, states. We describe the palette semantically, so switching the system theme is picked up on the fly, without a second layout set.
What is included in interface accessibility?
Labels for controls, focus order, minimum touch targets, text contrast, and support for enlarged system font. We check not by eye but by running through an accessibility requirements checklist and screenshot comparison of screens.
What happens when the platform updates?
Components inherit from system ones, so new rules for spacing, shadows, and animations are applied automatically. There are a minimum of custom elements — this removes a whole class of breakages after a major system update.
Let's discuss the task: what we need from you to start
To estimate screen rendering, a full package of project documentation is not needed — a few artifacts are enough. From them we calculate the scope for each screen and come back with a work plan for the app, not with a range "from and to".
- Source mockups with layers, styles, and components, not flat images: from the components it is clear what is reused and where each screen is assembled anew.
- A list of screens with states: loading, empty list, network error, offline, limited rights. Each undescribed state is a separate scope for rendering.
- Read access to the repository or an archive of the working branch: we look at the module structure, theme, and how design system elements are connected.
- A list of devices and system versions that we support, including the minimum. The available set of Material Design 3 components depends on this.
- Navigation scheme: where there are nested flows, where dialogs and bottom sheets are, and what happens when going back from each screen.
- A link to the current build or behavior recordings if the transition logic is not described in text.
Sending everything at once is not necessary: mockups, a list of screens, and access to the code are enough for an estimate. Full handoff of mockups and the repository goes in parallel — it is needed for the start, not for the estimate.
In return, you get an estimate of interface work broken down by screens and states and an app work plan with release sequence.