Shuichiro Ogawa
日本語

Notes · updated 2026-09-11

Design System Best Practices

Design systems (hereafter DS) are one of the few areas where the evidence of adoption and the evidence of effect do not balance.

The 2026 zeroheight survey (147 respondents) found that organizations with a dedicated DS team reached 83%. The value the same survey shows for a year earlier is 78%, so adoption is still continuing. 39% of respondents belong to organizations with 5,000 or more employees.

On the effect side, the numbers are thin. In the same survey, only 5% answered that they measure ROI, 31% for development speed, and 41% each for adoption status and component usage in design tools. In Sparkbox’s 2021 survey (376 responses) as well, 31% of organizations measured metrics.

In most organizations that have adopted a DS, the effect of adoption is not measured. Practices for which evidence has accumulated and practices carried only by received wisdom are mixed together under the same word, DS.

The perspective of reading DS as a context layer for AI was covered by design-systems-ai-infrastructure and mcp-design-agent-integration. What is lined up here is the design and operational evidence that comes before that.

Design Practices the Evidence Supports

IBM Carbon codifies in its design documentation a design that separates color abstraction into layers.

A Token is “code identifier for a unique role or set of roles,” a Role is a role that cannot be changed across themes, a Value is a hexadecimal value, and a Theme is a set of values. Tokens are common to all themes, and only values change when the theme is switched.

Carbon also attached a condition to reuse. “A single token can be associated with multiple roles, but only if the color value is used consistently across those roles.” Reusing the same value across multiple roles is limited to cases where that value is used with the same meaning in every role.

The constraints are also written as numbers. Each theme is fixed to a specific primary background, mixed tones are avoided, and accessibility requires a lightness difference of 50 or more. The default is four themes, and the guidance states that “IBM products should use one of the four IBM default themes.”

Salesforce advanced the separation of layers from a different direction. SLDS 2’s CSS architecture is decoupled from the default appearance and becomes “no longer locked into predefined design choices for buttons, modals, fonts, and borders.” Switching is done with global styling hooks (CSS custom properties), so that “One change updates everything.”

Salesforce’s naming convention is based on meaning. Names like radius-border-4 and font-scale-4 point to a role rather than to an appearance. Sharing the same vocabulary as the Figma kit produces “a shared vocabulary that bridges design and development.”

The W3C Design Tokens Community Group (DTCG) released a stable version of the interchange format in October 2025. The specification has $value, $type, $description, and $deprecated, and defines group inheritance, aliases, and types. With types fixed by the standard, handoff between tools became machine-readable.

Even if the standard fixes the types, it does not fix the meaning of names. Adobe Spectrum’s RFC admitted the problems its own repository’s naming carries. The meaning of names is implicit, and reading “text-to-visual” does not tell you what it points to. There is no validation of naming conventions, and it is not even possible to ask “show me all spacing tokens.” The summary is that “This makes it difficult to build tooling, enforce governance, or provide semantic guidance.”

The proposal was validation with JSON Schema and movement toward a controlled vocabulary. The prototype ran with 2,338 tokens in 8 files, with schema validation coverage of 82% (1,929 items), the parser under 2 seconds, and validation at about 500 ms. 455 items, or 19.5%, remained as Special Tokens requiring additional schemas.

Design trade-offs are also recorded. Keyed objects were rejected because names cannot be duplicated across themes, and anonymous arrays were adopted. The idea of having an LLM parse it was rejected on the grounds of being “Non-deterministic.”

In April 2026, the author corrected it: “this RFC is not the conformance target.” The nested name.structure was flattened, and the 9 categories were replaced with a classification following Nate Baldwin’s framework. The first controlled vocabulary also did not become the settled answer as it was.

Because tokens break when names change, renaming and migration are also part of design.

Carbon v11 changed token names into easier-to-understand forms while stating compatibility explicitly: “Tokens that are changing will continue to work in v11.” Assets deprecated in v10 also remain in v11, with notice that they will be removed in v12. Because the IBM Design Language itself does not change, IBM explains that products do not need to be redesigned.

