HIF / Documentation / Major platforms

Industry Design Systems

Status: comparative reference

Version: 0.1

This document compares major public design systems and platform guidance. It does not reproduce their visual styles. It extracts the transferable principles, operating practices and quality criteria that can strengthen HIF.

The comparison is based only on official, English-language sources published by the organisations that own the systems.

1. How to read this document

1.1 Evidence classes

Every imported idea MUST be classified before it can affect a Product Profile:

Platform convention — behaviour people reasonably expect on a named operating system, device class or distribution channel. It is mandatory where the target platform requires it or where departing from it would break interoperability, accessibility or learned behaviour.
External standard — a normative requirement from an applicable specification, regulation or contract. The source, version and scope MUST be recorded.
System convention — a rule required to produce an experience that belongs to a particular product ecosystem, such as Shopify Admin or Salesforce Lightning. It is mandatory only inside that ecosystem.
Heuristic — a useful, testable recommendation. It is not universally true and MUST NOT be presented as a platform or legal requirement.
HIF decision — a local normative choice made through HIF governance. It remains traceable to evidence and can be revised.

Popularity is not evidence of universality. A rule used by a large company may be excellent for that company's users, business model and technology while being wrong for another context.

1.2 Precedence

For a conforming product, conflicts are resolved in this order:

applicable law, safety obligations and external standards;
the HIF Constitution;
target-platform interaction and accessibility conventions;
the approved Product Profile;
the adopted design-system release;
product-specific patterns and components;
visual preference.

A platform convention MUST NOT be copied to another platform merely to create visual sameness. Cross-platform products preserve task, object and command semantics while adapting presentation, input, navigation, windowing and system integration.

1.3 Scope of comparison

The systems were selected because they provide one or more of:

a platform-scale interaction language;
public quality or assessment criteria;
a mature token, component and pattern architecture;
accessible implementation guidance;
a contribution, maturity or release model;
evidence from high-volume public, enterprise or professional software.

2. Comparative map

System	Primary context	Distinctive contribution	Platform-bound elements
Google Material Design 3	Multi-device products, especially Android	Adaptive layouts, semantic roles, explicit component states, expressive theming	Android navigation, system surfaces, Compose and device conventions
Android quality guidance	Android apps and Google Play	Testable minimum quality, lifecycle resilience, adaptive form factors, technical quality	Android lifecycle, back behaviour, permissions, windowing and distribution rules
web.dev	The web	Field performance metrics, progressive enhancement, semantic and accessible web implementation	Browser APIs, HTML semantics and web performance metrics
Apple Human Interface Guidelines	Apple platforms	Native familiarity, platform differentiation, system capabilities, accessibility preferences	iOS, iPadOS, macOS, watchOS, tvOS and visionOS conventions
Microsoft Fluent 2 and Windows	Microsoft products and Windows apps	Natural adaptation by platform, focus, semantic token layers, complete desktop integration	Windows windowing, shell, input, materials and system controls
IBM Carbon	Enterprise and data-rich products	Explicit definition of done, contribution lifecycle, component accessibility status, role-based theming	IBM brand expression and IBM-specific product conventions
Adobe Spectrum	Professional, creative and cross-platform tools	Rational component behaviour, desktop/mobile scales, transparent status and individual versioning	Adobe brand and specialised creative-tool conventions
Salesforce Lightning	Salesforce platform and enterprise workflows	Implementation-agnostic blueprints, styling hooks, enterprise consistency	Salesforce information architecture, platform components and Lightning runtime
Shopify Polaris	Shopify Admin and embedded commerce apps	Domain language, accessible reuse, merchant task consistency	Shopify Admin navigation, commerce terminology and app-review expectations
Atlassian Design System	Collaborative enterprise products	Opinionated foundations, semantic tokens, self-service documentation and enterprise scale	Atlassian product shell and brand conventions
GOV.UK Design System and Service Standard	UK public services	Whole-service thinking, research-backed patterns, progressive enhancement and service assessment	GOV.UK identity and UK public-sector obligations
U.S. Web Design System	US federal websites and services	Principle-led incremental adoption, trust, continuity and accessibility maturity	US federal identity and statutory obligations
GitHub Primer	Dense developer productivity interfaces	Compact efficiency, component maturity, upstreaming and theme-safe semantic tokens	GitHub workflows, terminology and product identity

