UI Architecture, Design Systems, and Reuse

Introduction

A modern frontend application is not merely a collection of screens. It is a software system whose user interface must remain understandable, consistent, accessible, testable, and adaptable as features and teams grow. UI architecture provides the structural principles for organising this system. A design system provides a shared language and implementation foundation. Reuse converts repeated knowledge and behaviour into stable components, patterns, and platform capabilities.

In React.js and Vue.js, these concerns are closely related but not identical. A component is an implementation unit; a design-system component is a governed, reusable interface capability; and UI architecture is the larger arrangement of components, state, routes, data flows, styles, services, and team ownership. Confusing these levels produces common failures: oversized components, duplicated styles, tightly coupled business logic, inaccessible widgets, and interfaces that are visually similar but behaviourally inconsistent.

At postgraduate level, UI architecture should therefore be approached as a socio-technical design problem. It involves software engineering, interaction design, accessibility, governance, product strategy, testing, and organisational collaboration.

Learning Objectives

By the end of this chapter, learners should be able to:

1. Distinguish UI architecture, component architecture, design systems, and reuse.
2. Analyse the trade-offs among different frontend architectural styles.
3. Design a scalable component and design-token hierarchy for React or Vue.
4. Apply principles of composition, state ownership, dependency inversion, and controlled reuse.
5. Evaluate accessibility, performance, testing, versioning, and governance implications.
6. Propose an architecture for a multi-team frontend product.
7. Critically assess emerging practices, including headless components and AI-assisted interface development.

1. Conceptual Foundations

1.1 UI architecture as a system of relationships

UI architecture describes how interface responsibilities are divided and connected. Its concern is not only where files are stored, but also:

• which layer owns state;
• which components may depend on which services;
• how data enters and leaves the interface;
• how visual decisions are represented as tokens;
• how accessibility behaviour is guaranteed;
• how features are tested, deployed, and evolved.

A useful abstraction is a dependency direction:

Figure: A layered model of frontend UI architecture. Dependencies generally flow from product composition toward lower-level reusable capabilities.

The diagram is a conceptual guide rather than a mandatory folder structure. Some systems use vertical slices, in which route, feature, test, and API code are colocated. The essential question is whether the dependency rules are explicit and enforceable.

1.2 Four levels of reuse

Reuse occurs at several levels:

Reuse should not be measured simply by the percentage of code shared. A highly generic component may reduce duplication while increasing cognitive complexity. The relevant objective is appropriate reuse: shared where semantics and behaviour are genuinely stable, specialised where domain meaning differs.

1.3 Component, module, and feature

A component renders an interface boundary and usually accepts inputs and emits events. In React, inputs are commonly props and callbacks; in Vue, they are props and emitted events. A module may include components, state, validation, data access, and tests. A feature is a user-recognisable capability, such as searching orders or editing a profile.

A component should have a clear contract. The contract includes:

• accepted data types and required properties;
• events or callbacks;
• visual states such as loading, disabled, invalid, and selected;
• keyboard and assistive-technology behaviour;
• layout assumptions;
• error handling expectations.

Contracts reduce accidental coupling. They also make refactoring safer because changes can be evaluated against a known boundary.

2. Architectural Styles and Trade-offs

2.1 Layered architecture

A layered approach separates presentation, feature logic, application services, and infrastructure. It is easy to explain and can support strong dependency rules. However, excessive layering may scatter a small feature across many directories and make changes slow.

2.2 Feature-oriented architecture

Feature-oriented architecture groups code by business capability rather than file type. A simplified structure might be:

src/
  app/                 # routing, providers, global configuration
  features/
    orders/
      components/
      state/
      api/
      validation/
      tests/
  design-system/
    primitives/
    patterns/
    tokens/
  shared/
    services/
    utilities/

This improves locality and team ownership. It requires discipline to prevent feature modules from importing one another’s private internals.

2.3 Atomic design and its limits

Atomic design commonly describes atoms, molecules, organisms, templates, and pages. It encourages a progression from small primitives to composed screens. Its strength is vocabulary and design-development alignment. Its limitation is that visual size does not always correspond to architectural responsibility. A small component may contain complex business rules, while a large layout may be a simple composition. Atomic categories should therefore support, not replace, dependency and ownership analysis.

2.4 Headless and styled components

A styled component combines behaviour, semantics, and visual presentation. A headless component supplies behaviour and accessibility while allowing the consumer to control markup or styling. Headless design is useful when a product needs multiple visual themes or layouts. It transfers more responsibility to consumers, however, and can produce inconsistent accessibility if the contract is unclear.

2.5 Micro-frontends