Bootstrap chose not to do a full overhaul in v5. It had the experience of a difficult migration from v3 to v4. It writes that “we’re now able to drop jQuery as a dependency, but you’d never notice otherwise,” explaining that it began using CSS custom properties in exchange for ending IE support. It limited itself to extending the grid, and says of CSS Grid that “we haven’t made use of it here yet, we’re continuing to experiment.”

Salesforce’s SLDS 2 made migration optional. It states explicitly that “You’re not required to switch,” and frames the release as “it’s an upgrade, not a full rebuild.” It adds that for organizations carrying complex customizations “it may take more effort,” and discloses that dark mode is not yet provided and is on the roadmap.

What the three companies have in common is that they delimit the scope of the change first and make explicit what will break.

Operational Practices the Evidence Supports

Delimiting the scope alone does not keep changes circulating. The evidence on operations clusters around automated verification and how contributions are accepted.

GitHub’s Primer audited more than 100 color pairs in a color contrast remediation. The required ratios were 4.5:1 and 3:1. What mattered here was the fact that colors are not independent. “colors are often part of multiple color pairs, which means that improving one pair may break the contrast for another.” Fixing one pair breaks another.

So they stopped manual verification, turned it into a script, and ran it as a GitHub Action on every PR. Because opacity depends on the background, they solved it with two-stage blending. Large brand-related changes were split off into a separate issue as “intentionally leaving larger brand-impacting changes as a separate issue,” then released after a feature flag, internal interviews, and several weeks of monitoring.

Harvey manages adoption rates with thresholds. A warning at 80% adoption and a pre-commit error at 95%. Figma variables are synced by a GitHub Action, with Figma as the source of truth.

USWDS uses VoiceOver, JAWS, keyboard, zoom, touch, and automated scanning as its means of internal testing, and establishes the rule “if it doesn’t pass, we don’t merge.” It warns, however, that “Building with accessible USWDS components does not guarantee an accessible service.”

There is a counterpart to this direction on the research side. UIS-Hunter detects guideline violations from the UI of Android apps and points to the relevant Material Design guidelines. GUIPilot detects mismatches between design mockups and implementations, and reported precision 99.8% and recall 98.6% across 80 apps and 160 mockups. Neither is a DS itself; they are a lineage that mechanically checks conformance to a DS.

The design of the acceptance side is published by the GOV.UK Design System as a table of 9 stages and 3 roles. The 9 stages of prioritise, gather evidence, consolidate designs, scope, rough proposal, build working version, user research, build robust version, and publish correspond to the 3 roles of driving, supporting, and awareness.

The team states explicitly that “There is no one-size-fits-all process for how we work” and that it “is process agnostic,” presenting itself as a non-prescriptive model. The roles were defined in a team workshop in 2023.

The shift that led to this model is recorded. Previously the stance was one of waiting, that “In the past, we often waited for teams to approach us for proposals for patterns and components,” and it “did not always match with the community’s needs.” It reversed into a model that publishes priorities first and asks the community to participate. It also writes that “Facilitating contributions to design systems is hard. Not everything will work.”

Shopify Polaris, by contrast, decided up front what it would not take on. “The Polaris team should never be pulled in to unblock a team from shipping something quickly,” and custom components are owned by the product team that built them. When a change across the whole product occurs, that team also bears responsibility for updating its own custom work.

Tokens, however, are the exception: “always use Polaris tokens” demands uniformity. For custom solutions it also obliges the team to make an effort to bring them into the system later: “the team should make an effort to systematize the custom solution down the road.”

The consultant Nathan Curtis splits intake into four types, Support request, Feature request, Contribution proposal, and Defect, and describes an operation in which design and dev Trafficers triage them. He places a DRI in the workflow and defines “doneness.” Each release is assigned “54 Preassigned tasks.” He mocks his own materials with “All the checklists, oh my!” and asks for plan, test, and review for Figma assets too. The design is based on experience supporting about 85 systems, and the sample composition and period are not disclosed.

In both automated verification and contribution models, what is being decided is the treatment of exceptions. What is left to machines, what people take on, and what is refused.

Organizational Factors Blocking Adoption

Even in organizations with operational patterns in place, adoption does not always spread. Research places the reason outside technology.

