UI Guideline for component naming and design system references

What is UI Guideline?

UI Guideline (uiguideline.com) is a research-driven reference that consolidates how leading design systems define and document UI components. It presents component names, anatomy, and practical patterns by reviewing multiple systems and synthesizing common approaches into one place. Teams use it to reduce audit time when defining component specs, naming conventions, and implementation expectations. The platform also highlights systems, Figma kits, and paid resources depending on its current catalog. This Uwarp page embeds the public site so you can compare component standards while working in your broader design system workflow.

What you can explore

Useful paths when standardizing component decisions.

1. Consolidated component references: Review summarized patterns for common UI components without auditing many systems one by one.
2. Naming and anatomy guidance: Compare alternative component names and structural parts to align design and engineering vocabulary.
3. Cross-system pattern research: Use synthesis from top design systems as a baseline before defining your own component spec.
4. Systems and kit discovery: Explore related design systems and kits listed on the site for deeper benchmarking work.

How to use this page

Turn references into an actionable internal standard.

1. Start with one target component: Pick a component like modal or sidebar, then compare naming, anatomy, and key behaviors.
2. Document your chosen pattern: Capture decisions in your own spec so product teams implement one consistent version.
3. Validate against accessibility needs: Use references as input, then verify keyboard, semantics, and states in your own product context.
4. Check source terms for premium assets: If you use paid packs or kits, follow pricing, license, and usage rules on the origin site.

Tips for component standardization

Research works best when paired with clear ownership.

1. Separate naming from behavior: A shared name is helpful, but state logic and accessibility rules matter just as much.
2. Avoid copy-paste governance: Adopt patterns that match your product scope, team size, and release process.
3. Review on a fixed cadence: Refresh specs quarterly so your system does not drift from current product needs.

Great for

Roles defining or maintaining shared UI standards.

1. Design system teams: Benchmark component specs and naming before publishing internal standards.
2. Design engineers: Translate component anatomy into implementation contracts for reusable code.
3. Product designers: Align component expectations across flows and reduce one-off patterns.
4. Students and early-career teams: Learn component conventions from a structured cross-system perspective.

Why use UI Guideline on Uwarp

A stable entry point next to your design system tools.

1. Lives in Design system: Grouped with system references, principles, and component libraries.
2. Stable Uwarp path: Share `/uiguideline` in docs, reviews, and handoff threads.
3. Source remains official: Uwarp embeds uiguideline.com; updates and policies stay on the origin site.

Technical notes

This page embeds https://www.uiguideline.com/. Uwarp does not host component data from the source site.

1. Embed source: The iframe loads the public UI Guideline website over HTTPS.
2. Third-party behavior: Component lists, pricing, and account prompts are controlled by UI Guideline and can change.
3. If the embed is restricted: Open https://www.uiguideline.com/ in a full browser tab for complete functionality.

Frequently Asked Questions

Have questions? We have answers.