How can designers explore, compare, and apply system knowledge without losing its context?
The challenge
Design-system guidance lives in separate documentation environments with different terminology, platform assumptions, and levels of detail. UXD Systems brings that material into a consistent learning structure while keeping official references visible.
Key design decision
Use profiles for depth and comparison for a focused question across systems.
Implemented result
The implemented product combines structured system profiles, a comparison workspace, a component explorer, and a manipulable Token Lab. No learning improvement or task-time reduction is claimed.
Designed for Designers learning and comparing design-system conventions.
The constraint
A shared comparison model must not turn educational interpretation into an authoritative implementation specification. The product explicitly separates official guidance, explanation, analysis, and comparison.
This case study analyzes the current implementation. Rationale describes the design implications of observable choices; it does not claim undocumented interviews, historical alternatives, or measured improvements.
SYSTEM LANDSCAPE / ANALYTICAL MAP
Separate authorities. One learning layer.
Apple HIGOfficial guidanceMaterial 3Official guidanceFluent 2Official guidanceCarbonOfficial guidance
↓
UXD / SYSTEMS
Explore context · Align comparison · Practice concepts
The learning layer links back to primary sources. It does not replace their authority.
02 / INFORMATION ARCHITECTURE
A structure for different intentions.
CURRENT ROUTE ARCHITECTURE
Depth where needed. Reference within reach.
Search across the content · Bookmarks for return visits
Systems
Library → System profile
Compare
Systems → Lens → Dimensions
Learn
Curriculum → Tokens / Foundations
Components
References → Button Explorer
Playground
Token Lab → Live preview
Reference
Patterns · Glossary · Sources
Product areas from the repository. This is an orientation model, not a tested linear user journey.
03 / DESIGN REASONING
The choices behind the experience.
DESIGN DECISION / 01
Keep exploration and comparison distinct
Observed in the product
The library has filterable system profiles; the comparison workspace exposes selectable systems and four lenses.
Design response
Use profiles for depth and comparison for a focused question across systems.
Rationale
A profile preserves context. Aligned comparison dimensions make differences inspectable without requiring readers to remember separate pages.
Tradeoff
Switching modes adds navigation; profile links preserve a route back to primary references.
Actual comparison workspace. Shared row labels align the question while each system retains its context.
01
Choose the comparison
System selectors sit together so the comparison set stays explicit.
02
Change the lens
Overview, Foundations, Architecture, and Operations narrow the dimensions under review.
03
Return to context
Each column links to its profile; normalized analysis remains connected to sources.
DESIGN DECISION / 02
Turn abstract tokens into visible consequences
Observed in the product
Token Lab exposes hue, radius, spacing, density, and a dark preview. Changes update shared preview variables.
Design response
Keep controls next to one consistent interface preview and a live white-on-action contrast readout.
Rationale
Holding the content constant lets the visual effect of a variable become easier to isolate. Contrast feedback also exposes when a color choice fails a specific text pairing.
Tradeoff
This is an educational preview, not a guarantee that every component and color pair in an exported system is accessible.
Implementation reference: components/TokenLab.tsx
TOKEN MODEL / CONCEPTUAL EXPLANATION
One value. Several layers of meaning.
01Primitive
A raw color value
02Semantic
The purpose: primary action
03Component
The button’s background
04Interface
An action with visual emphasis
Conceptual token architecture, not literal names exported by UXD Systems. The actual lab maps hue to preview variables.
DESIGN DECISION / 03
Compare through a common frame, not a common identity
Observed in the product
The comparison table uses shared dimensions, named system columns, and links to each profile.
Design response
Normalize the questions while retaining system names, source scope, and contextual explanation.
Rationale
Aligned attributes support cross-system scanning; direct references prevent the comparison from replacing the original guidance.
Tradeoff
Normalization inevitably compresses nuance. The product labels the result as educational analysis.
Comparison is contextual, not a ranking. The product preserves tradeoffs and platform differences.
DESIGN DECISION / 04
Make component states part of the lesson
Observed in the product
A dedicated Button Explorer presents component variants and states.
Design response
Treat the button as a behavioral component rather than a static color specimen.
Rationale
Hierarchy, affordance, focus, and disabled behavior affect how an action can be understood and used. A state explorer makes those differences available for inspection.
Tradeoff
An isolated explorer cannot represent every interaction within a complete task.
The action stays recognizable as its state changes.
Default
Default state in the actual component explorer.
Focus
Focus state in the actual component explorer.
Disabled
Disabled state in the actual component explorer.
01 Label: names the action02 Plus icon: supports meaning03 Padding & radius: shared silhouette04 Focus: location feedback05 Disabled: unavailable action
The explorer forces visual states for study. It does not constitute a cross-system implementation specification.
04 / VISUAL & INTERACTION SYSTEM
From a variable to an interface.
The Token Lab ties a primitive hue to semantic surface and text values, then applies radius, spacing, and density variables to a stable preview. This makes the relationship between a system value and an interface visible. In comparison, column alignment and row headings carry the grouping; system accents identify columns without replacing their labels.
CAUSE → EFFECT / ACTUAL TOKEN LAB
Density changes the space around the same content.
Comfortable: the starting state of the actual lab.
Compact: density changes while the other control values remain unchanged.
Theme → Surface & text
Color → Action emphasis
Spacing → Component separation
Radius → Container shape
Density → Space within the layout
RESPONSIVE BEHAVIOR / ACTUAL CAPTURES
Preserve the controls. Change the reading order.
Desktop: related controls and output share the available width.
Mobile: actual 390px capture. Read the controls and their output in sequence.
A narrow layout trades simultaneous visibility for readable controls. The next usability check should examine whether people can connect changes with output after scrolling.
05 / INCLUSIVE INTERACTION
Behavior matters as much as appearance.
Source inspection confirms labeled range controls, pressed states on density controls, a native theme checkbox, and a live contrast readout in Token Lab. The comparison uses table headers and a labeled focusable overflow region. These are implementation observations, not a complete accessibility certification.
06 / OUTCOME & REFLECTION
What exists. What remains to learn.
The implemented product combines structured system profiles, a comparison workspace, a component explorer, and a manipulable Token Lab. No learning improvement or task-time reduction is claimed.
What works
A shared comparison structure retains links back to contextual profiles.
What remains limited
An educational model simplifies the original systems; understanding still needs practitioner evaluation.
What I would explore next
The central tension is between making systems comparable and retaining the context that gives each system meaning. The next review should test whether the navigation separates learning and reference clearly enough; feature completeness alone cannot answer that.
CONTRIBUTION & EVIDENCE
Scope, decisions, and the evidence behind them.
Role & collaboration
The role presented in this case study is UX Designer, with a focus on Visual Design, Design Systems, Interaction Design. Individual ownership boundaries and collaborator contributions are not documented in this implementation review.
User feedback & iteration
No participant-feedback record is included in this case study, so the design changes are not attributed to user testing. The next validation question is: Can designers explain a system difference and predict what a token change will affect?
Constraints & priorities
A shared comparison model must not turn educational interpretation into an authoritative implementation specification. The product explicitly separates official guidance, explanation, analysis, and comparison. A concrete tradeoff: Switching modes adds navigation; profile links preserve a route back to primary references. This describes a product tradeoff; no stakeholder disagreement is claimed.
Evidence of benefit
A shared comparison structure retains links back to contextual profiles. This is observable product behavior. Whether it helps the intended audience remains a question for validation: Observe successful comparison, mistaken interpretations, navigation detours, and whether explanations match the demonstrated token behavior.
Verified implementation scope
Design systems in the library
20
Profile dimensions
14
Token Lab controls
5
These counts describe the implemented product. They do not measure usability improvement, participant satisfaction, or business impact.
07 / PROPOSED RESEARCH · NOT CONDUCTED
The next questions to test.
Proposed tasks
Compare two systems, explain a meaningful difference, then predict and inspect a density change in Token Lab.
question
Can designers explain a system difference and predict what a token change will affect?
method
Proposed moderated task-based usability sessions with think-aloud and a short explanation task.
participants
Practicing and early-career designers who use design-system documentation. Recruitment has not begun.
signal
Observe successful comparison, mistaken interpretations, navigation detours, and whether explanations match the demonstrated token behavior.
TOOLS & WORKFLOW
Tools supporting the design.
Design & interaction
Figma
Sketch
Prototype implementation
Next.js
React
TypeScript
Evaluation
Playwright
axe-core
Versioning & publishing
Git
GitHub Pages
Project tools confirmed by source configuration. Figma, Sketch, and Adobe XD belong to my overall toolkit; their use on this specific project has not yet been documented.