Richter et al. (2025) organized the reasons adoption stalls into four categories from interviews at a single organization with a mature DS. Knowledge gaps, slow evolution, lack of flexibility, and inefficiency. The proposal lies in inner source, that is, bringing in-house software development practices into the development and maintenance of the DS.

Lamine and Cheng (2022) analyzed issues in OSS DS repositories and interviewed leaders. The challenges concentrate on the behavior of UI components. Satisfying stable design knowledge and per-product flexibility at the same time is difficult. This research supports advancing evolution bottom-up.

Palomino et al. (2024) treated DS adoption as a developer experience (DevEx) problem. In a UCD-style case study that treats the development team as users, they report that resolving the challenges extracted through interviews led to successful adoption and improved developer ownership and collaboration between the UX side and the development side.

The starting point does not come from the top. In Sparkbox’s 2021 survey, 57% answered that the starting point of DS adoption was an individual contributor, against 22% for management.

There is also not enough slack on the ground. In the zeroheight 2026 survey, 61% answered that staffing was “insufficient,” and the largest challenge was resources and staffing at 56%. The share satisfied with stakeholder buy-in fell from 42% in 2025 to 32% in 2026. The roles with the largest shortfalls are accessibility specialists and product managers, both at 44%.

The entry point for people is narrow as well. Rose et al. (2023) present a pedagogical model for education, arguing that DS has hardly been taught in degree programs.

Circumstances outside the organization also matter. Du and Xiao (2023) analyzed, from the case of the Chinese market, the problem that deploying a global DS built first in English-speaking countries as-is into local markets produces products that fit neither global standards nor local needs.

Adoption in multidisciplinary teams is also a communication problem (Sousa and Lélis 2026) [requires primary verification]. The bibliography is confirmed, but because the abstract is not public, the content and methods have not been confirmed. Criteria for which components to include in a DS have also been proposed (Maia et al. 2026) [requires primary verification]. Here too the abstract is not public, and the content and methods have not been confirmed.

Richter et al.’s four barriers are not about the content of the DS but about the nature of the organization. What moves the adoption rate is not only the quality of the DS.

Claims Circulating Ahead of the Evidence

Numbers dealing with ROI circulate in large quantities. Few can be traced back to their source.

In collecting the industry corpus, no DS-specific ROI survey that published its sample and definitions between 2021 and 2026 could be confirmed. What remains is one controlled experiment and self-reported cases.

Sparkbox’s experiment had 8 developers implement the same contact form under two conditions. Building it by hand, and using IBM Carbon. The median fell from 4.2 hours to 2.0 hours, a 47% reduction. The Carbon condition includes learning time. Visual consistency improved for 5 of the 8, and the top 2 were implementations that used the DS. Accessibility was mixed: 3 were equivalent, and 2 were better without the DS.

All the developers were full-stack and accessibility-trained, and 2 of them were IAAP certified. The authors themselves withhold generalization.

The numbers from this experiment changed shape as they circulated. The phrasing “the Sparkbox 2023 survey shows 47% faster development” spreads, but the primary source is not a survey but a controlled experiment with n=8. The sample size and the method are different.

Vendor numbers often do not disclose their calculation formula. The Figma and HP case study, in a survey of 400 Dev Mode users, states that “80% experienced efficiency gains” and “98 minutes saved per person per week,” and puts Veneer at “500% ROI” from January to December 2023. The calculation formula and cost basis are undisclosed, and the effect is self-reported [requires primary verification].

The actual state of measurement does not correspond to the circulation of these numbers. In the zeroheight 2026 survey, 5% measure ROI.

The premise that “consistency is good” is also not simple.

Grudin (1989) argued that consistency is unreliable as a design guideline. The claim is that what designers should look at is not the degree of consistency but the work environment in which users are placed.

Kolko (2026) interviewed 17 design managers and showed that while DS and assembly-line production bring efficiency and consistency, they can harm creativity through a path that skips exploration and de-emphasizes differentiation.

The comparison by Opsahl and Sitompul (2025) makes that implication concrete. Eight crane operators tried a GUI to which the DS was applied as-is and a GUI modified along design principles. Task completion was 100% for both, and there was no difference in speed either. Satisfaction was substantially higher for the modified version.