Micro-frontends divide a frontend into independently owned or deployed sections. They may be justified by organisational autonomy, separate release lifecycles, or very large product boundaries. They introduce costs in duplicated dependencies, cross-application navigation, design consistency, performance, and operational complexity. They are an organisational architecture as much as a technical one and should not be adopted merely because a codebase is large.

3. Design Systems

3.1 Definition and purpose

A design system is a governed collection of design principles, tokens, components, patterns, documentation, code, and contribution processes. A component library is only one part of a design system. A mature system aligns:

1. design intent;
2. coded implementation;
3. accessibility requirements;
4. content and interaction guidance;
5. release and governance processes.

The system creates a shared vocabulary between designers, engineers, researchers, product managers, and quality specialists.

3.2 Design tokens

Design tokens represent decisions in a platform-neutral form. Typical categories include colour, typography, spacing, border radius, elevation, motion, and focus indicators. Tokens should be semantic where possible. For example, color.text.primary communicates purpose more effectively than blue.700.

A token architecture may contain:

• global tokens, such as a raw colour scale;
• semantic tokens, such as surface, text, border, and action roles;
• component tokens, such as button height or dialog padding.

Semantic tokens support themes and contrast adjustments without requiring every component to know the underlying palette. They also reduce direct use of arbitrary values.

3.3 Components as behavioural contracts

A design-system component must specify more than appearance. A dialog should define focus movement, escape-key behaviour, background interaction, focus restoration, labelling, and dismissal rules. A text field should define label association, help text, validation messaging, required-state communication, and error announcement.

In React, a controlled component receives its value and change handler from its parent. In Vue, the equivalent commonly uses a model binding. Controlled state is valuable when a parent must coordinate validation or persistence; internally managed state is convenient when the state is local and consumers do not need to observe every transition. A component can support both, but the precedence rules must be explicit.

3.4 Documentation and discoverability

Documentation should include:

• purpose and appropriate use;
• anatomy and content rules;
• properties and events;
• state matrix;
• accessibility behaviour;
• responsive behaviour;
• examples and anti-examples;
• migration notes and version history.

A visually attractive component explorer is insufficient if it omits keyboard testing, semantic markup, or failure states.

4. Reuse and Composition in React and Vue

4.1 Prefer composition over inheritance

Frontend components generally benefit from composition: a component receives smaller capabilities and arranges them. Composition avoids deep inheritance hierarchies and allows a feature to replace one part without changing an entire class tree.

React provides composition through children, props, custom hooks, context, and component functions. Vue provides slots, composables, provide/inject, and component props and emits. These mechanisms are not interchangeable in design intent:

• props express explicit data or configuration;
• events/callbacks communicate user or lifecycle outcomes;
• slots/children allow structural composition;
• hooks/composables share stateful logic;
• context/provide-inject support cross-cutting or scoped dependencies.

Context and provide/inject should not become invisible global state. They are most maintainable when used for stable concerns such as theming, localisation, or a scoped form context.

4.2 Avoiding the “god component”

A god component renders many unrelated sections, fetches data, manages global state, performs validation, handles navigation, and contains device-specific logic. It is difficult to test and reuse. Refactoring should separate:

• data acquisition and mutation;
• domain transformation;
• orchestration of the screen;
• presentational components;
• reusable interaction logic.

The aim is not maximal fragmentation. Excessive decomposition creates prop chains, indirection, and difficult debugging. A useful boundary exists when a unit has a coherent responsibility, a meaningful contract, or an independent test and ownership need.

4.3 State ownership

State should be placed at the lowest level that needs it, then lifted when multiple consumers require coordination. A practical classification is:

• ephemeral UI state: menu open, input focus, tab selection;
• shared client state: authenticated user, preferences, shopping basket;
• server state: remotely fetched data, cache status, freshness, errors;
• URL state: search terms, filters, pagination, selected resource;
• form state: draft values, validation, submission status.

Treating server state as ordinary global client state often creates stale data, redundant fetching, and unclear invalidation. Conversely, placing every small UI flag in a global store increases coupling.

4.4 API design and extensibility

A reusable component API should be minimal, semantic, and predictable. Boolean properties should not multiply into contradictory combinations. Prefer an explicit variant model and sensible defaults. Avoid exposing internal DOM structure unless customisation truly requires it.

Extensibility mechanisms include slots, render props, compound components, CSS custom properties, and token overrides. Each adds power and cost. The correct choice depends on whether consumers need to change content, structure, style, or behaviour.

5. Accessibility as an Architectural Property

Accessibility cannot be reliably added at the screen level after components have been built. The design system should establish semantic HTML, keyboard support, focus visibility, accessible names, status communication, and adequate contrast as default behaviour.

