Start with a common customer task
Imagine a Budapest equipment rental business preparing a website and app for event organisers. A customer assembles a list of equipment and requests a quote. On a laptop, comparing several items may benefit from a table; on a phone, a compact list may be easier to use. Both should describe the same equipment and requirements.
Write a short behaviour specification before reviewing polished screens: which accessories are compulsory, what the quantities mean and when a draft becomes a submitted request. If the app calls a draft “confirmed”, a matching logo cannot repair the misunderstanding. These are proposed rules for this hypothetical service, not claims about an existing client.
Share meanings before copying components
Ask for a small catalogue of shared design decisions. Named values, often called design tokens, can describe the brand colour, text roles, spacing and the appearance of warnings. Names such as “primary action” explain why a value exists; “blue button” says less about its purpose. Include the meaning and an example beside each value.
The catalogue should also cover common wording and states. A quote draft, a request awaiting review and a completed request need agreed labels. Shared components can reduce repeated work, but adapting a complicated universal component may cost more than maintaining two straightforward controls. Reuse should make future changes easier to understand.
Allow differences customers can use
React Native supports separating implementations by platform. Android guidance also encourages layouts suited to different displays. For the rental example, the desktop table and phone list can therefore serve the same task without sharing every visual detail.
Specify what Back does, where an unfinished quote remains available and how customers reopen an equipment detail. Review keyboard use on the website and touch interaction in the app. Android accessibility guidance also recommends alternatives to gesture-only actions. In this example, removing an item should have a discoverable control even if a swipe shortcut is offered.
Make differences visible to the team
Keep a comparison sheet with the customer task, shared rule, web treatment, app treatment and person responsible. A difference should have an explanation: the table supports comparison, while the phone list leaves more room for each item. An unexplained difference in required accessories is a defect to investigate.
When changing a shared rule, identify every affected screen before release. Record the rule version and any temporarily unsupported behaviour. If only one platform is ready, decide whether to postpone that change or clearly limit its availability. A shared design file alone does not keep separately released products aligned.
Use this checklist at the next review
Start with the quote journey and repeat the review whenever its rules change. Ask the team to demonstrate the following evidence on working versions of both products.
- Use the same sample equipment and quantities; compare requirements and state labels.
- Trace each shared colour, text role and warning to an agreed definition.
- Try navigation, item removal and returning to an unfinished quote on each platform.
- Record intentional differences, unresolved mismatches and who owns the next change.