“Using it as-is” did not produce the best result.

GOV.UK’s government design principles incorporate this limit among their 11 items. The ninth item is “Be consistent, not uniform.”

The word maturity also has no public definition. Within the scope of collection, no public document defining DS maturity was found. It cannot be asserted that none exists, but there is no definition available for reference.

The maturity stages in circulation are a commercial proposal. The UXPin and Whitespace survey interviewed 19 managers at large companies and reports that 63% reached Stage 3 “Design and Coded Components.” The timing of the survey is not disclosed [requires primary verification].

The definition of DS itself fluctuates between surveys. Yew et al. (2020) reported the fluctuation in definitions and a trend toward in-house development from a survey of 1,513 people at Clarity 2019 and interviews. If definitions do not align, lining up numbers between surveys has little meaning.

The academic accumulation is thin as well. Vendramini et al. (2021) mapped 23 sources, of which 6 were peer-reviewed literature. They point to the scarcity of citations from academic databases.

Areas that research has not addressed are also recorded. Peer-reviewed research taking design tokens alone as its subject barely exists; a title search for “design tokens” on OpenAlex returns 16 items, of which the only peer-reviewed conference paper is Brickify (CHI ‘25). No peer-reviewed paper taking DS governance as its subject was found. No peer-reviewed paper taking DS failure patterns as its subject was found either.

Comparison across versions of the same survey is also not possible. zeroheight records the 2025 dedicated-team rate as 78% in the 2026 edition, but the 2025 edition records the same year as 79%. A one-point discrepancy.

The nature of the samples is also constrained. Both zeroheight and Sparkbox are self-selected non-probability samples, and cannot be used to estimate the population.

Weak evidence does not mean the practice is ineffective. But as things stand, it has not been shown to be non-ineffective either.

Constraints Set by Standards and Regulation

Even with thin evidence of effect, some preconditions are set from outside. The token interchange format, and the required level of accessibility.

The design token interchange format was set by the DTCG. It is the “Design Tokens Format Module” published as a Final Community Group Report on October 28, 2025.

Calling this a W3C standard is not accurate. The specification itself states that it is not a W3C Standard and is not on the Standards Track, and it is published as a Community Group Report. The W3C also notes that “the views of a Community Group do not necessarily represent the views of W3C Membership or staff.” As a classification it is equivalent to a Candidate Recommendation, and the specification writes that it is “considered stable.”

The 2025.10 version consists of three modules: Format, Color, and Resolver. There are 546 participants and 3 chairs. At the time of publication, Style Dictionary, Tokens Studio, Terrazzo, and others supported it, and more than 10 tools including Figma, Penpot, Sketch, Framer, and zeroheight had implemented it. Contributors include Adobe, Amazon, Google, Microsoft, and Meta.

Governance is also moving. On June 17, 2026, Jina Anne and Val Head stepped down as co-chairs and became chairs emerita, and a co-chair election and the resumption of meetings were announced.

On the accessibility side, standards, regulation, and procurement overlap.

WCAG 2.2 is a W3C Recommendation dated December 12, 2024. It has 4 principles and 13 guidelines, and conformance levels are the three of A, AA, and AAA. It added 9 success criteria over 2.1 and removed one, 4.1.1 Parsing. Content that conforms to 2.2 also conforms to 2.0 and 2.1. It is also approved as ISO/IEC 40500:2025.

The W3C’s WCAG page does not state that AA is the level generally required. That AA is treated as the baseline in practice is because regulation designates it there.

In the United Kingdom, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 apply to public sector websites and apps. They took effect on September 23, 2018. The required level is stated explicitly as WCAG 2.2 AA. Publication of an accessibility statement is mandatory, and intranets and extranets are also covered. Content published before September 23, 2019 is required to conform when it is updated.

Monitoring is done by GDS through annual sampling, and the names of bodies found non-compliant and the decisions are published. Enforcement is carried by the EHRC and ECNI, which have the means of unlawful act notices and litigation. For a claim that compliance would be a disproportionate burden, an assessment and records are required.