The table is an orientation tool, not a ranking. No listed system is a complete substitute for user research, domain modelling or end-to-end evaluation.

3. Google: Material Design 3, Android quality and web.dev

3.1 What the Google corpus contributes

Google exposes three useful but different layers:

Material Design 3 is a design language and reusable system;
Android quality guidance defines product and platform quality;
web.dev provides web-specific implementation and field measurement.

HIF MUST keep these layers separate. A product can use Material components and still fail Android lifecycle, accessibility, reliability or core-value tests. Likewise, a site can achieve visual consistency while failing real-user performance.

3.2 Transferable invariants

Adaptation is structural, not proportional. Material canonical layouts change navigation and pane composition at meaningful breakpoints. HIF SHOULD model compact, medium and expanded arrangements as transformations of the same objects and tasks, rather than stretching one canvas.
Interaction states are first-class. Enabled, disabled, hovered, focused, pressed, dragged and selected are distinct. Combined states require defined precedence and more than colour alone.
Quality includes value. Android explicitly separates core value, user experience, technical quality, and privacy and security. HIF reviews MUST reject the idea that visual polish can compensate for a product that is unreliable, misleading or not useful.
Real devices interrupt work. Rotation, folding, backgrounding, locking, process recreation, network loss and returning from another app are normal states, not edge cases.
Performance is user experience. On the web, HIF SHOULD measure LCP, INP and CLS from real-user data and SHOULD evaluate the 75th percentile separately for relevant device and connection segments. Current web.dev “good” reference thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. These are versioned Google heuristics, not timeless laws.
Metrics have a lifecycle. Experimental, pending and stable metrics MUST not be treated as equally durable. A quality profile records the metric definition and version.

3.3 Platform conventions

For Android products, Android's current navigation, predictive back, windowing, edge-to-edge, system bar, permission, adaptive-layout and lifecycle guidance are platform conventions. Standard Material components are the default where they correctly represent the product semantics.

Material colour, type, shape and motion choices are not universal requirements. Material's expressive features are optional stylistic and behavioural tools. Their use MUST remain compatible with reduced-motion, contrast, density, cultural and task constraints.

For web products, semantic HTML, browser navigation, addressable URLs, native form behaviour, keyboard operation, zoom, reflow and progressive enhancement take precedence over imitating an app shell.

3.4 HIF review questions

Does the product retain task and state continuity through every supported device posture and lifecycle transition?
Are all component states separately modelled, perceivable and testable?
Is field performance measured, or are conclusions based only on a fast lab machine?
Does the product create continuing user value, or merely engagement?
Are experimental platform features isolated behind a reversible adoption decision?

4. Apple Human Interface Guidelines

4.1 What Apple contributes

Apple's HIG treats “feels at home” as a platform-specific outcome. It combines foundations, patterns, components and input methods with separate guidance for each Apple platform. The transferable lesson is not Apple's visual appearance; it is disciplined use of system capabilities and respect for platform expectations.

4.2 Transferable invariants

Familiar controls reduce relearning. Prefer system-defined components and behaviours when they express the required semantics.
Platform identity matters. A phone, desktop, watch, television and spatial interface cannot share one interaction model unchanged.
Accessibility is adaptive. Interfaces SHOULD respond to larger text, increased contrast, reduced motion, reduced transparency, captions, assistive input and screen readers.
Focus is not selection. Focus identifies the current interaction target; selection changes or designates application state. Products MUST keep them separate whenever activation would cause a consequential transition.
Privacy is part of interface design. Requests for data or capabilities require context, purpose and timing that support an informed decision.

4.3 Platform conventions

On Apple platforms, system navigation, menu placement, keyboard shortcuts, window behaviour, gestures, sheets, alerts, sharing, permissions, typography scaling, safe areas and input conventions are platform conventions. Exact requirements vary by operating system and release and MUST be checked against the current HIG and SDK documentation.

SF Symbols, Apple materials, system typefaces and Apple design resources have platform and licence constraints. HIF MUST NOT treat them as a white-label asset library.

4.4 HIF review questions

