A folder full of screenshots can make a project feel researched while leaving the difficult questions unanswered. You can see the spacing, colors, and components. You still do not know which choices belong in your product.
The useful output of reference research is a decision you can explain. A reference should help you choose what to do, identify what to test, or rule out an approach. Here is a practical way to make that happen without spending an afternoon collecting images.
Start with a question small enough to answer
“Find onboarding inspiration” is too open. It invites an endless scroll because almost any screen qualifies. “How should someone choose a workspace before accepting an invitation?” gives you a boundary.
Write down the user, the situation, and the uncertainty. For example:
A returning customer belongs to three workspaces. They followed an invitation link. Should we ask them to choose a workspace, or take them directly to the invited one?
This question suggests what to inspect: the invitation entry point, account recognition, workspace context, and the destination after acceptance. A polished welcome screen on its own cannot answer it.
Collect contrasting approaches
Look for three to five examples that handle the same problem differently. One might explain the destination before asking for authentication. Another might recognize the signed-in account first. A third might show a workspace switcher.
Avoid selecting only examples that resemble your first idea. If every reference supports the same answer, your collection may be a record of your preference rather than an investigation.
In Refcat, start with a task or flow search and inspect the steps around a promising screen. Save the examples worth comparing to a project. The important part is keeping the entry point and outcome attached to the interface you like.
Separate the visible pattern from its likely purpose
For each reference, write two short notes. The first describes something observable: “The invitation names the workspace above the sign-in button.” The second states your interpretation: “This may help people check that they are joining the right team.”
Keeping those notes separate prevents a screenshot from becoming evidence for an intention you cannot verify. You can inspect an interface. You usually cannot inspect the team's research, constraints, or experiment results.
Use a comparison table with four columns:
| Reference | Observed choice | Possible benefit | Risk in our product |
|---|---|---|---|
| A | Workspace name before sign-in | Clear destination | Long names may wrap |
| B | Account recognized first | Less account confusion | Shared devices need an escape route |
| C | Full workspace picker | Explicit choice | Adds a step to a direct invitation |
The final column is where reference research starts becoming product design.
Adapt for your constraints
An approach that works for a consumer app may be awkward in a team product. A flow designed for frequent users may confuse someone visiting once a year. A screen captured on iOS may rely on navigation conventions that do not transfer cleanly to the web.
Before adopting a pattern, check your users' prior knowledge, the cost of a mistake, the available data, and the behavior of the platform. Ask what would have to be true for this approach to work.
For the invitation example, a direct path may be appropriate if the link identifies the workspace reliably. You would still need a visible account switch, an expired-link state, and a clear explanation when the current account cannot accept the invitation.
End with a decision and a test
Write a small decision record:
Show the invited workspace before sign-in. After authentication, take eligible users directly to it. Keep “Use another account” available. Test whether participants can identify both the destination and the account they are using.
Attach the references that influenced the choice, including the one you rejected. That makes the reasoning easier to revisit when the product changes.
Stop collecting when the next reference is unlikely to change the decision. Open one real design question, compare a few contrasting flows, and leave with something your team can discuss. A useful reference library is a place where decisions become clearer.