A DS itself also declares conformance. The GOV.UK Design System states that all three targets, the website, the Frontend documentation website, and the Frontend codebase, are “fully compliant” with WCAG 2.2 AA. External audits were conducted by the Digital Accessibility Centre in July 2024 and at other times. Non-compliant content is “no known non-compliant content,” and two concerns under tracking are also published.

In the EU, the Web Accessibility Directive (Directive (EU) 2016/2102) has been in force since December 22, 2016. It covers public sector websites and apps, with limited exemptions for broadcasters and live streaming and the like. The obligations are an accessibility statement, a feedback mechanism, and periodic monitoring by member states with reporting to the European Commission every three years.

The technical basis is the harmonized standard EN 301 549 v3.2.1. A version skew is occurring here. The current version of EN 301 549 uses WCAG 2.1, and the move to WCAG 2.2 is expected in the next version. The W3C states that older versions have not been withdrawn and recommends using the latest version.

The original text of EN 301 549’s clauses could not be confirmed directly because the ETSI PDF returns 403, and the version number and its positioning have been confirmed only through the European Commission’s page [requires primary verification].

The European Commission writes of overlays that “It is best to fix accessibility issues at their source,” and requires that testing “always involve persons with disabilities.” About 100 million people in the EU population are estimated to have some form of disability.

The United States bases its requirements on Section 508 of the Rehabilitation Act. The 2018 update adopted WCAG 2.0 Level AA and positions it as “the baseline of conformance for legal compliance.”

USWDS’s own goal is higher than that. It describes achieving WCAG 2.1 AA as “works to achieve the higher standard,” and says of WCAG 2.2 that it is not mandatory but “we strive to achieve as many of the latest success criteria as we can.” The conformance report is produced as VPAT 2.5, evaluating the 44 components of USWDS 3.11.0 in March 2025 and publishing it in May.

The legal baseline and the DS’s goal do not match. It is not a relationship in which using the DS means being compliant.

In Japan, the Digital Agency publishes a design system beta. It has a three-part structure of design language, UI components, and guidelines, and distributes design tokens and sample code on GitHub and Storybook. HTML and React versions, Figma data, and a Markdown version are provided. The version is v2.18.0, and the update date is September 9, 2026.

“Beta” is explained as indicating that it is a living standard. In the latest update batch, about 20 components were published. The WCAG conformance level is not stated in the text.

Canada takes the form of a mandate. The basis is Appendix D of the Directive on the Management of Communications and Federal Identity, which requires the application of Canada.ca design requirements to public-facing sites and digital services of institutions listed in Schedule I, I.1, and II of the Financial Administration Act. Technology and platform do not matter. The global header and footer cannot be adapted or duplicated.

The normative documents also contain design decisions. The UK’s government design principles number 11, and “Minimise environmental impact” was added in the 2025 update. The Service Standard has 14 points, and the thirteenth is “Use and contribute to open standards, common components and patterns.” No item explicitly names the design system.

Research positions the DS as a delivery vehicle for accessibility. Wahid (2024) discussed an approach to scaling accessibility support across an organization (ACM Queue, non-peer-reviewed). Diniz and Gama (2024) surveyed the accessibility status of major DSs and had developers try component packages with accessibility built in.

Standards and regulation are constraints outside the DS’s own design decisions. The DTCG aligns the interchange format, and accessibility law determines the conformance level. Neither can be changed by a DS alone.

What Each Company Chose and What It Discarded

Aggregates do not show individual decisions. The content of the decisions appears in the record of what each company discarded.

Brad Frost rejects centralization into a single system. He writes that “it would be a disaster if ALL user interface at an organization originated from a single design system,” and argues for a layer-cake model that places each team’s autonomy on top of a shared foundation. The summary is that a DS, while it brings in constraints, needs to satisfy both “efficiency, quality, & scale” and “flexibility and agency.”

Atlassian tokenized typography across 18 or more apps and recorded its regret. “We allotted little design time to the tokenization, which we quickly realised was a mistake,” it admits, acknowledging the under-allocation of design effort. The method had three stages: first reproduce the old system with tokens under “no visual changes,” then move to the new font afterward. It raised the smallest heading and body text from 11px to 12px and adopted a minor third scale.