Which behaviours are shared semantically, and which are adapted per Apple platform?
Does content remain usable at supported Dynamic Type sizes without clipping, overlap or hidden actions?
Do VoiceOver labels communicate role, value, state and outcome?
Are system preferences respected without requiring a duplicate in-app setting?
Would custom UI remove a capability already supplied by a system control?

5. Microsoft Fluent 2 and Windows

5.1 What Microsoft contributes

Fluent's principle “natural on every platform” explicitly supports using native components and familiar patterns for most of an experience, reserving custom expression for signature moments. Windows guidance extends the interface beyond the content canvas to windows, title bars, inputs, shell integration, installation, update, performance, security and accessibility.

5.2 Transferable invariants

Consistency is behavioural before visual. Familiar interaction and complete task flow matter more than identical rendering.
Focus is a product property. Reduce clutter, protect the person's flow and place primary work ahead of decoration.
Semantic tokens separate meaning from value. Fluent distinguishes raw global tokens from alias tokens with contextual meaning. HIF SHOULD use the same separation.
A desktop app participates in an operating system. Window activation, resizing, multiple inputs, title bars, file handling, notifications, install/update/uninstall and power use all affect experience quality.
Content is functional UI. Helpful, concise, active language and responsibility-taking error messages reduce task cost.

5.3 Platform conventions

On Windows, keyboard and pointer support, system windowing, focus visibility, high-contrast and forced-colour behaviour, scaling, title-bar controls, shell integration and standard shortcuts are platform conventions. Mica, Acrylic and other signature materials are conditional Windows treatments, not universal hierarchy mechanisms.

The Windows principles “Effortless, Calm, Personal, Familiar, Complete and Coherent” are design heuristics. They are useful review lenses but are not individually testable requirements until a Product Profile defines evidence.

5.4 HIF review questions

Can the complete experience be operated with keyboard, pointer, touch and supported assistive inputs?
Does the app behave correctly as a resizable, activatable system window?
Do semantic tokens remain correct in light, dark and forced-colour modes?
Are installation, update, interruption and recovery included in the journey map?
Is brand expression concentrated where it does not displace familiar controls?

6. IBM Carbon

6.1 What Carbon contributes

Carbon demonstrates how an enterprise design system can combine working code, design assets, guidelines, contribution and community. Its most transferable strength is operational explicitness: components have a product-development lifecycle, a definition of done and visible accessibility status.

6.2 Transferable invariants

A component solves a named interface problem. Reuse is justified by stable semantics and behaviour, not merely repeated appearance.
Stable means complete. Design specification, code, documentation, design-kit representation, accessibility and tests form one release unit.
Accessibility status is multidimensional. Default render, advanced states, keyboard navigation and screen-reader behaviour SHOULD be reported separately; “accessible” is not a single badge.
Role-based tokens enable themes. Token roles remain stable while theme values change. Component-only tokens MUST NOT leak into unrelated use.
Migration is a designed experience. Feature flags can expose future breaking behaviour without silently changing a current major release.
Content guidance belongs inside the system. Action labels, errors and tone are part of component quality.

6.3 System conventions

Carbon's IBM brand palette, typography, grid and branded motion are IBM system conventions. Its component checklist, accessibility status model, role-based tokens and contribution process are transferable heuristics that HIF SHOULD adapt.

6.4 HIF review questions

Is the component's problem statement more stable than its current visual form?
Can consumers see implementation and accessibility maturity before adoption?
Does “done” include documentation and design assets, not just merged code?
Can a breaking change be previewed, measured and migrated?
Are domain extensions governed without fragmenting core semantics?

7. Adobe Spectrum

7.1 What Spectrum contributes

Spectrum is optimised for complex professional tools across platforms. Its principles — rational, human and focused — are supported by research, testing, cross-platform scale, inclusive design and transparent component status.

7.2 Transferable invariants

Professional density and touch ergonomics require different scales. Component proportions can change while roles and relationships remain stable.
Complexity should be purposeful. Professional capability does not justify ambiguous icons, undocumented states or irrelevant decoration.
Voice is stable; tone responds to context. Errors, onboarding and routine controls SHOULD not use identical emotional intensity.
Status creates trust. Individual versioning, open issues, checklists and implementation availability expose the real maturity of a component.
Custom interactions require multiple inputs. Mouse, keyboard, pen, touch, voice and accessibility APIs must be considered where supported.
Examples are part of the contract. Example code MUST demonstrate an accessible composition, not merely an isolated component.

