Design System Examples

This training explores real-world examples of design systems, helping designers and developers understand how reusable component libraries are structured and applied.

A digital instructor presents all 14 pages. Hold “Ask” at any point and ask out loud — the answer comes from this course. No sign-up needed.

28 minFree to watchDownloads

What you’ll learn

01Introduction to Examples of Design SystemsWelcome. This course compares real design systems, not visual styles. Our goal is to give your team a shared lens for evaluating structural and governance choices you can actually reuse. Across fourteen slides, we'll look at examples through seven lenses: foundations, tokens, component API, documentation, contribution, release, and adoption. Mature systems diverge for real reasons. Organization size, platform spread, accessibility duties, and brand decentralization all push teams toward different answers. So read each case for reusable structural patterns and trade-offs, not component inventories. A large system with a federal contribution model will not look like a single-team system, and that difference is the lesson. Keep one shared vocabulary in mind as we go: source of truth, contribution tiers, semantic versioning, deprecation windows, and adoption telemetry. Here's your practical takeaway for this first segment. Before we look at any case, agree as a team on which of those seven lenses matters most for your next review. That keeps the comparisons grounded. Next, we'll build the comparison framework itself: seven layers of a design system.nngroup.com designsystems.one sujeet.pro+22 min
02A Comparison Framework: Seven Layers of a Design SystemLet's give every case study that follows a shared spine. It's a working architecture of seven layers. Foundations, tokens, components, patterns, guidelines, governance, and tools. Each layer answers a different product question, and the value shows up when they reinforce each other. Your token names only matter if components consume them. Your guidelines only help if governance keeps them current. Here's the practical move. Use these seven layers as an audit matrix, and source each layer independently. You can adopt commodity components and still build your own brand foundations. But governance can't be bought. Decision rights and deprecation policy get built locally, by named people on your team. Before you plan your next review, pick one layer and trace where it's actually sourced. Next, we look at three governance archetypes and when each breaks.nngroup.com designsystems.one sujeet.pro+22 min
03Three Governance Archetypes and When Each BreaksLet's look at three governance archetypes, and when each one breaks. Centralized means one core team owns everything. Carbon, Lightning, and Cloudscape work this way. You get high coherence, but the team slowly becomes a service org for the rest of engineering. Federated means a core team owns the canon, and product teams contribute through a written RFC. Polaris and Atlassian sit here. Without real RFC discipline, you get drift. Open means components are public and anyone can fork. shadcn and Radix follow this. Adoption is broad, but every consumer maintains its own version forever. In practice, most teams in 2026 land on a hybrid. Foundations stay centralized, extensions are distributed. Each model has a shelf life set by your org size and your portfolio count. So in your next planning review, ask one question. Which model are we actually running, and has it outgrown us? Next, we'll see token-first theming in action with Material Design 3.atlassian.design atlassian.design uxpin.com+22 min
04Case Study: Material Design 3 and Token-First ThemingNext, let's look at Material Design 3 as a case study in token-first theming. Material organizes tokens into three classes: reference tokens hold raw palette values, system tokens assign roles like primary and surface, and component tokens map those roles to specific parts of a component. Theming happens at the system layer. Swap those role values and your components adapt automatically, with no rebuild. Dynamic color goes a step further: it takes one seed color and generates a full scheme using the H C T color space. Because role pairs are chosen together, contrast targets like W C A G are met by construction, not patched in afterward. The trade-off is real. You get strong platform coherence, but limited brand differentiation unless your team writes overrides. So the takeaway for your team: borrow the token-first architecture and contrast-safe role pairing as defaults in your own review. Now let's contrast this with IBM Carbon and its time-based release model.m3.material.io md3.io developer.android.com+22 min
05Case Study: IBM Carbon and Time-Based ReleasesLet's look at a system built around time rather than demand. Carbon releases a stable minor version every two weeks. A prerelease ships several days earlier, so your team gets an integration window to test against real products before the stable cut. Patches ship as needed for security and bug fixes, outside that cadence. Structurally, Carbon layers foundations under multi-framework components, all backed by one shared design kit. Its major pipeline is visible too. Preview flags named enable v twelve star land early, then a long prerelease, then Active, Maintenance, and end of life. Migration is designed in. Enable all future-version flags before the major, and expect no component changes. The takeaway for your review: pair a predictable cadence with a published release-phases table. Next, we turn to Carbon's contribution lifecycle.github.com carbondesignsystem.com carbondesignsystem.com+22 min
06Case Study: Carbon's Contribution LifecycleLet's look at Carbon's contribution lifecycle. The entry point is open: anyone can contribute code, design, or documentation, and each type has its own path. Experimental components start in Carbon Labs during discovery, kept separate from stable assets. From there, work moves through the Product Development Lifecycle: discovery, then delivery with preview status, then launch and scale, where it becomes stable at the definition of done. Prioritization weighs business impact. Reuse potential and high-impact teams move work up the pipeline. After launch, adoption is tracked through Figma's API and IBM Telemetry, so the team can see real product insertions. One takeaway for your review: ask contributors where their proposal sits in this lifecycle and which entry point it uses. Next, we'll look at Shopify Polaris and tiered contribution by risk.github.com carbondesignsystem.com carbondesignsystem.com+21 min
07Case Study: Shopify Polaris and Tiered Contribution by RiskLet's look at a real system that separates contributions by risk. Shopify Polaris splits contributions into minor and major. Bug fixes, documentation, icons, and style changes are minor. You can usually open a pull request directly. New components, API changes, and patterns are major. Those start with a written proposal in GitHub Discussions, using a fixed template, so your team answers the hard questions before anyone writes code. A centralized core team owns the canonical components and tokens. Product teams contribute through that public model. Polaris also co-locates content and pattern guidance with components, and its voice and tone guidance is cited well beyond Shopify. One evolution signal is worth noting. The React library was archived in favor of Polaris Web Components, a live platform-level migration. Your takeaway: in planning, classify your contribution by risk, and treat a written proposal as the first deliverable. Next, we look at Case Study: Atlassian's Deliberately Narrowed Contribution Surface.2 min
08Case Study: Atlassian's Deliberately Narrowed Contribution SurfaceLet's look at how Atlassian narrowed its contribution surface on purpose. Contributions are open only to Atlassians. External makers get a feedback collector, not a commit path. Within that boundary, the system team accepts fixes and small enhancements, like adding a new icon to the existing library. Major enhancements and new components stay with the system team, because they touch code, design, and guidelines across every product and brand. The stated rationale is blunt: avoid becoming a bottleneck for product teams shipping customer value. Participation stays open, though. There's a Slack help channel and fortnightly critique sessions. So read this as a deliberate strategy, not governance failure. Polaris and Carbon sit in the same archetype family, but with very different acceptance thresholds. For your team, write down your threshold explicitly, and name which changes bypass review and which require sponsorship. That one artifact prevents most review disputes. Next, we look at GitLab Pajamas and the core versus extended split.atlassian.design atlassian.design uxpin.com+22 min
09Case Study: GitLab Pajamas and the Core / Extended SplitLet's look at GitLab Pajamas and how its core and extended split works in practice. Pajamas runs two layers. The core layer holds foundations, components, and patterns that the Design System team owns. The extended layer is domain-owned and reusable, valuable in more than one place without scaling across the whole product. When you open an issue or merge request, the team classifies it as core, extended, out of scope, or pending classification when details are thin. They also set a support level: no support, consult and review, task-specific, or end-to-end. Core changes need Design System team review and approval, plus long-term maintenance, so expect a point of contact to guide you. Extended work is yours to drive, with optional guidance. The service commitments are concrete: a forty-eight hour response, a one-week path forward, and decisions capped at two weeks. Takeaway for your next review: classify the contribution before you estimate effort, and agree on the support level up front. Next, we turn to a case study on USWDS and accessibility as a compliance gate.2 min
10Case Study: USWDS and Accessibility as a Compliance GateLet's look at how USWDS turns accessibility into a compliance gate. The legal baseline is WCAG 2.0 double A, but the team works to 2.1 double A, a higher bar. Structurally, that means automated scans with pa11y and axe run on every commit. No pass, no merge. A second structural choice is the intake path. New components start in GitHub Discussions, then move into a forty five day public comment period. Contributors can see the reasoning before code lands. Third, the contributor ladder is explicit. Contributor, Maintainer, Alumni, each with stated requirements and privileges, so your team can plan review capacity rather than hope for it. Finally, adoption is paced by the maturity model, Principles, then Guidance, then Code, so agencies migrate incrementally instead of all at once. Your takeaway for planning reviews: define your accessibility gate and your intake path before you scale contributions. Next, we shift to the Pattern Matrix, looking at structures, releases, and decision rights.2 min
11Pattern Matrix: Structures, Releases, and Decision RightsLet's put these examples side by side in a pattern matrix. Read it as five connected choices. First, structure. Centralized teams run a monolithic core. Distributed teams split into federated packages. Many run a monorepo, and some ship web components. Second, governance. Options range from a central team, to tiered federation, to open community, to a public-sector mandate. Third, contribution. Models include fully open, core and extended layering, fix-only, and proposal-gated by risk. GitLab's Pajamas shows layering well: core is centrally owned, extended stays with the contributing team. Atlassian shows fix-only in practice. Fourth, release. Carbon publishes time-based biweekly minors. Pajamas releases by milestone. Carbon also graduates changes behind feature flags. Fifth, tokens. Look for reference, system, and component layers, semantic aliasing, and brand overrides. Your takeaway: in review, map each row to a named owner and a decision point. Then move on to designing your decision rights and RFC process.nngroup.com designsystems.one sujeet.pro+22 min
12Designing Your Decision Rights and RFC ProcessNow let's put decision rights into practice. Tier your decisions by risk. Core primitives and tokens get the heaviest review. Product-specific patterns get a lighter lane with the domain owner. Breaking changes need a formal request for comment with a documented migration window. Quality gates stay automated so review time goes to judgment calls. Your RFC should cover the problem, alternatives considered, affected surfaces, migration, and open questions. Ask reviewers to comment on the document, not the pull request. That keeps discussion in one place and stops code review from becoming a debate. Use Core, Federated, and Community tiers to set how deep the review goes, and name a maintenance owner before anything ships. Publish service level agreements, response times, decision windows, and an escalation path. Then track decision velocity, contribution rate, quality compliance, and breaking-change frequency. One takeaway for your next planning session: write these decision rights down and assign an owner to each tier, because a clear service level agreement is what keeps contributors from routing around your system. Next, we'll look at adoption metrics and deprecation discipline.designsystems.one nngroup.com designsystems.one+22 min
13Adoption Metrics and Deprecation DisciplineNext, let's talk about adoption metrics and deprecation discipline. Track health metrics continuously, like coverage, token compliance, detach rate, contributions, and accessibility pass rate. Reserve goal metrics for leadership accountability, so you don't turn every number into a target and inflate it. The data is sobering. Only about thirty eight percent of design systems report wide adoption, and weak governance is a top blocker. So give deprecation a policy before you make a decision. Notice, warning, lint rule, then major removal. Avoid the adoption trap: measuring what is easy, not what matters. Takeaway for your team: write your deprecation steps down now, and separate health signals from leadership goals. That prepares you for the next slide, Workshop: Map Your System and Pick One Borrowable Practice.2 min
14Workshop: Map Your System and Pick One Borrowable PracticeLet's put all of this into a working session you can run with your team. Step one, place your system on two axes: structure and governance. Are you centralized, hybrid, or federated? Step two, score all seven layers, from foundations to tools, and name the weakest one along with its failure mode. Step three, borrow one practice, not a whole model. Carbon's phased releases, Pajamas' service level agreements for review turnaround, or USWDS' merge gate. Step four, write your first RFC or decision record, and include both the migration plan and how you'll measure the result. Match structure and governance to your organization's constraints, not to what's popular. Then thank the room, and start the exercise. That's the workshop. Thanks for staying with me through all fourteen slides. You now have a comparison lens and a concrete next step. Pick the weakest layer in your own system and open the RFC this week. Good luck.nngroup.com designsystems.one sujeet.pro+21 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

PDF handoutEvery slide page, ready to print or share.15 pages · 3.0 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.15 pages · 15.1 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.15 pages · 2.9 MBDownload

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.