Important practices include:

• use native controls when they provide the required semantics;
• associate labels and descriptions programmatically;
• preserve logical tab order;
• provide visible focus indicators;
• ensure dialogs manage focus correctly;
• expose validation errors in text and through appropriate accessibility relationships;
• support zoom, reflow, and reduced-motion preferences;
• test with keyboard navigation, screen readers, automated tools, and real users with disabilities.

ARIA should enhance semantics, not replace correct native elements. A custom clickable div is usually inferior to a button because the developer must recreate keyboard, focus, and role behaviour.

Accessibility also has governance implications. Acceptance criteria should include accessibility, component releases should document behavioural changes, and automated checks should run in continuous integration. Conformance is not guaranteed by a single automated score; accessibility is contextual and must be evaluated through multiple methods.

6. Testing, Quality, and Performance

6.1 Testing layers

A design system benefits from several complementary tests:

• unit tests for deterministic logic and state transitions;
• component tests for user-visible interaction and semantics;
• visual regression tests for unintended appearance changes;
• accessibility tests for detectable violations and keyboard paths;
• contract tests for component APIs and event behaviour;
• integration and end-to-end tests for realistic workflows.

Testing implementation details, such as private state variables or framework internals, makes refactoring expensive. Tests should generally express what a user or consuming module can observe.

6.2 Performance implications

Reuse can improve performance through shared optimisations, but abstraction itself is not free. Large component libraries may increase bundle size, style calculation, or runtime work. Performance analysis should consider:

• JavaScript and CSS transfer size;
• initial rendering and hydration cost;
• unnecessary re-rendering or reactive invalidation;
• list virtualisation requirements;
• image and font loading;
• code splitting by route or feature.

Memoisation should be applied based on profiling rather than habit. It can reduce repeated work but also increases complexity and may fail when inputs change identity frequently.

6.3 Quality attributes and trade-offs

Architecture can be evaluated using quality attributes:

No architecture maximises every attribute. A highly centralised system may improve consistency but reduce team autonomy. A highly flexible system may increase variation and documentation burden.

7. Governance and Evolution

7.1 Ownership and contribution

A design system requires clear ownership. A central team may maintain primitives and tooling, while product teams contribute patterns and report gaps. Contribution rules should identify:

• who approves API changes;
• how accessibility is reviewed;
• how breaking changes are communicated;
• how deprecations are managed;
• which quality gates block publication.

Governance should enable contribution rather than become a bottleneck. A lightweight decision record can document the problem, alternatives, decision, consequences, and review date.

7.2 Versioning and migration

Changing a component can affect visual appearance, keyboard behaviour, layout, and application logic. Semantic versioning is useful when its meaning is applied consistently, but visual breaking changes may be significant even when the programming API remains unchanged.

Effective migration practice includes deprecation warnings, codemods where possible, migration guides, compatibility periods, and an inventory of consumers. A design system should distinguish:

• additive changes;
• behavioural fixes;
• visual changes;
• API deprecations;
• breaking removals.

7.3 Metrics

Useful indicators include adoption of approved components, accessibility defects, duplicate implementations, time to deliver a common workflow, bundle impact, and consumer satisfaction. Metrics must be interpreted carefully. High adoption may indicate success or forced compliance; low duplication may indicate reuse or underinvestment in features. Qualitative feedback and usability evidence remain essential.

8. Applied Case: Illustrative Multi-Team Commerce Platform

Background

Consider a fictional commerce organisation with three product teams building a customer portal, an operations console, and a partner dashboard. All use React, but each has independently implemented buttons, tables, notifications, and form validation.

Problem

Users encounter different keyboard behaviour, colour semantics, error messages, and responsive layouts. Engineers duplicate fixes. A new brand theme requires changes in many repositories. The organisation initially proposes a single repository containing every screen, but teams fear loss of autonomy.

Analysis

The underlying problem is not only duplication. There is no shared contract for interaction behaviour, no semantic token layer, and no ownership model. A monolithic application would not automatically solve these issues. The organisation identifies stable cross-product foundations—tokens, accessibility primitives, form-field behaviour, notifications, and layout utilities—while keeping domain workflows within product teams.

Approach

The proposed architecture has three parts:

1. Foundation package: semantic tokens, typography, icons, focus styles, and low-level accessible primitives.
2. Pattern package: tables, filter bars, pagination, empty states, and form compositions, each with documented usage and accessibility tests.
3. Feature ownership: product teams own domain-specific screens and may contribute patterns after review.