7.3 System conventions

Spectrum's icon language, Adobe brand expression, exact scales and creative-tool conventions are system-specific. Transparent status, accessible examples, responsive scale and contextual tone are transferable.

7.4 HIF review questions

Has density been tested with experts without making it inaccessible to other input and perception modes?
Are all public examples safe to copy into production?
Does a component declare supported browsers, platforms and input methods?
Is each release channel clearly labelled stable, beta or experimental?
Is customisation achieved through supported semantics rather than internal styling hacks?

8. Salesforce Lightning Design System

8.1 What Lightning contributes

Lightning demonstrates separation between a design specification and its runtime implementation. Its component blueprints combine semantic HTML, CSS, accessibility attributes and behavioural guidance, while base components provide maintained implementations. Styling hooks allow supported customisation without replacing component internals.

8.2 Transferable invariants

Blueprints are technology-neutral contracts. Anatomy, semantics, accessibility and behaviour can be specified independently from React, Web Components or another implementation.
Supported extension points prevent forks. A limited, documented styling API is safer than consumers overriding private selectors.
Platform components carry maintenance. When an accessible maintained base component exists, using it usually costs less than rebuilding the blueprint.
Enterprise consistency includes data-entry rules. Saving, validation, permission, record identity and long-running operations need shared patterns, not only shared controls.
Deprecation must be explicit. A token or styling mechanism can remain functional while no longer being the recommended path.

8.3 System conventions

Lightning component structure, Salesforce record concepts and platform shell are Salesforce conventions. Outside Salesforce, HIF MAY adopt the blueprint model but MUST NOT create a visual imitation that falsely suggests platform integration.

8.4 HIF review questions

Is the specification independent from a single framework?
Are public extension points semantic, constrained and versioned?
Does the maintained implementation match the documented blueprint?
Can product teams upgrade without depending on internal DOM or CSS?
Are record, permission and validation semantics consistent across workflows?

9. Shopify Polaris

9.1 What Polaris contributes

Polaris centres a design system on a specific work domain: commerce performed by merchants and partners inside Shopify. Its accessibility guidance begins with native web standards, uses ARIA only where native HTML is insufficient, and warns that accessible components do not make an inaccessible composition accessible.

9.2 Transferable invariants

Domain language is infrastructure. Shared names for merchant objects, states and actions reduce ambiguity more than visual consistency alone.
Native behaviour is the first option. Custom controls require a demonstrated need, clear instructions, full testing and preferably an additional standard way to complete the task.
Reusable accessibility has leverage. A fix in a shared component can benefit every adopting product.
Composition still owns the outcome. Focus order, labels, information architecture, errors and complete journeys remain the product team's responsibility.
Ecosystem fit is measurable. An embedded app should not force merchants to relearn routine Shopify Admin tasks.

9.3 System conventions

Inside Shopify Admin, its navigation, terminology, app surfaces and current Polaris implementation guidance are system conventions and may also be distribution requirements. Outside that context, Shopify's visual language and merchant terminology MUST NOT be copied.

9.4 HIF review questions

Does the interface use the domain's established object and action names?
Could a native element solve the problem with less behavioural risk?
Has the composed journey been tested beyond isolated component conformance?
Does an embedded experience preserve host navigation and expectations?
Is the product's own brand subordinate to host-platform trust where needed?

10. Atlassian Design System

10.1 What Atlassian contributes

Atlassian frames its system as foundations, components, content and tools maintained across disciplines. It deliberately prefers trusted fundamentals to an unlimited component catalogue and system needs to one product's immediate feature.

10.2 Transferable invariants

Do not optimise for infinite flexibility. Opinionated, composable building blocks are easier to learn, test and maintain than an unrestricted configuration surface.
Documentation, support and tooling are product features. Shipping code without them leaves adoption incomplete.
Semantic token names express use. Teams select a token by meaning rather than by a currently matching colour or size.
Tooling enforces migration. Typed accessors, linters, codemods and deprecation warnings keep design decisions aligned with production code.
Built-in accessibility is a basis, not a guarantee. Patterns, content and end-to-end interaction still require review.
Self-service is a governance goal. Consumers should be able to make correct routine decisions without waiting for a central team.

