Ten public design systems worth studying for a B2B SaaS product

When someone tells you to look at Polaris or Carbon, the useful follow-up question is: which page? For a B2B product, the part of another company's design system most worth reusing, in our view, is not its components. It is the written decisions about what business software finds hard: dense tables, what a person without permission sees, how several products share one language, and how a new pattern earns a place in the shared system. Many of those decisions are public, and in the systems below they sit in the patterns and contribution sections rather than the component catalogue.

This guide names ten systems, the specific pages worth reading in each, and the situation each one suits. We opened every source on 28 September 2026 and checked them again on 13 October 2026. Public design-system documentation moves: Shopify archived its Polaris React repository on 11 September 2026, and the documentation site for Twilio's Paste redirected to its code repository when we checked. Confirm a page still says what we describe before you rely on it.

The short answer: ten systems and the page to read first

We kept a system only where a specific public page teaches a decision a B2B product has to make. That gave ten rather than twelve. Systems whose lessons repeated one already here, or whose documentation we could not open, were left out.

Are these only useful to companies the size of Atlassian or IBM? Every system here belongs to a large vendor. Atlassian's own article introduces the head of its design system as leading more than 35 designers. Our view is that this is a reason to copy their decisions and not their operating models. A written decision, such as when a table should become a data grid or whether a viewer sees a disabled button or no button, costs roughly the same to adopt in a team of five as in a team of five hundred. A multi-tier library and a formal contribution process do not scale down in the same way.

Study or adopt? When your product runs inside the vendor's platform, adopting their components is the point: the Lightning Design System for Salesforce apps, Polaris for Shopify apps, and Cloudscape, which positions itself for products that extend the AWS Management Console or manage hybrid cloud. Elsewhere, the components arrive with someone else's framework, brand and release schedule. Helios, for example, ships its components as an Ember addon, so a React team is mostly taking its guidance, not its code.

Dense data: tables and page templates

Much B2B software is organised around records: resources, accounts, incidents, orders. These four systems document the decisions around those records in the most useful detail we found.

1. Cloudscape (AWS): a resource list is a page, not a component

What the documentation shows. Cloudscape has been used for AWS's own web applications since 2016 and is now open source. Its table view pattern (published 10 September 2020) specifies the whole page around a table: filtering, single and multi-column sorting with visible priority, and either pagination or progressive loading. It says not to use both, except for child rows in expandable tables. Preferences let a user set rows per page and choose which columns are visible, their order, and which stay sticky. It is precise about selection: the header checkbox selects only the rows visible on the page, and sorting, paging or changing preferences clears the selection. It also separates three situations that can all look like an empty table: no resources, no results for a filter, and a fetch or access-permission error, which appears as an alert inside the empty state.

What to take. The selection rules and the error distinctions. Write down what "selected" means after a sort or page change, and how your tables tell "nothing here" apart from "you can't see this" and "we couldn't load this". Cloudscape shows that each rule fits in a sentence or two.

2. Carbon (IBM): limits written next to features

What the documentation shows. Carbon's data table usage page (last updated 30 September 2026) states when not to use the table: where a more complex display or interaction is needed, and as a replacement for a spreadsheet. It defines five row sizes with matching header rows, a toolbar for global actions with up to five visible, a batch action bar that appears once rows are selected, and inline icon buttons instead of an overflow menu when a row has fewer than three actions. It recommends skeleton states over spinners when loading time is expected. A separate accessibility tab records the component's testing status across default states, advanced states, screen reader and keyboard. It also sets out how AI-generated content is labelled: on the whole table, on specific rows or columns, or inline on individual cells.

What to take. Two things. First, the "when not to use" list: a component that states its limits gives teams permission to use something else. Second, the labelling granularity. If generated values are starting to appear inside your records, decide now whether provenance is shown per cell, per column or per table, before each product team decides differently.

3. Elastic UI: a rule for when a table becomes a grid

What the documentation shows. Elastic's data grid page says the grid is the better choice over its tables when there are many columns, the data in them is fairly uniform, and schemas and sorting matter for comparison. It notes that the grid forces truncation and moves extra content and actions into cell popovers, and that its strengths are in displaying content rather than creating it.

What to take. An explicit threshold between two components for tabular data. If your team is stretching one table component to cover both a ten-row settings list and a hundred-column log view, Elastic's rule is a ready-made starting point for the split.

4. SAP Fiori: templates at the level of the page

What the documentation shows. Fiori documents page types it calls floorplans. The list report floorplan is for finding and acting on items in a large set, and the page names the alternative for each case it does not suit: an object page when someone needs one item in full, an initial page when they already know the item's identifier, a worklist when they work through a small set one by one, and an analytical list page when they need insight from the data. It treats saved views as a system decision: one variant management control per page saves filters, tabs, tables and charts together. It also says to hide actions that cannot be used at all, for example because of access rights.

