Set up accessibility guidelines in phase one
If we had followed WCAG guidelines from day one, we wouldn’t have had to fix things like focus states and color contrast later.
SafeInsights, Rice University
Building a Scalable Design System for SafeInsights
Status: Live
Overview
Building a scalable design system from scratch to accelerate product development
Starting from zero, I created a system that enabled faster development, consistent UX, and scalable growth.
When I joined SafeInsights, there was no brand, no component library, and no shared visual language. While engineering had adopted Mantine, the existing Figma resources were too generic and vast for early-stage product development.
I led the creation of the design system from the ground up — defining tokens, building atomic components, and structuring scalable patterns that could support dashboards, admin tools, and complex data workflows. This is the story of how that system came to life and how it held up over 12 months of real product development.
50%
Faster screen creation after system maturity.
12 mo
Of continuous product iteration and expansion.
1:1
alignment with engineering, reducing design–dev friction.
Problem
Before / After — 01 · No atomic structure
Before / After — 02 · Hard-coded styles
Before / After — 03 · Too many variants, not enough clarity
How shortcuts without a system created a debt we had to repay.
Developers chose Mantine — but the Figma library was enormous, generic, and not ours. Here is how that shaped everything.
The starting point
A massive library. No visual language of our own.
Developers chose Mantine as the engineering UI library. But the Mantine Figma community file was enormous — thousands of variants, visually generic, and built for every possible product, not ours. SafeInsights had no visual language of its own: no colour palette, no spacing system, no typography scale. Nothing to inherit.
We needed to move fast to test the MVP. So we started borrowing — grabbing components from the Mantine Figma library and modifying them to fit SafeInsights' needs. It worked in the short term. But we were building on someone else's foundation without understanding what was underneath it.
What went wrong
No atoms meant no resilience. Changes broke things.
Because we never built our own elements from the ground up — from atoms to molecules — nothing was truly connected. Styles became hard-coded at the component level, and global changes required manual fixes across dozens of components.
Simple updates exposed the cracks:
- A longer status label pushed adjacent columns out of alignment.
- A brand color change required hunting through multiple components.
- Layouts broke because nothing shared a consistent structure.
Every shortcut compounded into design debt.
The conclusion
We needed our own system, built for our product, not borrowed from a generic library.
SafeInsights required a design system grounded in our product needs and visual direction, while still aligning with Mantine for engineering consistency. The examples below show how this shift resolved the issues and enabled scalable, consistent design.
Before
Components built in isolation
Mantine pieces were grabbed and modified independently. With no shared atoms underneath, a change to one component had no way to cascade — everything had to be fixed manually.
After
Atom → molecule → organism hierarchy
Every component is built from smaller reusable atoms. Updates cascade automatically through the hierarchy — one change propagates everywhere it's used.
Before / After — 02 · Hard-coded styles
Before
Values hard-coded per component
Colours, spacing, and type were set manually on each component. No shared source of truth meant a single brand change required touching every file individually.
After
All styles driven by shared tokens
One token change updates the entire system instantly. Colour, spacing, and typography stay consistent across every component without manual fixes.
Before / After — 03 · Too many variants, not enough clarity
Before
Mantine's full component library
The community file included every possible state and variant. Designers couldn't navigate it efficiently, and developers were unsure which variants were actually in scope for SafeInsights.
After
Only what SafeInsights needed
Variants were stripped to exactly what the product required. Fewer options meant less confusion in design, faster decisions in handoff, and cleaner implementation.
Goals
What we set out to build.
Clear guardrails set before a single component was drawn.
From the start, this wasn’t about building components — it was about defining a system that could scale with the product. The system needed to balance three constraints: move fast for MVP, align with Mantine for engineering, and establish SafeInsights’ own visual and structural language.
01
Scalable component library
Build a system that could grow beyond MVP and support long-term product evolution.
02
Align with Mantine
Mirror Mantine’s component structure visually and structurally to accelerate development handoffs.
03
Nested component architecture
Create composable structures so updates propagate across the system automatically, without manual fixes.
04
Reduce design–dev inconsistencies
Establish a shared visual and structural language to eliminate handoff ambiguity.
05
Accelerate MVP production
Enable fast screen creation without sacrificing long-term flexibility or creating design debt.
06
Establish visual foundation
Lay the groundwork for SafeInsights' long-term brand identity and future accessibility expansion.
My Role
What I owned end to end.
Build-from-scratch responsibility touching design, engineering, and documentation simultaneously.
As the designer responsible for the system, I led every layer — from architecture decisions to the smallest naming convention. This wasn't a maintenance role. It was a build-from-scratch responsibility that touched design, engineering, and documentation simultaneously over 12 months of real product development.
Design & Architecture
- System architecture planning
- Token creation — spacing, color, typography
- Rebuilding Mantine components from scratch
- Nested component structures
- Atomic design classification
- Visual system definition
Collaboration & Ops
- Design–dev alignment and handoff
- Naming conventions
- Component documentation
- QA and refinement across releases
- Maintaining and expanding over months
Process
Early exploration — moodboard & visual direction
Colour primitives and tokens.
Typography primitives alongside spacing and radius tokens.
Atomic breakdown of the Table component — Cell → Row → Table container, with colour tokens.
Button matrix — 5 sizes × 5 variants × 6 icon instance, all from a single nested base component.
Text input — label text → description text → error state, icons, all nested inside a single base.
Model — covering different sizes, states, and modes and documenting it for use..
Alert component and documentation
Five phases. Twelve months. One system that kept up with the product.
Building a design system for a product that didn't exist yet meant the process had to be as adaptive as the system itself.
Phase 01 — Exploration & Visual Foundation
Defining the visual foundation before building the system.
Before defining tokens or components, I needed to establish what the system should feel like. This meant balancing two parallel tracks: understanding Mantine's structural constraints and exploring SafeInsights' visual direction. I analyzed existing patterns, mapped MVP needs, and explored color, typography, and layout directions to define a foundation that was both expressive and system-ready.
Outputs: Moodboard & visual direction · Early system blueprint
Early exploration — moodboard & visual direction
Phase 02 — Foundation Building
Tokens first. Everything else follows.
Before touching a single component, I established the foundation that every future decision would rest on. Typography scale, spacing system built on 4px increments, color palette with semantic tokens, interaction states, and grid rules — all defined and shared with engineering before component work began. This alignment upfront prevented the most expensive kind of rework: foundational rework.
Outputs: Core design tokens · Foundation specs · Visual direction for component styling
- Defined typography scale — Open Sans across heading, body, and label styles.
- Built spacing system on 4px base unit — xxs through xxl.
- Created color palette with primitive and semantic token layers.
- Defined interaction states — hover, focus, disabled, error.
- Established grid and layout rules aligned to Mantine.
- Shared all foundation specs with engineering before component work.
Colour primitives and tokens.
Typography primitives alongside spacing and radius tokens.
Phase 03 — Component Classification
Giving the system a backbone through atomic structure.
With the foundation set, I organized the component library using atomic design principles — not as a rigid rule, but as a practical framework for prioritization and hierarchy. This structure made it clear what to build first, and created a maintainable hierarchy as the library grew.
Outputs: Component roadmap · Prioritized build order · Atomic structure documentation
- Atoms — smallest reusable units (text, icons, spacing, tokens)
- Molecules — combinations of atoms forming functional UI (inputs, buttons, badges)
- Organisms — complex, reusable components (tables, forms, cards)
- Templates — layout-level structures defining page composition.
Atomic breakdown of the Table component — Cell → Row → Table container, with colour tokens.
Phase 04 — Building the Library
Rebuilt from scratch. Nested by design.
Instead of adapting Mantine’s community file, I rebuilt every component from scratch — aligning with Mantine’s structural logic while defining our own visual system.The most important decision wasn’t what components to build, but how to structure them. By designing components as nested, composable systems, we enabled flexibility without duplication — allowing the system to scale as the product evolved.
Outputs: Full component library · Nested component structures · Component documentation
- Rebuilt every component from scratch — not adapted from the community file.
- Matched Mantine base dimensions and prop structure exactly.
- Removed visual complexity irrelevant to SafeInsights' early stage.
- Documented every component with anatomy, usage, and do's and don'ts.
- Mapped all components to compatible Mantine counterparts.
Nested component structures — the core of scalability
Button
Base
→
Variant
→
Size
→
Icon
→
State
Text Input
Base
→
Variant
→
Size
→
Icons
→
State
Button matrix — 5 sizes × 5 variants × 6 icon instance, all from a single nested base component.
Text input — label text → description text → error state, icons, all nested inside a single base.
Phase 05 — Implementation & Iteration
The system didn't freeze at launch. It grew with the product.
As new features shipped, the system kept pace. Spacing was refined. Missing variants were added. New patterns emerged from real product needs and fed back into the library. This iterative cycle — design, ship, learn, refine — is what separated a component library from a living design system.
Outputs: Refined spacing and responsive behavior · New variants and patterns · Strengthened design–engineering alignment
- Continuously refined padding, spacing, and responsive behavior
- Added missing variants as new product flows were designed
- Aligned with new development patterns as they emerged
- Fixed inconsistencies discovered during handoff and QA
- Scaled the system to support new proposal, admin, and results flows
Model — covering different sizes, states, and modes and documenting it for use..
Alert component and documentation
Impact
The system in action
What a 10-month system investment actually delivered.
The impact of a design system shows up everywhere — in how fast screens get designed, how few bugs come from styling mismatches, and how confidently engineers build from a handoff file.
Design Impact
~50%
Faster screen creation after the system reached maturity.
- Near-zero duplicate components across the library
- Consistent UI across dashboards, admin pages, and flows
- New screens started from a shared foundation — not from scratch
Development Impact
1:1
Mantine mapping eliminated an entire class of styling mismatch bugs.
- Spacing values matched exactly between design and code
- State logic pre-defined — no interpretation needed
- Significantly reduced back-and-forth during QA
Product Impact
MVP+
System shipped with the MVP and kept expanding across product phases.
- Supported dashboards, admin tools, and research workflows
- Foundation ready for full accessibility expansion
- No structural rework needed after 10 months of iteration
The system in action
The same system powering three distinct user experiences.
One design system — three different contexts. The personal dashboard, Research Lab view, and Data Organization view all use the same components, tokens, and spacing rules. Color-coded role distinction is built into the system itself, not applied after the fact.
Personal dashboard
Role switcher, unified studies table across Research Labs and Data Orgs
Research Lab view
Green color system, Data Catalog access, proposal submission flow
Data Organization view
Blue color system, review studies table, admin controls
01
End to end coverage
From tokens to templates — every layer of the product UI is supported by the system, from the smallest icon to full dashboard layouts.
02
Multi-phase scalability
The system expanded continuously across 10 months without requiring structural rework — proof that the nested architecture held up under real product pressure.
03
Accessibility ready
Focus states, contrast considerations, and keyboard navigation groundwork are in place. The foundation is ready for full a11y guidelines as the platform evolves.
Reflection
What building a system from scratch taught me.
12 months designing SafeInsights' design system taught me things no brief could have anticipated.
01
Tokens are decisions, not just values.
Setting up the token system before building any components felt slow. In hindsight it was the most important investment I made. Every decision encoded in a token — a spacing value, a semantic color, a state was a decision I never had to make again.
02
Nesting saves maintenance. Maintenance saves everything.
Nested component structures paid dividends every time the product changed direction — which it did, repeatedly. An update to a base button propagated across every variant and state automatically. Without nesting, the same change meant hunting through dozens of components manually.
03
A design system is a collaboration tool.
The most important parts of the system were built in close conversation with engineering. When developers were involved early — in naming, token structure, and component logic — the system held. When they weren't, it showed. The system's real value wasn't the Figma file. It was the shared understanding it created.
If I started again
Three things I'd do differently from day one.
Every design system reveals its gaps over time. These are the decisions I'd make earlier, not because anything went wrong, but because making them sooner would have compounded the value of things built after.
-
01
-
02Introduce a token-to-code pipeline earlierCreating styles manually caused inconsistencies. Using a token system from the beginning would have kept design and code aligned.
-
03Add usage examples to documentation from day oneGuidelines alone aren’t enough. Showing real examples of how components are used would have helped people learn faster and avoid mistakes.