Things judged unnecessary were also discarded. The already-shipped “UI text” style did not resolve the confusion, so it was scrapped. The criterion for judgment is “When in doubt, take it out.”

Harvey chose a rebuild. The trigger was “Our product complexity was growing faster than our design infrastructure could support.” Its self-assessment at the time was “more of a collection of components than a fully realized design system,” and the tokens were “transformed organically over time, which is a polite way of saying it was chaotic.” Some colors had only two values, neutral colors ran from 910 to 940, and other colors mixed two systems, 100 to 1000 and 50 to 950. Multiple versions of the same component lived in different files, and “There was no clear ownership or contribution process.”

The new tokens carry a hy- prefix, Figma variables are synced by a GitHub Action, and Figma is the source of truth.

Ant Design admitted the weaknesses of its own approach. The maintainer @MadCcc writes that because the CSS-in-JS approach does not follow component props, all styles of a component that is used are imported. Inlining styles during SSR bloats the generated CSS. It also admitted that hitches when switching themes and a light-to-dark flicker on reload are problems its own product has.

The solution is injecting CSS variables, and from 5.12.0 it provides a CSS variable mode. It did not take the option of discarding flexible theming capability the way Mantine did. It states explicitly that the cost remains: with nested multi-theming, the generated CSS increases.

OpenProject discarded its own DS and decided to ride on an external, mature system. The reason is “lean on the experience and expertise of more mature open source projects,” with the intent of redirecting the effort freed up to core features. The migration is not light. It writes that “it is nevertheless a significant amount of effort,” and that midway “you might notice a mix of old design elements and new Primer components” and “This blending is temporary but essential.” As a side effect, font sizes became smaller to match the adoption target’s baseline. The adoption target also has constraints, and it is noted that “not all existing components are reviewed for accessibility.”

Google also produced a counterexample. The Expressive version of Material Design is based on 46 studies, more than 18,000 participants, and a comparison across 10 apps. It says of itself that it is “the most researched update to Google’s design system, ever.” The methods are eye tracking, surveys and focus groups, experiments, and usability testing.

Along with the results, it disclosed changes that did not work. “removing text labels from email actions resulted in decreased usability.” Removing labels lowered usability. “a strong minority of users preferred calmer, less intense versions.” A strong minority preferred the calmer versions. It concludes that “it’s not a one-size-fits-all solution.” On accessibility, it states explicitly the choice to exceed the baseline: “we chose to exceed existing standards for tap target size, color contrast.”

Storybook moved its styling foundation from Styled Components to Emotion. The scope was 541 components, 5 codebases, and more than 2,300 stories, and it took one quarter. The hard part of the migration is CSS’s context dependence. “Refactoring CSS is one of the most challenging tasks as a frontend developer,” and “minor changes in one file can have unintended consequences without warnings.” Maintaining two versions slowed things down: “Maintaining parity between two versions of the same components slowed us down.” Because Emotion has no attrs, they worked around it with defaultProps and a wrapper, and zero-config SSR did not work, so they switched to manual setup.

Another Atlassian team measured the cost of an attempt to fold a DS into a single file. When DESIGN.md is made the sole source of DS information for generating a login screen, token consumption rose about 92% and run-to-run variance grew about 2.7 times, it reports. The comparison covers four approaches. No context: an average of 4.20M tokens, 6 minutes 19 seconds, 43 turns. ADS MCP: 3.75M, 5 minutes 1 second, 35.1 turns. ADS skill: 4.43M, 5 minutes 23 seconds, 36 turns. DESIGN.md: 7.21M, 6 minutes 46 seconds, 45.3 turns. All are averages, and the number of trials is not disclosed.

To keep DESIGN.md within about 19,800 tokens, usage guidance for more than 50 components was deleted. The gaps are filled in by the agent reading the implementation. As a result of writing the inside of the DS into prose, the tendency that “DESIGN.md was more likely to re-create components rather than use the existing system” was observed, working in the direction of producing technical debt.

