Several attractive screens do not automatically form a design system. They may use different spacing scales, unrelated component rules, and patterns optimized for different products.
References are useful for studying relationships: how hierarchy is expressed, how actions are prioritized, and how components respond to state. A system emerges when you turn those observations into explicit rules that fit your product.
Choose a bounded area
Start with one part of the interface, such as account settings or project management. A bounded area gives you repeated components and related tasks without requiring you to define the whole product at once.
Collect a few flows that address similar needs. In Refcat, keep the examples in a project and include the screens around important actions. A card by itself tells you little about how it behaves when selected, edited, or placed in a dense list.
Write down the product constraints before extracting patterns: supported platforms, typical content length, density, user roles, and accessibility requirements. These constraints help you decide which observed choices are relevant.
Inventory roles before appearances
Instead of beginning with “rounded card” or “blue button,” identify the jobs the elements perform. You may find a primary action, a destructive action, a navigation item, a status indicator, a form field, and a container for related settings.
The same visual treatment can serve different roles across products. Conversely, one role may need several appearances in your own product. Naming the role first helps you avoid building a component library from surface resemblance alone.
For each role, record its content, states, interaction, and relationship to other elements. A primary action needs a rule for when it appears and how it behaves while pending, not merely a color and height.
Look for relationships you can test
Study the hierarchy between page titles, section headings, labels, and supporting text. Compare the spacing within a group with the spacing between groups. Notice which information is emphasized and which is deferred.
Turn those observations into candidate rules: “Related controls share a container,” “Each section has one clear action,” or “Supporting text explains consequences before confirmation.” These rules can guide several screens even when the visual style changes.
Avoid claiming that a reference reveals its original token values. A screenshot may show an apparent spacing relationship, but rendering scale and capture size can make precise measurements misleading. Treat extracted measurements as starting hypotheses and check them in your own files.
Build your own small token set
Choose a restrained set of spacing, typography, color, radius, and elevation values for your product. Give them names based on their use where that improves clarity: surface, border, muted text, critical action, and selected state.
Document the difference between a raw value and a semantic role. A particular orange may be a palette value; “primary action” describes where a color is used. That distinction makes future changes easier to reason about.
Apply the tokens to three representative screens: a content-rich screen, a form, and an empty or error state. If the system only works on the cleanest mockup, it needs another pass.
Define components with variation limits
For each component, specify the variants you actually need. A button might support primary, secondary, and destructive roles, along with disabled and pending states. A status badge may need a text label so meaning is not carried by color alone.
Include long content, small viewports, keyboard interaction, and focus states in the review. A flexible-looking component can still fail when a translated label wraps or an error message appears.
Keep exceptions visible. If one page needs a special layout, decide whether it reveals a missing system rule or is a legitimate local exception. Adding a new global variant for every exception can make the library harder to use.
Preserve the reasoning
Attach references to the decisions they influenced, with notes explaining what you adapted and why. Credit sources appropriately and respect rights when importing or sharing their assets.
Your final artifact should contain tokens, component rules, representative screens, and the unresolved questions. It should also be recognizably suited to your product's content and behavior.
The reference is a source of questions and examples. The system is your team's answer to the constraints you actually have.