Designing Documentation as Product Infrastructure
EPIC.Compliance Design System & Knowledge Architecture
Overview
As the Compliance & Enforcement platform grew in scope and complexity, it became clear that shipping features was only part of the problem. The product depended on complex business rules, multiple legacy systems, and evolving policy requirements — making clear documentation and shared patterns essential for long-term sustainability.
I led the creation of a design system and documentation framework to ensure the product could be maintained, extended, and safely evolved by future teams.
Video walkthrough: Documentation & Design System
Video of a short walkthrough of how documentation, design system, and Storybook were structured to support long-term maintainability.
Problem
Business rules lived in conversations or tickets
UI patterns were scattered across multiple libraries and implementations
New contributors required significant ramp-up time to understand system logic
Design decisions risked being reinterpreted or duplicated incorrectly
Constraints & Context
The product combined patterns from multiple sources (MUI, BC Government Design System, custom components)
Business logic was complex and policy-driven, requiring precision
Developers needed a single, reliable reference for component behavior
Documentation had to support both design and implementation, not just visuals
What I Built
Pattern Inventory & Consolidation
I created an inventory of all existing UI patterns, documenting:
Component purpose and usage
Variations and states
Source (library, custom, or legacy)
Alignment with design and code
This inventory became the foundation for consolidating patterns into a coherent system rather than redesigning everything from scratch.
Design System & Developer Alignment
Working closely with the front-end developer, we:
Defined a shared set of components and behaviors
Aligned Figma components with implementation
Ensured design intent translated directly into code
The developer created a Storybook as the single source of truth for implemented components, while Figma served as the design reference.
Documented, configurable UI components aligned with production code via Storybook.
Business & design documentation structured in Confluence
Business & Design Documentation in Confluence
I organized end-to-end documentation in Confluence, covering:
System concepts (case files, inspections, complaints, review board)
Business rules and decision logic
Role-based behavior and permissions
Links to Figma designs, research artifacts, and Jira tickets
This ensured that anyone joining the project could understand why the system works the way it does — not just how.
Responsive & Layout Guidance
To support different devices and contexts, I documented:
Responsive behavior and breakpoints
Grid systems and layout rules
How components adapt across screen sizes
This reduced ambiguity and prevented ad-hoc responsive decisions.
Two-column layout behavior documented across breakpoints (768px → 1200px+), showing how panels expand, collapse, and reflow for Requirements and Enforcement views.
Outcome & Impact
Reduced onboarding time for new developers and designers
Improved consistency across the product
Lower risk of misinterpreting business rules or UI behavior
Created a foundation for scaling the system beyond the initial release
Result: Documentation shifted from an afterthought to part of the product’s core infrastructure.
What This Shows About Me
I design for longevity, not just delivery.
I focus on decisions that reduce future ambiguity, not just shipping features.
I treat UX as shared infrastructure.
Design systems, documentation, and patterns are tools teams rely on long after initial delivery.
I’m comfortable operating at the intersection of design, engineering, and policy.
Especially in regulated environments where clarity, precision, and trust matter more than novelty.
I build systems organizations can confidently evolve over time.