What to take. A small set of page archetypes, each with a "use this other one instead" rule. Our view is that for a suite, agreement at page level (what a list page, a record page and a queue page contain) often removes more inconsistency than agreement at component level. The page sits at a versioned address (v1-151, still the latest guideline version on 13 October 2026), and some of its links were broken when we checked.

Permissions, plans and failure states

The states a B2B user meets, such as no permission, a plan limit, an unfinished prerequisite or a service outage, are where products built by several teams can diverge. Three systems document them, and comparing them is more useful than copying any one.

5. Helios (HashiCorp): permissions, plans and quotas in one pattern

What the documentation shows. Helios' show, hide and disable pattern recommends avoiding disabled elements, because they cannot be reached by keyboard or read properly by assistive technology, and says user research and feedback supported that approach. When a user lacks permission, it hides the related actions, navigation and views. When someone lands on a page they cannot access, it explains why and how to fix it. Where a feature needs other steps first, it replaces the disabled control with context and a route to enable it. It covers upgrades (a feature spotlight, or a dialogue that interrupts an action, with a caution against over-advertising) and quotas: hide the create action once a quota is reached, offer an increase if the user can request one, and otherwise explain why and point to an upgrade path. Submit buttons stay enabled, with errors shown after submission.

What to take. Among the pages we read, this is the one that treats commercial facts (plan tiers, quotas, upgrades) as interface states alongside permissions. If your product has packaging, those states need the same written rules as a validation error.

6. Primer (GitHub): saving, and what happens when part of the product is down

What the documentation shows. Primer's degraded experiences guidance, written primarily for GitHub staff, distinguishes primary experiences (without which the page is useless, so show an error page) from secondary ones (render the page without them). It warns against showing a generic empty state for content the user created, because they may conclude it was deleted. It says never to disable a control that fails because of an availability problem, and never to suppress the global navigation. Its saving pattern makes explicit saving the default, reserves automatic saving for controls that behave like switches, forbids mixing the two in one form, and keeps the save button enabled even when the form is invalid or unchanged.

What to take. The primary and secondary split. For a product that assembles each page from several services, deciding in advance which parts of each page are primary is what makes graceful degradation possible to review.

Where the three agree, and where they do not

Fact: all three keep form submission enabled and rely on validation, which makes that a safe default to adopt. On permissions they split, and SAP Fiori sits with Helios on hiding actions blocked by access rights. Cloudscape's reason formats, such as "This action is available for [constraint]", show the alternative done carefully.

Our reading: the pages share a principle beneath the split. Explain when the person can act on the explanation (request access, upgrade, finish a prerequisite), and remove what they can never use. Whichever rule you choose, write one down. A user who works across several of your products is likely to notice inconsistency here more than in any component.

Several products, one system

7. Atlassian Design System: a middle tier, and an admission that tiers blur

What the documentation shows. In an article published on 28 May 2026, the system's leaders describe scaling across more than 20 apps with three tiers: core (tokens, components and guidelines used everywhere), platform (components and patterns shared across several apps) and app (domain-specific components for one product). Adoption flows down; app patterns that prove their value can move up. They then say the neat model evolved in practice into a web of interconnected systems, where a Jira designer might use a Jira kit, platform patterns or the core directly. The same article describes overhauling lozenges, tags, badges and labels after years of customisations had made them diverge across apps.

What to take. The platform tier. A suite with only a core library and separate product libraries has nowhere to put a pattern that three products share. Atlassian's admission that the tiers blurred is useful too: treat the tiers as a way to assign ownership, not as a filing system teams must respect. Status labels are also worth checking first in your own suite, since Atlassian names them as a place divergence accumulated.

Left out. The article reports AI efficiency percentages from Atlassian's own evaluations without describing the method or baseline. We have not repeated them.

Carbon, again: an extension library that shows its status in code

What the documentation shows. Carbon for IBM Products is an open-source library of components and patterns built on core Carbon, implementing IBM's closed-source software pattern library. Its components carry their lifecycle status in the import name: stable components have no prefix, preview components use a `preview` prefix, and components still being validated use `previewCandidate`.

What to take. A product-family library can sit on top of the core with its own maturity rules, and putting status into the name means an engineer sees it at the moment of use rather than only on a documentation page.

Contribution and ownership

8. Pajamas (GitLab): ownership follows the layer

What the documentation shows. GitLab's contribution page (updated 15 September 2026) splits the system into a core layer, owned by the design system team, and an extended layer for patterns useful in more than one place but not across the whole product, owned by the team that created them. Each has written criteria and requirements. Core items need full accessibility conformance, design specs, Figma assets, code and documentation, and team capacity for long-term maintenance. Extended items need documentation and code, and receive no long-term support from the design system team. Every contribution gets a level of support: none (the default for extended work), consult and review (the default for core), task-specific, or end-to-end. The team reviews its support every milestone and scales back where work has stalled.

