Design systems across websites and apps

Answered 5 October 2026: all 2 recommendations accepted. A design system brings reusable components, patterns and guidance together. A captured screen shows one particular use of those things. We need to help people research both without pretending that every screen defines the system behind it.

The recommendations below are the accepted meanings. Examples and alternatives are retained as the review record; no further answer is needed on these choices.

Choice	Recommendation
Web and app design systems	Use Digital Design System as the shared meaning, with supported platform scope. Preserve genuinely distinct systems.
Responsive layout rules	Keep a named, searchable description for how layouts adapt, alongside the broader layout and grid description.

What is already settled

You already approved separate relationships for where content was collected and what it depicts. Useful document parts can be independently browsable with a link back. Documented claims also remain distinct from our interpretation. Those decisions carry forward here; they do not need another answer.

Your older identity list proposed Web Design System, App Design System, Responsive Rules and App Icon Suite. Its bundled question also covered physical environments. This page resolves only the two choices below. It does not approve the environment list, the icon suite or a new whole-piece content type.

1. A design system can support more than one platform

Recommendation: use Digital Design System for the shared concept, with evidence of the platforms it supports. Keep Web and App as useful ways to narrow the research. Do not require a different system just because one library serves a website and another serves a native application.

Checked example: Microsoft Fluent's development guide presents a common design language with platform-specific libraries for web, iOS, Android and Windows. Someone researching Fluent should be able to find that common context and then inspect a particular platform's components or guidance. Platform libraries remain distinguishable; they are not interchangeable files.

Counterexample: a company's marketing website and native product may use different systems. Matching ownership or a similar button does not prove shared membership. If sources establish two systems, keep both. An unknown relationship stays unknown.

Alternative: retain Web Design System and App Design System as separate identity-element kinds, linking related systems where supported. That makes each entrance explicit, but makes a system spanning both harder to describe without repeating it. I recommend one common meaning and explicit platform scope, while preserving real differences between systems and their versions.

What changes downstream: capture the guideline or component source and connect it to the system it documents. Link an observed screen only as far as the evidence permits. Research can move from a system to its web examples, app examples and supported products without copying the same source into unrelated records. A product can use more than one system over time; a system can support more than one product. Neither relationship should be inferred from the company name alone. Exact storage remains an architecture decision after the audit.

2. Keep adaptation rules findable

Recommendation: keep Responsive Layout Rules as a named, searchable description of guidance for adapting a layout to available space. This can cover breakpoints, changes in columns and navigation, and how panels affect content. It can overlap with Layout and Grid System; it need not compete for one exclusive heading.

Checked example: Carbon's 2x Grid guidance documents breakpoints, fluid columns, fixed boxes and panel behavior. A researcher looking for adaptation rules should be able to find this guidance directly, rather than opening every item labelled layout.

Counterexample: a single screenshot with three columns establishes an appearance at that capture's conditions. It does not establish the intended rules at other sizes. Observing the page at several sizes can support a description of its behavior, but does not turn our observation into the owner's documented guidance.

Alternative: keep adaptation details only inside Layout and Grid System, searchable through its description without a dedicated vocabulary choice. That is a smaller list, but makes a recurring research question less precise. I recommend the named description because people may specifically want to compare how different systems handle limited space.

What changes downstream: guideline extraction identifies the relevant passage; screen analysis describes what was observed and under which conditions. Search, tracker rules and cited answers preserve that difference. The new choice is whether to retain this particular vocabulary entry, not whether evidence and interpretation should be separate—that is already settled.

Joe also cautioned against excessive detail on responsive rules. The answer does not require exhaustive breakpoint analysis for every captured screen.

What remains outside these choices

These are approved identity descriptions, not authorization to relabel records, create tables or change the pipeline. The icon and component review separately covers app identity and searchable interface-component descriptions. The environment descriptions and both icon/component meanings are now also approved. Exact platform and component vocabulary, versions, system membership and implementation retain their outstanding work.

The evidence note explains the checked sources and selected local and database findings. The complete publication, correction and monitoring paths remain to verify. Approving a meaning does not certify those paths.

Both named recommendations are approved. The later environment and icon/component answers complete the displayed meaning choices in the original bundle; exact definitions and implementation still require verification.

Return to the morning review desk for the other independent packets.

Prepared 5 October 2026.

Last reviewed 5 October 2026.