10.3 System conventions

Atlassian brand expression and product-shell patterns are system-specific. Semantic token discipline, constrained flexibility, migration tooling and self-service documentation are highly transferable.

10.4 HIF review questions

Is a new option solving a recurring need or avoiding a product decision?
Can tooling detect raw values, deprecated tokens and unsupported use?
Does documentation explain how components combine into complete patterns?
Is central review reserved for consequential novelty rather than routine use?
Can the system evolve once without manual search-and-replace across products?

11. GOV.UK Design System and Service Standard

11.1 What GOV.UK contributes

GOV.UK makes the strongest distinction in this corpus between a component library and a successful service. The Design System contains researched styles, components and patterns; the Service Standard assesses the whole problem, joined-up channels, inclusion, security, measurement, technology and reliable operation.

11.2 Transferable invariants

Solve the whole problem. A polished transaction is insufficient when the surrounding eligibility, evidence, offline, support or follow-up journey fails.
Start with user needs and observed behaviour. Research findings and service data justify patterns. Organisational preference does not.
Progressive enhancement creates resilience. Start with semantic HTML; retain content without CSS; preserve a functional path without JavaScript where the service permits.
Accessible components do not make an accessible service. Research, content, integration and testing are still required.
Reuse before invention. Search existing patterns, evidence and community work before creating a new solution.
Make maturity and uncertainty visible. Published patterns, experimental work and community examples MUST not appear equally assured.
Define and publish success measures. Quality is an operating obligation, not a launch ceremony.
Plain language is interaction design. Content order, labels, questions and errors materially determine completion and error rates.

11.3 Platform and service conventions

GOV.UK branding, exact component appearance and UK government content rules are mandatory only for applicable GOV.UK services. Legal accessibility and service assessment duties depend on jurisdiction and organisational scope.

Whole-service thinking, evidence-backed patterns, progressive enhancement and publicly accountable measures are transferable HIF practices.

11.4 HIF review questions

What is the whole user problem, including channels outside the interface?
What evidence supports each non-standard pattern?
Does the essential journey survive partial failure and constrained devices?
Have people with access needs participated in research and testing?
Are success, failure and abandonment measured without creating harmful incentives?

12. U.S. Web Design System

12.1 What USWDS contributes

USWDS allows incremental adoption through three nested levels: principles, guidance and code. This avoids equating a package installation with design system maturity. Its principles place real user needs, earned trust, accessibility, continuity and listening ahead of visual uniformity.

12.2 Transferable invariants

Principles can precede code. A team can improve decisions before it can migrate every interface.
Trust is earned repeatedly. Reliability, honesty, privacy, continuity and stewardship of people's time and data are interface qualities.
Consistency is not conformity. Shared solutions reduce disruption, but different missions and audiences can require different expressions.
Accessibility is a design constraint, not a compliance afterthought.
Listening is continuous. Direct research, feedback, support evidence and behavioural analytics reveal different parts of experience.
Adoption maturity is multidimensional. A product may use code without the principles, or principles without broad component coverage; both facts should be visible.

12.3 System conventions

US federal identity, banners, legal notices and statutory requirements are system-specific. The maturity model and trust-centred principles are transferable heuristics.

12.4 HIF review questions

Is adoption measured at principles, guidance and code levels separately?
Which interactions establish or damage trust?
Does continuity span agencies, products, devices and time?
Does feedback reach the teams empowered to change the service?
Are local differences evidence-based or merely historical?

13. GitHub Primer

Primer is included as an additional system because it demonstrates mature governance for dense, high-frequency professional interfaces.

13.1 Transferable invariants

Efficiency and accessibility are joint requirements. Compact interfaces can remain inclusive when semantics, focus, targets and alternatives are engineered from the start.
Component maturity must be public. Experimental, ready and deprecated states establish different consumer expectations.
Upstream only recurring, proven solutions. A product-local component can mature through real use before becoming a system commitment.
Theme-safe tokens are semantic. Base values are implementation inputs; functional and component tokens are the consumer API.
Migration accompanies breaking change. Stable consumers need a versioned path, not only a release announcement.
Documentation has production criteria. Accurate examples, meaningful copy, alt text, links and review are part of release quality.