The package uses a component explorer as a documentation and testing surface. Each component has a state matrix covering default, hover, focus, disabled, loading, invalid, and responsive states. Automated checks run alongside keyboard and screen-reader review. Teams receive codemods for replacing legacy buttons and fields.

Outcome

The teams retain independent product delivery while sharing stable interaction contracts. The first release does not attempt to standardise every visual detail. Instead, it prioritises high-frequency, high-risk components. Migration is staged: new work adopts the system first, then heavily used legacy flows are migrated. Success is assessed through defect reduction, migration effort, accessibility findings, and developer feedback rather than adoption alone.

Learning points

1. Reuse should target stable semantics and behaviour, not every repeated fragment.
2. Design-system governance is an organisational capability.
3. Accessibility and testing belong in component architecture.
4. A shared foundation can coexist with feature-team autonomy.
5. Migration strategy is as important as component design.

9. Ethical, Legal, and Professional Considerations

Interface architecture affects people’s access to services, privacy, and ability to make informed decisions. Teams should avoid dark patterns such as disguised advertising, obstructive cancellation flows, misleading defaults, and ambiguous consent controls. Reusable components can amplify harm if a defective pattern is deployed everywhere; central governance therefore creates responsibility as well as efficiency.

Privacy should influence state and analytics design. Sensitive data should not be placed unnecessarily in URLs, client logs, or persistent browser storage. Consent and preference components should communicate purpose clearly. International products also require localisation, right-to-left layout considerations, date and number formatting, and culturally appropriate content.

AI-assisted code generation can accelerate scaffolding and component conversion, but generated code requires review for licensing, security, accessibility, data leakage, and framework correctness. AI should not be treated as an authority on design-system policy or inclusive interaction. Human ownership remains necessary for architectural decisions.

10. Contemporary Directions

Several developments are shaping UI architecture:

• Design-to-code pipelines increasingly transform token and component metadata into implementation artifacts, but human review remains necessary for semantics and interaction.
• Web components can support framework-neutral distribution, although integration, styling, forms, and accessibility details require careful evaluation.
• Server rendering and resumability shift performance decisions but do not eliminate the need for clear component boundaries.
• Multi-brand systems use semantic tokens and theme layers to share behaviour while permitting visual differentiation.
• Accessible-by-default primitives are becoming a baseline expectation rather than a specialist enhancement.
• Platform engineering for frontend teams provides standard build, testing, observability, and release capabilities, allowing product teams to focus on domain work.

These developments should be assessed against product context, team capability, user needs, and total cost of ownership rather than adopted as fashion.

Best-Practice Checklist

Before approving a reusable component or architectural boundary, ask:

1. Is the purpose and semantic responsibility clear?
2. Is the API smaller than the set of internal implementation details?
3. Are keyboard, focus, screen-reader, responsive, loading, and error states defined?
4. Can consumers compose the component without unsafe escape hatches?
5. Is state owned at the appropriate level?
6. Are tokens semantic and themeable?
7. Are tests based on observable behaviour?
8. Is documentation available with examples and anti-examples?
9. Is ownership and versioning explicit?
10. Does reuse reduce total complexity rather than merely reduce line count?

Chapter Summary

UI architecture organises the relationships among screens, features, components, state, services, styles, and teams. A design system extends beyond a component library by combining tokens, accessible components, patterns, documentation, governance, and contribution processes. Effective reuse is selective: it standardises stable semantics and behaviour while allowing domain-specific variation.

React and Vue support composition through props, events, children or slots, hooks or composables, and scoped dependency mechanisms. Sound architecture places state deliberately, avoids god components, maintains dependency direction, and evaluates trade-offs among consistency, flexibility, autonomy, performance, and maintainability. Accessibility must be designed into primitives and verified through multiple testing methods. Finally, design systems are socio-technical products: their success depends on ownership, migration, documentation, ethical practice, and continuous evidence from users and teams.

Key Terms

UI architecture: The structural organisation of interface code, state, data, styles, dependencies, and ownership.

Design system: Governed design guidance, tokens, components, patterns, documentation, and processes.

Design token: A named representation of a reusable design decision.

Semantic token: A token named by purpose, such as primary text or action background.

Component: A reusable interface unit with a defined input, output, and behavioural contract.

Primitive: A low-level reusable visual or interaction component.

Pattern: A reusable solution to a recurring interface or workflow problem.

Feature module: A domain-oriented unit containing interface and supporting logic.

Composition: Building larger behaviour by combining smaller units.

Headless component: A component that provides behaviour and semantics without prescribing complete visual presentation.

Controlled component: A component whose relevant state is owned by its consumer.

Server state: Data originating from and synchronised with a remote system.

Ephemeral state: Short-lived local interface state.