What to take. The levels of support. Beyond who approves, Pajamas says who does the work and how much help to expect, which is the question a product team under deadline actually has. A small team can copy the idea with two layers and two support levels.

Primer, again: the first decision is whether to look further

What the documentation shows. Primer's guidance on new patterns lists signs a pattern is ready to share, including likely use in more than one product and no dependencies unavailable to other apps. After a proposal, the first decision is whether to invest in further evaluation, not whether to approve. The recorded outcomes are to pursue it with named owners, gather specific evidence, or keep it local, with the product team responsible for its quality. Primer's component status page defines experimental, ready and deprecated, with breaking changes to ready components released as major versions.

What to take. "Keep it local" as a recorded outcome, with an owner. It stops a declined proposal from turning into an undocumented fork.

Atlassian, again: a contribution page that states its limits

What the documentation shows. Atlassian's contribution page accepts contributions only from Atlassians, takes fixes and small enhancements, and says it may be unable to take new components or patterns. It states plainly that contributing is currently difficult and that the team is working on it.

What to take. Saying what the system cannot accept is part of governance. It tells product teams when to build locally, and shows that even a large team cannot take every proposal.

When others build on your interface

9. Salesforce Lightning Design System 2: the supported surface is the contract

What the documentation shows. Salesforce's comparison of SLDS versions says SLDS 2, introduced in Spring '25, separates structure from visual design through styling hooks, which are CSS custom properties. Design tokens are not supported in SLDS 2 themes, global styling hooks replace them, and a linter and validator help developers find what needs to change. Component-level styling hooks are not yet supported in SLDS 2, and developers who rely on them are advised to stay on SLDS 1 for now. A separate anti-patterns page says styling the rendered markup of base components and overriding SLDS classes are unsupported, because Salesforce must be free to change component internals, and that fixing any breakage is the developer's responsibility.

What to take. If customers or partners style or extend your product, name the supported customisation surface, state what is unsupported, and ship tooling for the migration. Our view is that the same boundary helps inside one company, where product teams overriding the core behave much like external developers.

10. Polaris (Shopify): what "look at Polaris" now points to

What the documentation shows. On 28 September 2026, polaris.shopify.com redirected to Shopify's developer documentation, Polaris references. That page describes Polaris as Shopify's unified UI framework built on web components, used across the surfaces where apps appear, and says each surface (the admin, checkout, customer accounts and point of sale) has its own subset of components. The Polaris React repository, whose old address now redirects to an archive, says the React library is deprecated, that Polaris Web Components were released on 1 October 2025, and that the repository was archived on 11 September 2026.

What to take. Polaris is now most instructive as a system exposed to third-party developers: technology that does not depend on one framework, and a deliberately limited component set for each place where outside code can appear. If your product has an app marketplace or extension points, that is the lesson. If you were pointed to Polaris for its guidance on your own product's interface, note that the site those recommendations referred to now redirects to documentation for building Shopify apps.

What public documentation cannot show

The premise of this guide held up: in these ten systems, many of the decisions B2B products find hard are public, and few of them sit on the component pages. The research also showed its limits.

• Some of the reasoning is internal. Primer's degraded experiences page cites a GitHub-only article. Carbon for IBM Products implements a pattern library IBM keeps closed. Atlassian's contribution route runs through internal channels.
• Cost and capacity are absent. None of the pages we cite says what the practice costs to run. You can see the rule, not the team that keeps it true.
• Outcomes are absent. The pages we cite do not report whether these decisions improved anything measurable for their products. Treat them as considered positions, not proven results.
• The systems disagree. On permissions, you cannot copy an answer. You can only see the options clearly and choose one.
• Pages move. Polaris changed its public home, Paste's documentation site redirected to GitHub, Carbon's data table page moved to a new address, and some links on the Fiori page were broken when we checked.

A quick way to read any system in about an hour: open its patterns index before its components; find every "when not to use" section; read its contribution page and its component status page; then look at its migration notes or anti-patterns. Take one recurring decision from your own product with you, such as what a read-only user sees on an admin screen, and check how each system would answer it.

Where this work sits

Choosing which of these decisions your own system should standardise, and for which products, is design system strategy. Making contribution, exceptions and "keep it local" outcomes workable is governance and adoption, and the governance definition sets out the models without prescribing a large committee. When you are not sure where your current system breaks, a design system audit looks across the system, and the drift checker traces one shared component family across Figma, code and the shipped product. If you would rather look yourself first, how to audit a design system sets out a checklist, and when to hire a design system consultant covers when outside help is the wrong answer. Our earlier article on design systems for SaaS covers what a design system is and why SaaS teams adopt one.

At Tcules, we also publish Matter, a public Figma design-system reference of our own. We have not included it among the ten. It demonstrates token-led foundations and component composition, not the product-state and governance decisions this guide is about, and its Figma listing showed it had not been updated for three years when we checked it on 13 October 2026.

For the wider service, see Design Systems.