UI Style Guide: What to Include and How to Apply the Rules

A UI style guide makes recurring visual decisions explicit: which type styles to use, what colors mean, how much space elements need, and how components behave. It gives designers and developers a shared reference instead of leaving each screen to individual interpretation.

Consistency is the starting point, not proof of accessibility or usability. A guide also needs rules for contrast, readable text, keyboard focus, and component states, which the team must check in the implemented product.

Start with the decisions your team repeats most often. A small guide grounded in working screens is more useful than a large collection of swatches with no explanation of when to use them. Connect those rules to the reusable assets in your Pixso design system, so the written guidance and the components can be reviewed together.

Part 1. UI Style Guide: What is it?

Your style guide should inform design decisions. Cover typography, color, spacing, layout, components, and interface language, with examples of appropriate use. A new teammate should be able to find the right pattern and understand its limits without guessing from a polished screenshot.

Part 2. What Sections Should Be Included in a UI Style Guide?

There is no one-size-fits-all style guide. Its scope should reflect the product and the team’s needs. A template can organize existing colors, text styles, and components, but it does not automatically explain usage, accessibility, or exceptions. The following sections provide a practical starting point.

1. Typography

Document typefaces, sizes, weights, line heights, and intended roles: page title, body copy, field label, and supporting text. Show long labels and realistic paragraphs as well as short samples. Include font fallbacks and check that supported languages have the required characters.

2. Color palettes

Specify colors by purpose, not only by hex value. Distinguish primary actions, ordinary text, borders, errors, and selected states. Show foreground–background pairings and their contrast requirements. A color that works for a large heading may not work for small supporting text.

3. Layouts

Record spacing values, alignment rules, content widths, and how layouts adapt when space changes. Show the same screen with a narrow viewport and long content. These examples explain where a rule should flex instead of encouraging designers to copy a fixed-width composition.

4. Components

Show components in the states people actually encounter: default, hover where relevant, focus, selected, disabled, loading, and error. Explain labels and behavior alongside appearance. For example, a disabled button and a loading button may both prevent another submission, but they communicate different reasons.

The icon sheet above illustrates consistent sizes and visual variants within one asset family. A complete component guide also needs interaction and feedback states, such as the invitation-form example below.

Part 3. How to Create a UI Style Guide

Begin by auditing a few representative screens. Gather repeated text styles, colors, spacing values, and components, then identify accidental variations. Choose a consistent rule for each and document why it fits the product. Use a template as a container for these decisions, not as evidence that the guide is complete.

Try the proposed rules on a realistic prototype before extending them across the product. A button style may look clear on its own but fail with a long translated label or an error message beside it. Review those cases with designers and developers, record agreed exceptions, and name an owner for later changes.

A mini style guide for inviting a teammate

Consider an invitation form with an email field, a role selector and a “Send invitation” button. The design team has three similar screens with slightly different labels, spacing and error styles. A useful guide defines what the shared pattern means, then shows it in the actual screens that use it.

Example spacing values might start at 8 px between label and control and 24 px between field groups. These are proposed values for this form, not accessibility requirements or a universal scale. Apply them to real content, then decide whether they produce the intended grouping. Record the chosen values as named decisions instead of leaving different unlabelled gaps on each screen.

Write the state rule, not just the state name

For an empty email field, the example message is “Enter an email address.” For an address already on the team, it is “This person is already a member,” with a link to their member entry when appropriate. A service failure needs a different message and retry route. The guide should not tell every form to display “Something went wrong” simply because the same red component is available.

Document what remains after a failed submission: keep the entered address and selected role so the person can retry or correct them. The visual loading state is not proof that an invitation was sent. Confirmed success must follow the application’s result, and retry behavior must be agreed with development.

Show the form after text enlargement and spacing changes in implementation as well as in the design file. WCAG’s text-spacing guidance concerns preserving content and functionality when users change spacing; it does not require every design to use those test settings by default.

Resolve an exception without creating a second standard

A compact member-list row may use a smaller “Invite” action than the full form. Record that as a specific variant with a defined location, rather than making an unnamed local button. If the label or action differs, explain why. A small table can track the component, approved variant, screen that demonstrates it and person responsible for the rule.

When changing the field height, inspect the invitation form, account settings and any compact dialog that uses it. Update the shared asset and the usage note together, then check affected instances and implementation. A library change and a deployed application update are separate events. Keep the decision and adoption status visible so two conflicting examples do not both look authoritative.

Part 4. 5 Best UI Style Guide Examples

Many style guides are publicly available, so it might be that a brand or app you love can, with a little search, be your inspiration. If not, here are five style guides to check.

1. Mozilla

Mozilla is useful as a historical example of coordinating a recognizable identity across interfaces. Treat Firefox OS material as an archive, not a current smartphone platform: Mozilla announced the end-of-life plan for its smartphone project in 2016. Study the structure of the guidance rather than copying obsolete platform rules.

2. Apple Human Interface Guidelines

Apple’s Human Interface Guidelines illustrate how platform guidance connects interface elements with behavior. They are broader than a brand palette. Use them to understand relevant platform conventions while documenting your own product-specific decisions.

3. Yelp

Yelp’s Cookbook connects foundational styles with components, templates, and pages. Its examples include badges, buttons, ratings, and selections. This makes it useful for studying how typography and color rules become reusable interface patterns. Apply that relationship to your own guide rather than copying Yelp’s visual identity.

4. Salesforce

Salesforce’s Lightning Design System guidance explains how custom Lightning components can remain consistent with the surrounding Salesforce interface. It distinguishes shared styles from supported variations and customization methods. For a team extending an existing product, this is a useful model: document what must stay familiar and where a component can be adapted, rather than treating every visual detail as freely editable.

5. Spotify

Spotify’s design and branding guidance addresses products that integrate its content. It is useful for understanding how a guide can explain constraints and their context. Do not confuse an integration guide with a complete internal UI system, or apply its brand requirements to unrelated content.

Part 5. Build and Review the Guide in Pixso

Use a Pixso file to put foundations beside the screens that depend on them. Create sections for typography, colors, spacing, and components, then place a real form or settings screen next to each relevant example. Reviewers can see what a proposed rule changes.

Pixso provides a shared design workspace for this review. Compare component states, discuss unclear rules, and keep usage notes next to the design. A library asset and a written rule serve different purposes: the asset supports reuse; the rule explains when reuse is appropriate.

For example, place a normal input, an error state, and a long translated label in the same review area. Ask the team to check spacing, contrast, and wording together. Record the decision in the guide so the next screen does not reopen the same question.

Conclusion

A useful style guide removes uncertainty from repeated decisions. Begin with the patterns your team already uses, explain their behavior and limits, and revise the guidance when implementation exposes a missing case.

In your next Pixso review, choose one common component and document its states beside a realistic screen. That is a concrete foundation for a guide the team can use, rather than a document that only looks complete.