GitHub-specific workflow terminology, density and brand treatments remain system conventions.

14. Cross-industry invariants adopted by HIF

The following propositions recur across independent systems and are compatible with the HIF Constitution. HIF adopts them as default engineering and governance requirements, subject to formal incorporation in normative documents.

14.1 Semantics and behaviour

Start from people, tasks, objects, commands, state and consequences.
Preserve semantic continuity across themes, platforms and representations.
Use native or established controls before creating custom interaction.
Specify every supported state, transition, input method and failure mode.
Keep focus, selection, activation, expansion and checked state distinct.
Design system components MUST expose semantics, not just styling.

14.2 Accessibility and inclusion

Accessibility begins in research and architecture, not in final audit.
Standards-conformant components are necessary but not sufficient.
Automated, keyboard, screen-reader, zoom/reflow, contrast, forced-colour and human testing provide different evidence and MUST be reported separately.
System preferences for text size, contrast, colour scheme and motion SHOULD be respected by default.
Information MUST NOT depend on colour, position, motion, sound or gesture alone.

14.3 Adaptation

Adapt layout and navigation to available space, input and posture without changing object identity or hiding essential capability.
Platform conventions outrank cross-platform pixel equality.
Supported device, browser, input, locale and assistive-technology matrices MUST be explicit.
Density is a Product Profile decision informed by task frequency, expertise, input precision and access needs.

14.4 Content

Content design is part of interaction design and component specification.
Use stable domain vocabulary, descriptive labels and outcome-oriented messages.
State what happened, its consequence and the next available action.
Voice may be stable; tone MUST respond proportionately to context and risk.
Content MUST be structured for localisation rather than translated after layout is fixed.

14.5 System architecture

Separate raw values, semantic roles and component decisions.
Provide maintained components, patterns, design assets, code, documentation and tests as aligned representations of one system.
Prefer supported extension points to consumer overrides of private internals.
Record maturity, support, accessibility and deprecation independently.
A shared component is justified by a recurring semantic problem and evidence from more than one context.

14.6 Quality and governance

Define “done” before accepting a component into the stable system.
Require evidence and ownership for new patterns.
Treat documentation, migration and support as release deliverables.
Measure complete journeys, technical quality and user outcomes, not only component adoption or visual consistency.
Publish known limitations and uncertainty.
Review high-impact failures before aesthetic inconsistency.

15. Important differences HIF preserves

Convergence does not remove legitimate differences:

Native versus branded. Apple and Windows prioritise platform familiarity; enterprise systems often prioritise product-family consistency. HIF chooses according to host-platform expectations and product context.
Comfort versus density. Public services often favour simple, single-purpose pages; professional tools may need dense, persistent workspaces. Both require evidence and accessibility.
Progressive enhancement versus application runtime. It is a strong default for public web services, but an offline creative tool or operating system shell has a different execution model.
Central control versus community contribution. Systems range from centrally governed to open contribution. HIF requires clear decision rights, evidence and lifecycle regardless of organisation shape.
Uniformity versus continuity. Identical visuals are rarely necessary. Stable meaning, predictable outcomes and coherent movement between surfaces are necessary.
Minimum compliance versus excellence. WCAG conformance, store rules and platform checklists establish floors. Usability, dignity, trust and value still require research and outcome evaluation.

16. Rules for using external systems in a Product Profile

A Product Profile that adopts or references an external design system MUST record:

system name, release and retrieval date;
target platforms and distribution channels;
which parts are platform conventions, system conventions or heuristics;
adopted packages, assets and licences;
supported browsers, devices, inputs and assistive technologies;
token mapping and theme ownership;
component and pattern exceptions;
known accessibility gaps;
migration and update policy;
evidence that end-to-end tasks remain conformant with HIF.

“Uses Material”, “uses Carbon” or “uses Polaris” is not a quality claim. The profile MUST identify what is used, why it is appropriate, and how the resulting experience is verified.

17. Sources

All sources in this section are official English-language publications. Retrieval date: 30 July 2026.