9. Design Systems and Scalable Component EngineeringIntroduction and ContextA digital product rarely fails because one button is poorly styled. It fails when hundreds of buttons, forms, navigation patterns, messages, and layouts evolve inconsistently across screens, platforms, and teams. Design systems address this problem by connecting design decisions, reusable interface components, implementation standards, documentation, and governance. A design system is more than a visual style guide and more than a component library. A style guide describes appearance; a component library provides reusable code; a design system combines these resources with principles, tokens, usage rules, contribution processes, accessibility requirements, and organizational ownership. Its purpose is to make product development more coherent, efficient, inclusive, and adaptable. For a postgraduate full stack developer, design systems are strategically important because they sit at the intersection of user experience, front-end architecture, product management, quality assurance, and organizational coordination. They influence how quickly a team can deliver features, how reliably interfaces behave, how easily products are themed or rebranded, and how much technical debt accumulates over time. This chapter examines the design and governance of scalable component ecosystems. It focuses on design tokens, component anatomy, variants and states, pattern libraries, documentation, theming, framework integration, contribution models, technical debt, and designer–developer collaboration. Learning ObjectivesAfter studying this chapter, the learner should be able to: 1. Distinguish a design system from a style guide, pattern library, and component library. 2. Explain how design tokens create consistency across products and technologies. 3. Design reusable components with clear anatomy, variants, states, and accessibility behaviour. 4. Evaluate the trade-offs between flexibility, standardization, and component complexity. 5. Plan documentation, governance, contribution, versioning, and adoption processes. 6. Integrate design-system assets with front-end frameworks and delivery workflows. 7. Identify technical debt, organizational risks, and ethical concerns in design-system development. 8. Apply design-system principles to a realistic product scenario. From Visual Consistency to a Product Operating ModelThe central idea of a design system is not sameness for its own sake. Consistency reduces unnecessary cognitive effort for users and lowers repeated decision-making for teams. If a primary action appears as a blue filled button in one workflow and as a thin grey link in another without a meaningful reason, users must interpret the interface rather than complete their task. Similarly, when developers independently implement the same interaction several times, defects and maintenance costs increase. A mature design system operates at several levels. At the foundational level are principles, design tokens, typography, colour, spacing, elevation, motion, icons, and accessibility rules. At the component level are controls such as buttons, inputs, dialogs, tabs, cards, and data tables. At the pattern level are recurring combinations such as search interfaces, checkout forms, authentication flows, and empty states. At the product level are templates, page structures, and domain-specific experiences. These levels should not be confused. A token such as `color.action.primary` is a foundational decision. A button maps that token to a component state. A form pattern combines buttons, inputs, validation messages, and layout rules. A product team then applies the pattern to a specific business task. Reusability becomes more reliable when decisions are made at the appropriate level rather than copied indiscriminately. A design system can therefore be viewed as a socio-technical system. It includes code and design files, but also people, decision rights, quality criteria, release processes, and communication channels. A technically excellent library may fail if teams cannot discover it, do not trust its quality, or have no safe way to request changes. Important Concepts and TerminologySeveral terms are closely related but have different meanings. A style guide records visual rules such as colour, type, imagery, and spacing. A pattern library documents recurring solutions to common interaction or content problems. A component library is a collection of coded, reusable interface elements. A design system encompasses these resources and the principles, governance, workflows, and documentation that connect them. A design token is a named value representing a design decision, such as a colour, spacing unit, font size, border radius, or animation duration. A component API is the public interface through which developers configure a component, including properties, events, slots, and composition rules. A variant is a deliberate visual or behavioural version of a component, such as primary, secondary, compact, or destructive. A state represents a condition during interaction, such as hover, focus, disabled, loading, error, or selected. Composition means building a larger experience from smaller components. Cohesion describes whether a component has a focused and understandable purpose; coupling describes how strongly it depends on other components or implementation details. Theming is the controlled replacement of design values to support brands, modes, products, or accessibility preferences. Governance consists of the decision-making structures and processes that maintain system quality. Technical debt is the future cost created by expedient decisions, outdated dependencies, duplication, weak documentation, or incompatible abstractions. Design Tokens: Encoding Design DecisionsDesign tokens provide a shared vocabulary between design tools and code. Instead of repeatedly entering a literal value such as `#1769AA` or `16px`, a team uses a semantic name such as `color.text.link` or `space.4`. The name communicates intent and allows the underlying value to change without editing every component. Tokens are commonly organized in layers. Primitive tokens represent raw values, for example a blue colour scale or a spacing scale. Semantic tokens assign meaning to those values, such as `color.background.surface` or `color.border.focus`. Component tokens describe how a particular component uses semantic decisions, such as `button.primary.background`. This layered approach separates value from purpose. A useful token architecture might contain: - Primitive tokens: raw colour, type, spacing, radius, and shadow values.
- Semantic tokens: roles such as text, surface, action, feedback, and focus.
- Component tokens: context-specific assignments for buttons, fields, menus, or dialogs.
Semantic tokens are especially important for themes. A dark theme should not require every component to know that a particular dark blue replaces a light blue. Instead, both themes map the same semantic role to different values. This preserves intent while allowing controlled variation. Tokens should be named according to stable meaning rather than temporary appearance. `color.blue.500` describes a value; `color.action.primary` describes its role. The former may be useful at the primitive level, while the latter is more useful to product teams. Token names also require governance: inconsistent naming, duplicate values, and uncontrolled aliases make the system difficult to learn. Tokens do not eliminate design judgement. A token can standardize spacing but cannot decide whether a layout has too much information. Nor should every unique value be converted into a token. Excessive tokenization creates a catalogue that is difficult to understand and encourages arbitrary customization. Component Engineering: From Anatomy to BehaviourA reusable component should be designed as a behavioural contract, not merely as a visual rectangle. Its specification should identify anatomy, purpose, inputs, outputs, states, accessibility behaviour, responsive behaviour, and appropriate use. Consider a dialog. Its anatomy may include a backdrop, title, description, content region, close control, and action area. Its contract should define how it opens and closes, whether focus moves into it, how focus is trapped, what happens when the Escape key is pressed, how it behaves on small screens, and how assistive technologies identify it. A screenshot alone cannot express these requirements. Component design usually involves the following questions: 1. What user problem does the component solve? 2. Which parts are stable and which require composition? 3. Which properties are essential, and which create unnecessary flexibility? 4. What are the default, interactive, validation, loading, and failure states? 5. How does the component behave with long text, localization, zoom, and narrow viewports? 6. What accessibility semantics and keyboard interactions are required? 7. Can it be tested independently and used consistently across teams? A component should expose a small, meaningful API. A button may need a label, type, variant, size, disabled state, loading state, and optional icon. It normally should not expose dozens of styling flags that allow every consumer to create a new visual design. An excessively flexible component becomes difficult to test and impossible to govern; an excessively rigid component causes teams to bypass it. Variants, States, and the Complexity BudgetVariants express intentional differences, while states express conditions arising from use. Confusing these categories produces incomplete systems. For example, “danger” is usually a variant expressing the consequence of an action; “disabled” is a state expressing availability. “Compact” may be a size variant; “focus-visible” is an interaction state. Every variant multiplies testing and documentation requirements. If a component has four variants, three sizes, six states, two themes, and three responsive contexts, the possible combinations can become large even when not every combination is meaningful. Teams should therefore establish a complexity budget. A new variant should answer a real product need, support a distinct user task, and have a documented relationship to existing options. States should be designed rather than left to browser defaults or individual developers. Important states include default, hover, focus-visible, pressed, selected, disabled, loading, success, warning, error, and empty. Not every component uses every state, but the absence of a state should be an explicit decision. Focus treatment deserves particular attention because removing outlines without providing an equivalent indicator harms keyboard users. Responsive behaviour is also part of the component contract. A data table may become horizontally scrollable, transform into a card list, or retain its structure with reduced columns. The correct choice depends on the task and information hierarchy, not simply on screen width. Pattern Libraries and Documentation as Design InfrastructureDocumentation is the interface between the design system and its users. It should explain not only what a component looks like, but why and when it should be used. Effective documentation normally includes purpose, anatomy, examples, properties, states, content guidance, accessibility requirements, responsive behaviour, do-not-use guidance, and links to source code and design assets. A good example is often more valuable than a long property table. However, examples should show realistic content, edge cases, and failure conditions rather than only ideal screenshots. A form-field page should demonstrate labels, helper text, validation, long error messages, required indicators, and disabled behaviour. Documentation has at least three audiences. Designers need visual rules and component configurations. Developers need APIs, installation instructions, version compatibility, and implementation examples. Product managers and content specialists need usage guidance and limitations. Documentation should therefore support both quick discovery and deeper reference. A pattern library should distinguish approved patterns from exploratory concepts. Publishing every experiment as an official pattern creates ambiguity. Status labels such as experimental, proposed, stable, deprecated, and retired can communicate maturity, although the labels must have defined meanings. Governance, Contribution, and Lifecycle ManagementGovernance prevents a design system from becoming either a chaotic collection of preferences or an authoritarian bottleneck. It determines who can approve changes, how proposals are evaluated, how breaking changes are communicated, and how adoption is measured. A practical governance model often includes a core team responsible for foundations and shared components, representatives from product teams, and subject-matter contributors in accessibility, content, engineering, and research. Decision rights should be clear. The core team may own token architecture and release quality, while product teams provide evidence about real use cases. A contribution process should make the safest path the easiest path. A proposal can include the problem, affected users, evidence of repetition, alternatives considered, accessibility implications, API proposal, migration impact, and test plan. Contributions should be reviewed for usability, visual consistency, code quality, accessibility, performance, and long-term maintenance. Versioning is essential when components are shared across products. Changes that alter markup, keyboard behaviour, visual meaning, or public properties may be breaking even if the code compiles. Deprecation should provide a migration path, a clear timeline, and tooling where possible. A changelog should explain user-visible effects rather than only listing commit identifiers. Adoption should be encouraged through quality and service, not merely mandated. Useful measures may include component reuse, time to implement common flows, accessibility defect rates, duplicate patterns, documentation search success, migration completion, and developer satisfaction. Metrics should diagnose improvement rather than become simplistic performance targets. Framework Integration and Delivery ArchitectureA design system must fit the technical environment in which it operates. In a component-based framework, components may be distributed as a package, a monorepo workspace, a web-component library, or framework-specific implementations. Each approach involves trade-offs. A framework-native library may provide excellent integration with properties, events, styling, and server rendering, but may be difficult to share across different frameworks. Web components offer broader interoperability but can introduce challenges involving styling, forms, server-side rendering, and framework conventions. Multiple framework implementations may provide a better developer experience but increase maintenance and parity work. The architecture should clarify ownership of styling and behaviour. Tokens may be exported to CSS custom properties, native mobile platforms, or other environments. Automated pipelines can transform a canonical token source into platform-specific formats. Storybook-like environments or equivalent documentation tools can render components, test states, and support visual review. Quality assurance should operate at several levels: unit tests for logic, interaction tests for behaviour, accessibility testing, visual regression testing, cross-browser testing, and integration testing within real products. Automated testing is valuable, but it cannot determine whether a component solves the correct user problem. Research and product validation remain necessary. Continuous integration can check token naming, package builds, linting, type safety, accessibility rules, visual snapshots, and documentation completeness. Automation should support judgement rather than conceal it. A passing visual snapshot, for example, does not prove that colour contrast, content clarity, or interaction meaning is satisfactory. Theming, Accessibility, and Inclusive DesignTheming is often introduced for branding, dark mode, white-label products, or high-contrast preferences. A robust theme changes semantic tokens while preserving component behaviour and hierarchy. If a theme changes colour but reduces contrast or makes focus indicators invisible, it is not a successful theme. Accessibility must be a system property as well as a product-team responsibility. Shared components can provide reliable semantic HTML, keyboard interaction, focus management, accessible names, announcements, and contrast defaults. Nevertheless, product teams remain responsible for meaningful labels, content order, task flow, and context. Common accessibility failures include using colour alone to communicate status, placing placeholder text where a label is required, creating custom controls without keyboard support, allowing focus to disappear, and exposing visual variants that have no meaningful semantic distinction. Automated tools can detect some issues, but manual keyboard testing, screen-reader testing, zoom testing, and user research are also required. Inclusive design also involves localization, cultural interpretation, language length, motion sensitivity, motor accessibility, and variable connectivity. Components should tolerate text expansion, right-to-left layout where relevant, reduced-motion preferences, and touch interaction. These requirements should be recorded in component specifications rather than treated as late-stage corrections. Designer–Developer CollaborationDesign systems work best when design and engineering collaborate continuously rather than exchanging finished artefacts at handoff. Designers contribute user understanding, visual hierarchy, interaction models, content considerations, and research evidence. Developers contribute knowledge of platform constraints, browser behaviour, performance, accessibility implementation, and maintainability. Shared naming is a practical foundation for collaboration. A designer who calls a control “destructive button” and a developer who calls it “red button” are not discussing the same abstraction. Shared tokens, component names, acceptance criteria, and example states create a common vocabulary. A useful workflow begins with a problem and evidence, continues through joint exploration and component modelling, and ends with implementation, testing, documentation, and product validation. Design files should use library components linked to code where possible. Code should expose the same conceptual properties represented in design tools. Differences should be treated as issues to resolve, not silently accepted as normal. The relationship should not be reduced to design handing over screens and development reproducing them. In a mature team, both disciplines participate in deciding whether a pattern deserves system-level investment, whether a requirement is product-specific, and what trade-offs are acceptable. Technical Debt and Strategic Trade-offsDesign-system debt accumulates when teams duplicate components, introduce undocumented exceptions, retain obsolete tokens, bypass accessibility fixes, or add APIs without considering long-term use. It also accumulates socially when users lose trust in the system and create private alternatives. Not every inconsistency is debt. A deliberate product-specific decision may be appropriate when a domain has unique requirements. Debt exists when the cost or risk of a decision is hidden, repeated, or left without a maintenance plan. A system that attempts to standardize every experience may create a different form of debt: excessive abstraction. Common strategic tensions include: - Consistency versus contextual fit: shared patterns reduce learning effort, but unique tasks may require specialized solutions.
- Central control versus team autonomy: strong governance protects quality, but slow approval discourages adoption.
- Flexibility versus simplicity: configurable components serve more contexts, but large APIs increase cognitive and testing costs.
- Speed versus durability: a quick local implementation may be rational under deadline pressure, provided the exception is recorded and reviewed.
- Visual fidelity versus platform conventions: exact replication may conflict with native accessibility or responsive behaviour.
Debt management requires visibility. Teams can maintain an exception register, mark deprecated assets, track duplicated patterns, and schedule remediation alongside feature work. Refactoring should be prioritized by user impact, adoption, defect risk, and migration cost rather than aesthetic preference alone. Illustrative Case Study: Consolidating a Multi-Product Education PlatformBackgroundThe fictional organization LearnSphere operates a learner portal, instructor dashboard, assessment application, and mobile administration tool. Over several years, four product teams have implemented their own buttons, form fields, alerts, tables, and navigation systems. The products use two front-end frameworks and have separate design files. Situation and ProblemUsers report that similar tasks behave differently between the portal and assessment application. Keyboard users encounter inconsistent focus indicators. Developers estimate that approximately one-third of front-end work on new features involves recreating or adapting existing interface patterns. The organization wants a common visual identity and faster delivery, but product teams fear that a central library will restrict their domain-specific needs. AnalysisAn audit identifies six button implementations, four modal implementations, duplicated colour values, inconsistent error messages, and undocumented exceptions for mobile screens. The problem is not merely visual inconsistency. Different keyboard behaviour and validation patterns create usability and accessibility risk. A single rewrite would also be risky because the products have different release schedules and framework constraints. Approach and StrategyThe organization establishes a cross-functional design-system group with representatives from each product, accessibility expertise, and a release manager. It first defines principles: accessible by default, composable rather than over-configured, evidence-informed, and compatible with gradual adoption. The team inventories existing patterns and ranks them by frequency, risk, and opportunity for reuse. It begins with tokens, typography, colour roles, focus treatment, buttons, form fields, alerts, and modal behaviour. Primitive values are separated from semantic roles so that a dark theme and a high-contrast theme can be introduced without rewriting component logic. Each component receives a documented contract covering anatomy, states, keyboard behaviour, responsive rules, content guidance, and API. The team publishes an initial package for the newer framework and a standards-based token and accessibility layer for the other framework. Instead of forcing immediate migration, it provides adapters and codemods for common properties. A contribution process allows product teams to propose extensions. A proposal must show that a need cannot be met through composition or an existing variant. The system group reviews accessibility, API complexity, and product evidence. Exceptions are recorded with owners and review dates. OutcomeAfter the first release cycle, new teams use the shared components for common controls, while legacy products migrate incrementally. Visual and keyboard inconsistencies decline, and developers report that finding approved patterns is easier. Some specialized assessment interactions remain outside the core library, but they follow the shared token and accessibility standards. The organization avoids a disruptive rewrite and treats adoption as a product service rather than a compliance exercise. Learning PointsThe case demonstrates that successful design-system work begins with prioritization and governance, not with coding every possible component. Tokens create a foundation, but component contracts and documentation make that foundation usable. Compatibility layers and gradual migration reduce organizational resistance. Finally, a design system should standardize shared decisions while preserving legitimate domain-specific innovation. Challenges, Risks, and Common MistakesA frequent mistake is beginning with an attractive component catalogue without identifying product problems. Another is treating a design tool library as the complete system. Design assets that do not correspond to accessible, tested code create false confidence. Teams also create “mega-components” that contain every possible option. These components appear reusable but often have tangled APIs, unpredictable combinations, and poor documentation. Composition is usually safer: a small set of focused components can be combined into a pattern without making each component responsible for every context. Other risks include undocumented overrides, untested themes, visual regression suites that ignore behaviour, token names based on temporary branding, and governance meetings that approve changes without user evidence. A system may also become a bottleneck if its core team is under-resourced or disconnected from product delivery. There are organizational risks as well. Mandating adoption without migration support can cause teams to hide exceptions. Measuring success only by the number of components can reward unnecessary proliferation. The system should be evaluated by improved outcomes: reduced duplication, stronger accessibility, faster delivery of common experiences, and greater consistency where consistency benefits users. Professional and Ethical ConsiderationsDesign systems influence whose needs are considered normal. If shared components assume one language, one reading direction, perfect vision, high bandwidth, or precise pointer control, those assumptions become widespread. System governance should therefore include accessibility, localization, privacy, security, and inclusive-design review where relevant. Components that display personal or sensitive information require careful defaults. Data tables, notifications, analytics widgets, and account controls should avoid exposing information through insecure previews, unnecessary tracking, or misleading status language. Motion and persuasive interaction patterns should be reviewed for user autonomy and accessibility. Ownership must also be transparent. Contributors should receive recognition, and decisions should be documented so that authority does not depend on informal relationships. When a component is deprecated, users deserve a clear migration path rather than silent removal. Current Developments and Emerging DirectionsDesign systems are increasingly treated as product platforms rather than static repositories. Teams are connecting design tools, token pipelines, code packages, documentation sites, testing systems, and analytics. This enables more traceability between a design decision and its implementation, although synchronization remains technically and organizationally difficult. AI-assisted tools can generate component documentation, identify visual differences, suggest token mappings, and convert designs into preliminary code. Such outputs require expert review because generated code may reproduce inaccessible markup, invent unnecessary abstractions, or misinterpret interaction intent. AI is most useful when constrained by an established system, typed APIs, tests, and human governance. Newer systems also emphasize multi-platform delivery, supporting web, native mobile, email, and embedded interfaces through shared principles and tokens. The goal is not always identical rendering; it is coherent experience and shared intent across platform conventions. Best-Practice Framework for ImplementationA practical implementation sequence is as follows: 1. Establish the business and user problems that system investment should address. 2. Audit existing designs, code, patterns, defects, and accessibility gaps. 3. Define principles, ownership, contribution rules, and success measures. 4. Create a governed token architecture based on semantic roles. 5. Prioritize a small set of high-value, high-risk components. 6. Specify anatomy, APIs, variants, states, responsive behaviour, and accessibility. 7. Build design and code assets together, with automated and manual testing. 8. Publish documentation using realistic examples and explicit limitations. 9. Integrate releases with product workflows and provide migration support. 10. Review adoption, user outcomes, technical debt, and emerging needs continuously. The sequence is iterative rather than strictly linear. Evidence from implementation may reveal that a component is too broad, a token name is ambiguous, or a supposed common pattern is actually context-dependent. Mature teams treat such findings as system learning. Chapter SummaryDesign systems coordinate design decisions, reusable components, patterns, code, documentation, governance, and collaboration. Their strategic value lies in reducing unnecessary variation while preserving meaningful product differences. Design tokens encode stable semantic decisions and support theming across products and platforms. Components must be specified as behavioural contracts that include anatomy, APIs, variants, states, accessibility, responsive behaviour, and content conditions. Pattern libraries and documentation make the system discoverable and usable. Governance establishes ownership, contribution, versioning, deprecation, and quality standards. Framework integration requires deliberate choices about packages, web components, tokens, testing, and release architecture. Accessibility, localization, privacy, and inclusive design must be built into shared foundations. Finally, successful adoption depends on trust, migration support, designer–developer collaboration, and continuous management of complexity and technical debt. Key TermsDesign system: A governed collection of principles, tokens, components, patterns, documentation, and practices for creating consistent digital products. Design token: A named representation of a reusable design decision such as colour, spacing, typography, or motion. Semantic token: A token whose name expresses purpose or role rather than only a raw value. Component library: A collection of coded, reusable interface components. Pattern library: A documented collection of recurring solutions to interaction or content problems. Component API: The public properties, events, slots, and composition rules through which a component is used. Variant: An intentional version of a component that differs in appearance or behaviour for a defined purpose. State: A condition of a component during interaction or system operation, such as focused, disabled, loading, or invalid. Composition: Combining smaller components to create a larger interface or pattern. Theming: Replacing governed design values to support brands, modes, products, or accessibility preferences. Governance: Structures and processes for making, reviewing, maintaining, and communicating system decisions. Design debt: Future cost caused by inconsistent, outdated, duplicated, or poorly governed design decisions. Technical debt: Future maintenance cost created by expedient or suboptimal implementation decisions. Deprecation: The formal process of marking an asset for replacement or removal while providing migration guidance. Visual regression testing: Comparing rendered interfaces across versions to detect unintended visual changes. Accessibility: Designing and implementing products so that people with diverse abilities can use them effectively. Semantic HTML: HTML elements chosen according to their meaning and intended function. Design-system adoption: The extent to which product teams discover, use, and contribute to the shared system. Review QuestionsShort Answer Questions1. How does a design system differ from a component library? 2. What is the purpose of semantic design tokens? 3. Distinguish between a component variant and a component state. 4. Why should a component specification include keyboard behaviour? 5. What is the purpose of a deprecation process? Long Answer Questions1. Explain how tokens, components, patterns, and product templates relate to one another in a design-system architecture. 2. Discuss the governance practices required to maintain a design system across multiple product teams. 3. Analyse the trade-off between component flexibility and API simplicity. 4. Explain how accessibility should be incorporated into design-system foundations and component engineering. 5. Describe an appropriate framework-integration and testing strategy for a multi-product design system. Analytical / Application Questions1. A team has eight button variants and allows arbitrary colour overrides. Diagnose the likely system problems and propose a rationalization strategy. 2. A company wants to introduce dark mode by replacing colour values directly in every component. Evaluate this approach and recommend a token architecture. 3. Two product teams need different versions of a data table. Determine whether the differences should be handled through variants, composition, separate components, or product-specific implementation, and justify your decision. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best distinguishes a design system from a component library? A. A design system contains only visual guidelines, while a component library contains research. B. A design system combines reusable assets with principles, documentation, governance, and workflows. C. A component library is always framework-independent, while a design system is framework-specific. D. A design system is used only by designers, while a component library is used only by developers. Correct Answer: B. A design system combines reusable assets with principles, documentation, governance, and workflows. Question 2Why are semantic tokens such as color.action.primary generally preferable to names based only on raw colour values? A. They prevent all visual variation between products. B. They allow components to express purpose and support controlled theme changes. C. They eliminate the need for accessibility testing. D. They guarantee that every component will have the same implementation. Correct Answer: B. They allow components to express purpose and support controlled theme changes. Question 3Which option is most likely to represent a component state rather than a variant? A. Destructive B. Compact C. Secondary D. Loading Correct Answer: D. Loading Question 4A component has many properties that permit arbitrary combinations and overrides. What is the most likely strategic risk? A. The component will require less testing. B. The component will become easier to document. C. The component API will become complex and difficult to govern. D. The component will automatically become more accessible. Correct Answer: C. The component API will become complex and difficult to govern. Question 5Which practice best supports accessible dialog behaviour? A. Moving focus into the dialog and defining keyboard dismissal and focus restoration. B. Removing the focus indicator to improve visual simplicity. C. Using colour alone to identify the dialog's purpose. D. Allowing each product team to invent its own keyboard interaction. Correct Answer: A. Moving focus into the dialog and defining keyboard dismissal and focus restoration. Question 6A team wants to introduce dark mode without rewriting component logic. Which architecture is most appropriate? A. Hard-code a second set of colours inside every component. B. Use semantic tokens that map roles to different theme values. C. Allow users to override any component colour independently. D. Replace all semantic names with primitive colour names. Correct Answer: B. Use semantic tokens that map roles to different theme values. Question 7Which evidence would most strongly justify adding a new shared component variant? A. A designer prefers a different shade of the existing variant. B. One developer finds the existing API unfamiliar. C. Several products have a repeated, meaningful user need that cannot be met through composition. D. The variant would increase the total number of components. Correct Answer: C. Several products have a repeated, meaningful user need that cannot be met through composition. Question 8What is the primary purpose of an exception register in design-system governance? A. To hide product-specific implementations from reviewers. B. To record deviations, their owners, rationale, and possible review or remediation. C. To prevent all product teams from making local decisions. D. To replace accessibility and visual testing. Correct Answer: B. To record deviations, their owners, rationale, and possible review or remediation. Question 9Why is a passing visual regression test insufficient to establish component quality? A. Visual tests cannot detect any change in rendered output. B. Visual tests do not by themselves prove usability, accessibility, content quality, or correct interaction. C. Visual tests are useful only for backend systems. D. Visual tests eliminate the need for documentation. Correct Answer: B. Visual tests do not by themselves prove usability, accessibility, content quality, or correct interaction. Question 10In the LearnSphere case, why was gradual migration preferable to an immediate rewrite? A. The organization wanted to preserve all duplicated implementations permanently. B. The products had different frameworks and release schedules, making an incremental approach lower risk. C. The design-system group had decided not to use shared tokens. D. Gradual migration prevents teams from contributing to governance. Correct Answer: B. The products had different frameworks and release schedules, making an incremental approach lower risk.
|