Design-system governance: Policies and processes for contribution, quality, ownership, and change.

Visual regression testing: Automated comparison used to detect unintended visual changes.

Accessibility: Designing technology so people with diverse abilities can use it effectively.

Micro-frontend: An architectural approach dividing a frontend into independently owned or deployed sections.

Semantic HTML: HTML elements selected for their meaning and built-in behaviour.

Dependency direction: The rule governing which architectural layers or modules may depend on others.

Codemod: An automated source transformation used to assist large-scale code migration.

Review Questions

Short Answer Questions

1. What is the difference between a component library and a design system?
2. Why are semantic design tokens preferable to raw colour names in multi-theme products?
3. Distinguish ephemeral UI state from server state.
4. What is a headless component, and when might it be useful?
5. Why should accessibility be addressed at the design-system level?

Long Answer Questions

1. Compare layered, feature-oriented, and atomic-design approaches to frontend organisation.
2. Explain how composition mechanisms in React and Vue support reuse while introducing different forms of coupling.
3. Discuss the quality-attribute trade-offs between a centralised design system and independent product-team implementations.
4. Design a governance and versioning process for a design system used by several autonomous teams.
5. Explain why testing implementation details can undermine the maintainability of a reusable component library.

Analytical / Application Questions

1. A reusable table component has accumulated thirty properties, several boolean combinations, and feature-specific callbacks. Diagnose the architectural problem and propose a refactoring strategy.
2. A company wants to adopt micro-frontends because its frontend repository contains 500,000 lines of code. Evaluate whether repository size alone justifies the decision, and identify the evidence required.
3. Design a migration plan for replacing three inconsistent form-field implementations with one accessible design-system component while allowing continuous product delivery.

Multiple Choice Questions with Answers

Question 1

Which statement best defines a design system?

A. A collection of CSS files containing brand colours

B. A governed combination of principles, tokens, components, patterns, documentation, and processes

C. A routing library for frontend applications

D. A set of database schemas for interface data

Correct Answer: B. A governed combination of principles, tokens, components, patterns, documentation, and processes

Question 2

What is the main advantage of a semantic token such as color.text.primary?

A. It permanently exposes the raw palette value

B. It makes every component independent of accessibility requirements

C. It expresses purpose and supports themes or palette changes

D. It eliminates the need for component documentation

Correct Answer: C. It expresses purpose and supports themes or palette changes

Question 3

Which state is most appropriately treated as ephemeral UI state?

A. A cached list of server orders

B. The authenticated user identity

C. A menu’s currently open or closed status

D. A persisted billing preference

Correct Answer: C. A menu’s currently open or closed status

Question 4

What is a defining characteristic of a headless component?

A. It cannot receive properties

B. It provides behaviour and semantics while allowing consumer-controlled presentation

C. It is always rendered on the server

D. It contains no accessibility behaviour

Correct Answer: B. It provides behaviour and semantics while allowing consumer-controlled presentation

Question 5

Which practice best supports accessible dialog architecture?

A. Move focus into the dialog and restore it after dismissal

B. Use a clickable div instead of a button for flexibility

C. Hide the dialog title from all assistive technologies

D. Allow keyboard focus to move unpredictably behind the dialog

Correct Answer: A. Move focus into the dialog and restore it after dismissal

Question 6

Why can excessive component decomposition be harmful?

A. It always prevents automated testing

B. It can create indirection, prop chains, and difficult debugging

C. It makes semantic HTML impossible

D. It guarantees larger bundles in every framework

Correct Answer: B. It can create indirection, prop chains, and difficult debugging

Question 7

Which architecture groups code primarily by business capability?

A. Feature-oriented architecture

B. File-extension architecture

C. Colour-oriented architecture

D. Database-normalised architecture

Correct Answer: A. Feature-oriented architecture

Question 8

What is the principal purpose of visual regression testing?

A. To measure API response latency

B. To detect unintended changes in rendered appearance

C. To replace all accessibility testing

D. To validate database transactions

Correct Answer: B. To detect unintended changes in rendered appearance

Question 9

Why should server state not automatically be placed in ordinary global client state?

A. Server state never changes

B. It can create stale data, redundant fetching, and unclear invalidation

C. Global state cannot store strings

D. It prevents any component from rendering

Correct Answer: B. It can create stale data, redundant fetching, and unclear invalidation

Question 10

In the case study, why was migration staged rather than requiring an immediate rewrite?

A. The teams had no shared framework

B. Staged migration preserved continuous delivery and prioritised high-value components

C. The design system had no documentation

D. Accessibility was intentionally postponed

Correct Answer: B. Staged migration preserved continuous delivery and prioritised high-value components