Intent before appearance
Tokens and components are named according to their purpose, not their visual value.
Self-Initiated Design System Case Study
Building a scalable system for complex product workflows
A code-backed exploration of how semantic tokens, accessible components, responsive density, and practical documentation can create a dependable foundation for enterprise products.
Workspace health✓ Ready
24
illustrative active workflowsReview queue! 3 pending
02 / SEMANTIC LAYER
One role. Many contexts.
action.primary✓ Defined03 / INTENTIONAL OPTIONS
A focused starting point
System at a glance
2interface themes
2density modes
8core components
6interaction states
A separate public exploration, built for this portfolio. No client delivery, company adoption, or production release is implied. All workflow data is illustrative.
01 / The opportunity
Why create another design system?
Complex products often accumulate one-off interface decisions. Colors become disconnected from meaning, similar components behave differently, and accessibility is addressed only after inconsistencies have already spread.
I created this self-initiated system to explore a more dependable approach: begin with semantic foundations, limit flexibility through a clear component API, and treat documentation and accessibility as part of the component itself.
02 / The operating principles
Design principles
Accessible by default
Contrast, focus, keyboard behaviour, and non-color feedback begin at the foundation level.
Flexible within boundaries
Components support meaningful variation without creating uncontrolled combinations.
Documentation is part of the component
Usage, behaviour, content, accessibility, and handoff guidance are designed together.
03 / Foundations
Foundations that carry intent
The system begins with a focused set of primitives for color, typography, spacing, radius, and elevation. Semantic tokens then translate those values into reusable interface decisions. This separation allows the visual language to evolve without changing the purpose of every component.
Violet / 600
#5B4BDB · Action
Teal / 700
#0F766E · Accent
Ink / 950
#0B1220 · Text
Green / 700
#15803D · Success
Amber / 700
#B45309 · Warning
Red / 700
#C2413B · Critical
Neutrals provide the supporting structure: Canvas #F6F7FB, Surface #FFFFFF, Border #D8DEE9, and secondary text #526071. Dark surfaces use #111827 and #1D2939. Dark-theme accents use lighter companions to preserve contrast.
04 / Color architecture
Semantic color without guesswork
A primitive stores a value. A semantic token expresses intent. A component token applies that intent to a specific part of the interface.
Primitive token ↓
violet.600Semantic token ↓
action.primaryComponent token
button.primary.background| Primitive | Semantic | Component |
|---|---|---|
| white | surface.default | card.background |
| neutral.600 | text.secondary | label.color |
| neutral.600 | border.control | input.border |
| green.700 | status.success | badge.success.text |
| amber.700 | status.warning | alert.warning.text |
| red.700 | status.critical | input.error.text |
| violet.600 | focus.ring | control.focus |
In CSS: --ds-violet-600 → --ds-action-primary → --ds-button-primary-background. Decorative borders use a softer role; input boundaries use a stronger one.
05 / Rhythm and proportion
Typography, spacing, radius, and elevation
Expressive headings meet quiet interface text. A four-pixel spacing base keeps the system consistent from a field label to a full workflow.
Type with a purpose
AaDisplay
Manrope 64/68
Manrope 64/68
Heading 1Manrope
48/56
48/56
Heading 2Manrope
36/44
36/44
Heading 3Manrope
24/32
24/32
Body LargeInter 18/30
BodyInter 16/26
Interface LabelInter 14/20
Semibold
Semibold
CaptionInter 12/18
Space as structure
4px
8px
12px
16px
24px
32px
48px
64px
Radius
8px12px16px24px
Elevation
BaseRaisedOverlay
Shadows indicate depth in light mode; lifted surfaces reinforce it in dark mode. Specimen sizes are reference values; page headings adapt to the viewport.
06 / Adaptive environments
Two themes, one visual hierarchy
Theme switching should change the environment without changing the importance of information. Both themes therefore use the same semantic roles, component structure, and hierarchy while adapting surfaces, borders, text, and elevation.
Light / same semantic roles
Release checklist
✓ ReadyAll required checks are complete.
Review ownerDesign operations
Review workflowDark / same semantic roles
Release checklist
✓ ReadyAll required checks are complete.
Review ownerDesign operations
Review workflow07 / Controlled flexibility
Density that respects the task
Enterprise products must support both focused tasks and information-heavy workflows. Instead of redesigning components for every screen, the system offers two controlled density modes that preserve hierarchy and interaction quality.
Request / Workspace access✓ Reviewed
Request / Rule update! Pending
Applies to the component gallery and workflows belowTry the components
Compact mode changes spacing and height only. Labels retain their size; interactive controls retain a minimum 44px height.
08 / Component architecture
Components with clear boundaries
Eight reusable building blocks. Each resolves the same token roles and exposes only the choices a workflow needs. These are live HTML controls; try them with a keyboard.
01 / Buttons
API: emphasis = primary | secondary; disabled = true | false. Use one primary action per decision.
02 / Text input
Anatomy: persistent label → editable value → supporting guidance. Choose a name your team can recognise.
03 / Select field
Use a native select for a short, mutually exclusive choice. Platform keyboard behaviour is preserved.
04 / Checkbox
The entire label is clickable. Use a checkbox for an independent on/off preference.
05 / Status badge
✓ Ready! Needs review
Meaning combines an icon, a written label, and a semantic color. Badges are informational, not controls.
06 / Alert
! Review required
Confirm the rule scope before enabling it.
Confirm the rule scope before enabling it.
Lead with the condition, then explain the next step. Reserve live announcements for dynamically changed messages.
07 / Content card
Review workspace
A shared place to inspect pending changes.
Open examplesAnatomy: heading → context → explicit action. The card itself does not compete with its link for focus.
08 / Data row
Access policy
Owner: Operations
✓ ActiveOwner: Operations
A stable identity and a scannable state. Supporting text remains visible in both density modes.
09 / Behaviour
States belong to the system
The same state rules travel with each component. The labelled hover, focus, and active specimens hold a state for comparison; real controls also respond to pointer and keyboard input.
DefaultClear action and stable boundary.
Hover · previewInset shading and an underlined label.
Focus-visible · previewAn offset ring; no movement or resizing.
Active · previewInset depth communicates a press.
DisabledDisabled in HTML; unavailable until review.
Error! Enter a rule name to continue.
10 / Accessible foundations
Accessibility as a starting condition
Accessibility is more reliable when it is encoded into foundations and components instead of being left to individual screens. The system therefore establishes accessible defaults that remain present wherever the components are reused.
- WCAG 2.2 AA contrast targets
- Visible keyboard focus
- Logical tab order
- Non-color status indicators
- Descriptive labels and error messages
- Minimum 44px control height as an internal usability standard
- Responsive reflow
- Reduced-motion support
Contrast is evaluated per foreground/background pair, including action labels, supporting text, status text, and focus rings in each theme. These checks are component-level evidence, not a claim of a complete accessibility audit.
11 / From parts to product
Stress-testing the system through real workflows
A component library becomes credible only when its parts work together. I tested the system through three generic enterprise scenarios to identify gaps in hierarchy, density, states, and responsive behaviour.
Interactive, illustrative scenarios only. Actions update this page; no request is submitted to a service.
Operations overview
DEMO WORKSPACEOpen requests
12
! Review queueActive rules
24
✓ EnabledOwners assigned
8
✓ Covered! Three requests need a decision. Review their scope before making changes.
Workspace access! Pending
Weekly report✓ Ready
Rule revision! Review
Configure a review rule
LOCAL DEMONSTRATIONReview configuration change
! Awaiting decisionExtend the review window from two to three working days for routine workspace access requests.
! Check the exception.
Urgent requests keep their existing review window.
Urgent requests keep their existing review window.
Requested byOperations team
ScopeRoutine access
Supporting informationUrgent path unchanged
12 / Documentation and handoff
Documentation designed for adoption
A scalable component needs more than visual specifications. It also needs clear guidance about purpose, anatomy, properties, behaviour, content, accessibility, and implementation.
Purpose and usage
Use a primary button to commit a decision. Use a secondary action for a reversible alternative. Avoid competing primary actions in one group.
Anatomy
A field pairs a persistent label, control, and help or error text. Link the message with aria-describedby so the relationship survives visual changes.
Variants and properties
Button: primary or secondary. Field: default or invalid. Theme and density are inherited; individual components do not introduce local palettes.
Interaction behaviour
Enter submits a form. Space toggles a checkbox. Arrow keys navigate workflow tabs; Home and End reach the first and last tabs.
Accessibility requirements
Keep labels visible, preserve native semantics, describe errors in text, and retain a visible focus ring. Recheck contrast when changing token values.
Design-to-development handoff
Map semantic roles to CSS aliases, document the supported properties, and review the component in a workflow at both densities and themes.
| Token name | Semantic role | Example usage |
|---|---|---|
--ds-action-primary | Main action emphasis | Primary button background |
--ds-surface-default | Content surface | Card and input background |
--ds-focus-ring | Keyboard location | Control outline |
--ds-status-critical | Actionable error | Invalid field and error message |
--ds-space-6 | Related content spacing | Comfortable component gap |
13 / Proposed measurement framework
What I would measure after adoption
These are future evaluation criteria, not completed results. Establish a baseline with a pilot team, then review the patterns alongside qualitative feedback.
Component adoption rate
Share of eligible interface elements using a supported component.
Detached or overridden instances
Where teams bypass defaults, and which unmet needs explain it.
Accessibility defects
Issues by severity, component, and recurrence across workflows.
Repeated handoff questions
Recurring ambiguity that should become documentation or a clearer API.
Time required to assemble standard workflows
Comparable tasks measured before and after a controlled pilot.
Contribution and review turnaround
Time from a documented proposal to a reviewed decision.
14 / Reflection
What this exploration taught me
This project reinforced that a design system is not primarily a collection of polished components. Its value comes from the decisions it removes, the behaviours it standardises, and the confidence it gives teams when creating new workflows.
The strongest systems do not offer unlimited flexibility. They provide intentional options, accessible defaults, understandable documentation, and a clear path for responsible change.
Next steps
- Validate the system with product designers and engineers
- Expand components only when real workflow needs emerge
- Connect design tokens to a shared development pipeline
- Establish contribution and deprecation processes
- Measure adoption, accessibility, and delivery efficiency
Intentional foundations. Dependable products.