How can designers explore, compare, and apply system knowledge without losing its context?
The challenge
Design-system guidance is spread across websites, each with its own terminology and platform assumptions. UXD Systems brings it into one learning workspace while keeping links to the original guidance.
Key design decision
Use profiles for depth and comparison for a focused question across systems.
Current result
The working product brings system profiles, comparisons, component states, and Token Lab into one learning workspace. Its effect on learning still needs to be tested with designers.
Designed for Designers learning and comparing design-system conventions.
The constraint
A comparison can simplify differences too far. The workspace distinguishes official guidance from its own explanations and links back to the source.
The design review focuses on the working product. Participant research and usability evaluation are planned next.
SYSTEM LANDSCAPE / ANALYTICAL MAP
Bring guidance together without losing context.
Apple HIGOfficial guidanceMaterial 3Official guidanceFluent 2Official guidanceCarbonOfficial guidance
↓
UXD / SYSTEMS
Explore systems · Compare decisions · Try concepts
The learning layer links back to primary sources. It does not replace their authority.
02 / INFORMATION ARCHITECTURE
Organize around the task.
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
The main product areas support different tasks; people can move between them as their needs change.
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
Profiles explain each system in context. Aligned comparison rows let designers compare differences without remembering information from separate pages.
Tradeoff
Switching modes adds navigation; profile links preserve a route back to primary references.
Shared row headings help compare the same question across design systems.
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 so designers can return to the original context.
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.
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
Use the same comparison questions while preserving each system’s name, context, and links to its guidance.
Rationale
Shared headings help designers scan across systems. Direct links keep the original guidance within reach.
Tradeoff
A shared table cannot capture every detail. Links to the original guidance keep the comparison in context.
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.
BUTTON ANATOMY / ACTUAL EXPLORER STATES
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 lets designers inspect each state. Those examples still need to be tested within a complete user task.
04 / VISUAL & INTERACTION SYSTEM
From a variable to an interface.
Token Lab lets designers change color, corner radius, spacing, and density while watching the same interface respond. In the comparison view, aligned columns and headings make differences easier to scan; color reinforces each system’s name.
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.
Token Lab uses labeled controls, clear selected states, and live contrast feedback. Table headings and a keyboard-focusable scrolling area support the comparison view. Screen-reader and task-based testing are still needed.
06 / OUTCOME & REFLECTION
What exists. What remains to learn.
The working product brings system profiles, comparisons, component states, and Token Lab into one learning workspace. Its effect on learning still needs to be tested with designers.
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.
Next questions
Comparing systems requires simplifying them without losing important context. The next study should test whether designers can move between quick comparisons and deeper guidance without getting lost.
CONTRIBUTION & EVIDENCE
My contribution and the next questions.
My contribution
Product direction, the learning structure, system comparisons, and the interactive Token Lab experience.
Collaboration
The project involved designers, developers, and design-system reviewers.
Next user study
Participant testing is planned. The central question is: Can designers explain a system difference and predict what a token change will affect?
Constraints & priorities
Switching modes adds navigation; profile links preserve a route back to primary references.
What the design supports
A shared comparison structure retains links back to contextual profiles. The next evaluation will look for: Observe successful comparison, mistaken interpretations, navigation detours, and whether explanations match the demonstrated token behavior.
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.
Research 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.
What to observe
Observe successful comparison, mistaken interpretations, navigation detours, and whether explanations match the demonstrated token behavior.