The authors withhold: “These results should not be seen as conclusive; this blog is not a research paper.” It is a comparison on a single task, and the design of passing a DS as AI context is at a stage where results change just by changing how it is passed. This is also the area covered by design-agent-tools-landscape-2026.

That records of discarded things remain is because those were the places where judgment was hard. Whether to add vocabulary or reduce it, whether to make the system one or several, whether to rush expansion or wait.

Unresolved Conflicts

There are multiple practices that give opposite answers to the same question.

AxisPosition A (source)Position B (source)Evidence needed to adjudicate
Single system or multiple systemsIt would be “a disaster” if all UI originated from a single DS, and a layer-cake model of a shared foundation plus autonomy should be taken (Brad Frost 2025, developer-voice)In actual operating models, centralized is 51%, hybrid 31%, and federated 13%, so centralization is the majority (zeroheight 2026, n=147, self-selected sample)A comparison measuring, in organizations operating multiple systems, the number of duplicate components and the time to propagate a fix
Is consistency the goal or the meansPlace the unification of tokens and roles at the core of design (IBM Carbon), “One change updates everything” (Salesforce SLDS 2). Both are primary sourcesConsistency is unreliable as a design guideline (Grudin 1989, academic). DS can harm creativity through skipping exploration (Kolko 2026, n=17, academic). GOV.UK’s principle is “Be consistent, not uniform”A comparative study that controls the level of consistency and measures task performance and exploration behavior at the same time
Should tokens be exhaustive or minimalPropose managing 2,338 tokens with JSON Schema and a controlled vocabulary (Adobe Spectrum RFC, prototype measured)Adding context raised token consumption about 92% and variance about 2.7 times (Atlassian DESIGN.md experiment, single task, the authors themselves withhold generalization)A controlled experiment measuring the relationship between token count and generation quality on the same task
Govern or leave to autonomyRefuse urgent requests and place ownership of custom work with product teams (Shopify Polaris, operational rules document). Publish a 9-stage, 3-role process (GOV.UK, team document)The barriers are knowledge gaps, slow evolution, lack of flexibility, and inefficiency, and inner source is proposed (Richter et al. 2025, single organization). The starting point of adoption is individual contributors at 57% (Sparkbox 2021, n=376, self-selected)A longitudinal comparison of organizations with different levels of governance (adoption rate and the number of external contributions over time)
Rename and reorganize, or preserve compatibilityChange token names while keeping the old names working in v11, with notice of removal in v12 (IBM Carbon v11, release announcement)Avoided a full overhaul because of the difficult migration from v3 to v4 (Bootstrap v5, author’s blog). Migration is optional: “You’re not required to switch” (Salesforce SLDS 2)Cases tracking the survival period of old tokens and the cost of fixes in organizations that chose to preserve compatibility
Does using a DS make you accessible”Building with accessible USWDS components does not guarantee an accessible service.” The legal baseline is WCAG 2.0 AA, and the DS’s goal is 2.1 AA (USWDS, primary source)Position the DS as a delivery vehicle for accessibility support and scale it across the organization (Wahid 2024, ACM Queue, non-peer-reviewed)A comparison of accessibility audit results between services that adopted the DS and services that did not

Each row of the fourth column is in fact made up of several measurements. A record decomposing each single line into units of measurement, establishing how far measurement reaches and where it is empty, is in design-system-adjudication-evidence.

References

The access date for all URLs is 2026-09-11.

Academic Literature

Public Bodies and Standards

Industry Surveys

Practitioner First-Hand Accounts

Unverified Items

  • The response period for each edition of the zeroheight survey is not disclosed (both the 2026 and 2025 editions)
  • When Sparkbox’s controlled ROI experiment was conducted
  • When the UXPin and Whitespace survey was conducted
  • The ROI calculation formula and cost basis in the Figma and HP case study
  • The publication dates of IBM Carbon’s v10 color page, the Google Design article, and the Shopify Polaris contributing document
  • The content and methods of Sousa and Lélis (2026) and Maia et al. (2026)
  • The original text of EN 301 549 clauses (the ETSI PDF returns 403), and the ISO-side bibliography of ISO/IEC 40500:2025

← All Notes · Home