Two screens can solve the same problem and still belong to very different journeys. A mobile account page may rely on a previous tab selection. A web account page may be opened directly from an email. Similar layouts do not guarantee similar context.
Cross-platform reference research works best when you compare the job first and the interface second. This helps you transfer useful ideas while preserving the navigation, input, and state expectations of each platform.
Define the shared job
Choose a concrete task such as changing a payment method, recovering a password, or filtering a product list. Write the starting condition and the successful outcome.
For example: “A signed-in customer needs to replace an expired card without changing their subscription.” This gives you a common basis for comparison even if the iOS, Android, and web interfaces use different structures.
Avoid comparing a mobile first-run flow with a mature web account simply because both contain a profile form. Their users may have different knowledge and different reasons for being there.
Label the platform and the captured state
Keep platform labels attached to your references. In Refcat, use the platform information in search and inspect the surrounding flow before saving an example.
Add your own context when it matters: approximate screen width, signed-in state, keyboard visibility, and whether the screen appears in a modal or a full page. Record unknown details as unknown rather than guessing from the visual style.
A screenshot cannot establish every interaction. If a gesture, back action, or focus behavior matters to your decision, verify it in a working example or prototype. Do not let a visual reference stand in for behavior you have not observed.
Compare transitions, not just components
For the payment-method task, inspect how the person enters the flow, edits the details, confirms the change, and returns to the account. Then inspect cancellation and failure.
A mobile flow may spread the task across several screens. A web flow may keep the form and explanation together. Neither structure wins by default. Compare what each step helps the person understand and what information remains available when they need it.
Pay particular attention to return paths. A person who opens a direct link should still understand where they are. A person who cancels should return to a meaningful state. A person who receives an error should have a clear way to recover.
Separate product rules from presentation
Make two lists. The first contains rules that should remain consistent: which account is being changed, what information is required, when a change becomes effective, and what confirmation is needed.
The second contains presentation choices that may differ: navigation placement, form grouping, dialog versus full-page layout, and where supporting explanation appears.
This separation prevents a cross-platform design system from forcing identical screens where the context is different. It also helps engineering identify the shared domain behavior behind several interfaces.
When platform conventions influence a choice, consult the current platform documentation during implementation. A captured reference is a useful example, but it is not a substitute for the platform's accessibility and interaction guidance.
Build a scenario matrix
Use a compact table to make gaps visible:
| Scenario | iOS | Android | Web |
|---|---|---|---|
| Enter from account | Reference available | Reference available | Reference available |
| Open a direct link | Needs verification | Needs verification | Reference available |
| Save with an error | Missing state | Reference available | Missing state |
| Cancel without changes | Reference available | Missing state | Reference available |
“Missing state” is a research finding. It tells you where the collection cannot yet support a decision. Do not fill the cell with a guess just to complete the board.
Adapt the decision for each destination
Finish with shared behavior and platform-specific proposals. For example, all versions may require a clear account name and successful-save confirmation, while each uses a navigation structure appropriate to its destination.
The goal is a coherent product across platforms. Keep the user task consistent, let the presentation respond to context, and document the assumptions that the reference could not answer.