Gomada Design System: scaling product UI
A lightweight design system that aligned product and marketing UI, reduced inconsistencies and helped the team ship faster with reusable components, tokens and clear usage guidelines.
2022 - 2023
-
· Design System · B2B SaaS ·
Scroll
Overview
My role
Design Owner
Team Composition
1 UX/UI Designer (me) + 3 Founders + 1 Project Manager + 3 Developers + 1 part-time Visual Designer
Gomada was evolving quickly: new features, new pages and multiple contributors meant the UI started to drift — different button styles, inconsistent spacing, diverging patterns. I led the creation of a pragmatic design system to keep the product cohesive while still moving at startup speed.
The focus wasn't "a perfect library", but an adoptable system: a clear visual language, reusable components and guidelines that designers and engineers could apply immediately.
Challenge
The team building Gomada, designers, engineers and stakeholders, needed a consistent, predictable UI language so they could create and maintain screens without re-deciding basics (spacing, type, buttons, inputs) every time.
Business Goals
Increase delivery speed and UI quality by reducing rework and inconsistency, enabling the team to ship new features with confidence and maintain a coherent brand experience as the product scaled.
Key Pain Points
01
Slow design-to-dev handoff: engineers had to interpret one-off designs; QA found repeated UI bugs.
02
Inconsistent UI patterns: same intent, different component styles and a lack of shared definitions and spacing rules weren't standardised.
03
Scaling risk: as more surfaces were added (dashboards, activities, onboarding), consistency degraded.
Problem to solve
How might we create a design system that the team actually adopts, one that reduces UI drift and speeds up delivery without slowing down product work?
Discovery
I treated design system work like a product problem: understand the current state, identify the highest-impact gaps and prioritize what the team would actually adopt.
Research and discovery methods used:
UI audit of key product surfaces: dashboard, activity flow and onboarding to catalog inconsistencies.
Engineering constraints review: existing front-end patterns and component approach.
Brand and marketing alignment check: ensuring the system supported Gomada's voice, friendly, credible and "no-prep".
Lightweight internal interviews with PM and engineers: what slows shipping and where UI decisions get stuck.
Key Insights
Big time sink:
The biggest time sink wasn't new components it was variants, size and state differences and edge cases.
Tokens first:
Tokens like type, color and spacing were needed to stop visual drift before building a full component library.
Real adoption:
Adoption would only happen if the system was small, opinionated and documented with real examples.
Versatile system:
The system had to cover both product UI and marketing-like surfaces, balancing credibility with warmth.
Strategy
I structured the system around Brad Frost's atomic design model to keep it scalable and navigable in both Figma and code. The goal was an adoptable system, not a complete one. Foundations first, then components mapped to real screens and real dev needs, then documented patterns to handle recurring decisions.
Design Principles
Start with foundations — type scale, spacing, color, elevation, radius, icon rules...
Design with constraints: fewer options and clear defaults.
Build for reuse, not for the file: components mapped to real screens and dev needs.
Document decisions: usage guidance and do/don't examples to reduce interpretation.
Strategy methods
The architecture I choose to follow was inspired by Brad Frost's Atomic Design. I picked this method because of its logic and how it will help me to organise my components by complexity and find them quickly.
Atoms:
Color tokens (semantic), typography styles, spacing scale, radius and elevation rules, icon rules.
Molecules:
Labeled input, button with icon and loading state, tag/badge with status color.
Organisms:
Empty state block, toast/banner system, navigation blocks.
Templates:
Layout recipes for dashboard, forms and activity flows.
Pages:
Onboarding, dashboard, plan and activity screens used as live examples to test system coverage.
Solution
I built the system in parallel with product delivery to keep it grounded in real use cases. The approach moved from foundations to components to patterns — each layer validated against actual screens before moving on.
From v0 to v1: reduced acceptable component variations, replaced bespoke spacing with shared layout recipes, and clarified naming to match engineering terminology.
Key screens narrative
Foundations and tokens:
Semantic color tokens keep UI intent consistent even when the palette evolves. Typography scale balances "friendly" with "credible". Spacing rules align layouts across screens and contributors.
Component library:
Buttons with all states ( default / hover / pressed / disabled / loading ), inputs with label/hint/error structure, cards and list items with consistent padding and interactive affordances, badges unified across dimensions and statuses.
Patterns:
Documented checklists, empty states and onboarding steps so teams can assemble screens quickly. Usage guidelines cover the decisions that previously caused drift: button hierarchy, long labels, stacked input spacing.
Testing
Internal design critiques with stakeholders to confirm brand alignment and clarity. Developer pairing to ensure components mapped to implementation realities. Usability checks on updated screens to confirm the system didn't reduce clarity or accessibility.
Results
Faster design-to-dev cycles for new screens because common elements were already defined.
Reduced UI inconsistencies across onboarding, dashboard, and activity flows.
Improved team confidence in making UI decisions independently (clear defaults + guidelines).
🚨
Results Caveat
Formal metrics (time saved per feature, QA UI bugs, design clarification requests) were not tracked at v1. Identified as a next step for future measurement.
Learnings
What I've Learned
Design systems succeed when they optimise for adoption, not completeness.
Semantic tokens create stability even when visuals change.
Documentation is part of the product, examples and do/don't rules prevent drift more than component count.
What I'd do differently
Add a clearer measurement plan from day one: track QA UI bugs, time-to-ship and reuse rate.
Align earlier on engineering component strategy: Storybook cadence, ownership and release notes.
Next Steps
Expand the library with higher-complexity components — tables, filters, modals.
Add accessibility checks as a formal gate: contrast, focus states, keyboard flows.
Create a simple release process for system updates: changelog and versioning.
Gomada Design System: scaling product UI
A lightweight design system that aligned product and marketing UI, reduced inconsistencies and helped the team ship faster with reusable components, tokens and clear usage guidelines.
2022 - 2023
-
· Design System · B2B SaaS ·
Scroll
Overview
My role
Design Owner
Team Composition
1 UX/UI Designer (me) + 3 Founders + 1 Project Manager + 3 Developers + 1 part-time Visual Designer
Gomada was evolving quickly: new features, new pages and multiple contributors meant the UI started to drift — different button styles, inconsistent spacing, diverging patterns. I led the creation of a pragmatic design system to keep the product cohesive while still moving at startup speed.
The focus wasn't "a perfect library", but an adoptable system: a clear visual language, reusable components and guidelines that designers and engineers could apply immediately.
Challenge
The team building Gomada, designers, engineers and stakeholders, needed a consistent, predictable UI language so they could create and maintain screens without re-deciding basics (spacing, type, buttons, inputs) every time.
Business Goals
Increase delivery speed and UI quality by reducing rework and inconsistency, enabling the team to ship new features with confidence and maintain a coherent brand experience as the product scaled.
Key Pain Points
01
Slow design-to-dev handoff: engineers had to interpret one-off designs; QA found repeated UI bugs.
02
Inconsistent UI patterns: same intent, different component styles and a lack of shared definitions and spacing rules weren't standardised.
03
Scaling risk: as more surfaces were added (dashboards, activities, onboarding), consistency degraded.
Problem to solve
How might we create a design system that the team actually adopts, one that reduces UI drift and speeds up delivery without slowing down product work?
Discovery
I treated design system work like a product problem: understand the current state, identify the highest-impact gaps and prioritize what the team would actually adopt.
Research and discovery methods used:
UI audit of key product surfaces: dashboard, activity flow and onboarding to catalog inconsistencies.
Engineering constraints review: existing front-end patterns and component approach.
Brand and marketing alignment check: ensuring the system supported Gomada's voice, friendly, credible and "no-prep".
Lightweight internal interviews with PM and engineers: what slows shipping and where UI decisions get stuck.
Key Insights
Big time sink:
The biggest time sink wasn't new components it was variants, size and state differences and edge cases.
Tokens first:
Tokens like type, color and spacing were needed to stop visual drift before building a full component library.
Real adoption:
Adoption would only happen if the system was small, opinionated and documented with real examples.
Versatile system:
The system had to cover both product UI and marketing-like surfaces, balancing credibility with warmth.
Strategy
I structured the system around Brad Frost's atomic design model to keep it scalable and navigable in both Figma and code. The goal was an adoptable system, not a complete one. Foundations first, then components mapped to real screens and real dev needs, then documented patterns to handle recurring decisions.
Design Principles
Start with foundations — type scale, spacing, color, elevation, radius, icon rules...
Design with constraints: fewer options and clear defaults.
Build for reuse, not for the file: components mapped to real screens and dev needs.
Document decisions: usage guidance and do/don't examples to reduce interpretation.
Strategy methods
The architecture I choose to follow was inspired by Brad Frost's Atomic Design. I picked this method because of its logic and how it will help me to organise my components by complexity and find them quickly.
Atoms:
Color tokens (semantic), typography styles, spacing scale, radius and elevation rules, icon rules.
Molecules:
Labeled input, button with icon and loading state, tag/badge with status color.
Organisms:
Empty state block, toast/banner system, navigation blocks.
Templates:
Layout recipes for dashboard, forms and activity flows.
Pages:
Onboarding, dashboard, plan and activity screens used as live examples to test system coverage.
Solution
I built the system in parallel with product delivery to keep it grounded in real use cases. The approach moved from foundations to components to patterns — each layer validated against actual screens before moving on.
From v0 to v1: reduced acceptable component variations, replaced bespoke spacing with shared layout recipes, and clarified naming to match engineering terminology.
Key screens narrative
Foundations and tokens:
Semantic color tokens keep UI intent consistent even when the palette evolves. Typography scale balances "friendly" with "credible". Spacing rules align layouts across screens and contributors.
Component library:
Buttons with all states ( default / hover / pressed / disabled / loading ), inputs with label/hint/error structure, cards and list items with consistent padding and interactive affordances, badges unified across dimensions and statuses.
Patterns:
Documented checklists, empty states and onboarding steps so teams can assemble screens quickly. Usage guidelines cover the decisions that previously caused drift: button hierarchy, long labels, stacked input spacing.
Testing
Internal design critiques with stakeholders to confirm brand alignment and clarity. Developer pairing to ensure components mapped to implementation realities. Usability checks on updated screens to confirm the system didn't reduce clarity or accessibility.
Results
Faster design-to-dev cycles for new screens because common elements were already defined.
Reduced UI inconsistencies across onboarding, dashboard, and activity flows.
Improved team confidence in making UI decisions independently (clear defaults + guidelines).
🚨
Results Caveat
Formal metrics (time saved per feature, QA UI bugs, design clarification requests) were not tracked at v1. Identified as a next step for future measurement.
Learnings
What I've Learned
Design systems succeed when they optimise for adoption, not completeness.
Semantic tokens create stability even when visuals change.
Documentation is part of the product, examples and do/don't rules prevent drift more than component count.
What I'd do differently
Add a clearer measurement plan from day one: track QA UI bugs, time-to-ship and reuse rate.
Align earlier on engineering component strategy: Storybook cadence, ownership and release notes.
Next Steps
Expand the library with higher-complexity components — tables, filters, modals.
Add accessibility checks as a formal gate: contrast, focus states, keyboard flows.
Create a simple release process for system updates: changelog and versioning.
Gomada Design System: scaling product UI
A lightweight design system that aligned product and marketing UI, reduced inconsistencies and helped the team ship faster with reusable components, tokens and clear usage guidelines.
2022 - 2023
-
· Design System · B2B SaaS ·
Scroll
Overview
My role
Design Owner
Team Composition
1 UX/UI Designer (me) + 3 Founders + 1 Project Manager + 3 Developers + 1 part-time Visual Designer
Gomada was evolving quickly: new features, new pages and multiple contributors meant the UI started to drift — different button styles, inconsistent spacing, diverging patterns. I led the creation of a pragmatic design system to keep the product cohesive while still moving at startup speed.
The focus wasn't "a perfect library", but an adoptable system: a clear visual language, reusable components and guidelines that designers and engineers could apply immediately.
Challenge
The team building Gomada, designers, engineers and stakeholders, needed a consistent, predictable UI language so they could create and maintain screens without re-deciding basics (spacing, type, buttons, inputs) every time.
Business Goals
Increase delivery speed and UI quality by reducing rework and inconsistency, enabling the team to ship new features with confidence and maintain a coherent brand experience as the product scaled.
Key Pain Points
01
Slow design-to-dev handoff: engineers had to interpret one-off designs; QA found repeated UI bugs.
02
Inconsistent UI patterns: same intent, different component styles and a lack of shared definitions and spacing rules weren't standardised.
03
Scaling risk: as more surfaces were added (dashboards, activities, onboarding), consistency degraded.
Problem to solve
How might we create a design system that the team actually adopts, one that reduces UI drift and speeds up delivery without slowing down product work?
Discovery
I treated design system work like a product problem: understand the current state, identify the highest-impact gaps and prioritize what the team would actually adopt.
Research and discovery methods used:
UI audit of key product surfaces: dashboard, activity flow and onboarding to catalog inconsistencies.
Engineering constraints review: existing front-end patterns and component approach.
Brand and marketing alignment check: ensuring the system supported Gomada's voice, friendly, credible and "no-prep".
Lightweight internal interviews with PM and engineers: what slows shipping and where UI decisions get stuck.
Key Insights
Big time sink:
The biggest time sink wasn't new components it was variants, size and state differences and edge cases.
Tokens first:
Tokens like type, color and spacing were needed to stop visual drift before building a full component library.
Real adoption:
Adoption would only happen if the system was small, opinionated and documented with real examples.
Versatile system:
The system had to cover both product UI and marketing-like surfaces, balancing credibility with warmth.
Strategy
I structured the system around Brad Frost's atomic design model to keep it scalable and navigable in both Figma and code. The goal was an adoptable system, not a complete one. Foundations first, then components mapped to real screens and real dev needs, then documented patterns to handle recurring decisions.
Design Principles
Start with foundations — type scale, spacing, color, elevation, radius, icon rules...
Design with constraints: fewer options and clear defaults.
Build for reuse, not for the file: components mapped to real screens and dev needs.
Document decisions: usage guidance and do/don't examples to reduce interpretation.
Strategy methods
The architecture I choose to follow was inspired by Brad Frost's Atomic Design. I picked this method because of its logic and how it will help me to organise my components by complexity and find them quickly.
Atoms:
Color tokens (semantic), typography styles, spacing scale, radius and elevation rules, icon rules.
Molecules:
Labeled input, button with icon and loading state, tag/badge with status color.
Organisms:
Empty state block, toast/banner system, navigation blocks.
Templates:
Layout recipes for dashboard, forms and activity flows.
Pages:
Onboarding, dashboard, plan and activity screens used as live examples to test system coverage.
Solution
I built the system in parallel with product delivery to keep it grounded in real use cases. The approach moved from foundations to components to patterns — each layer validated against actual screens before moving on.
From v0 to v1: reduced acceptable component variations, replaced bespoke spacing with shared layout recipes, and clarified naming to match engineering terminology.
Key screens narrative
Foundations and tokens:
Semantic color tokens keep UI intent consistent even when the palette evolves. Typography scale balances "friendly" with "credible". Spacing rules align layouts across screens and contributors.
Component library:
Buttons with all states ( default / hover / pressed / disabled / loading ), inputs with label/hint/error structure, cards and list items with consistent padding and interactive affordances, badges unified across dimensions and statuses.
Patterns:
Documented checklists, empty states and onboarding steps so teams can assemble screens quickly. Usage guidelines cover the decisions that previously caused drift: button hierarchy, long labels, stacked input spacing.
Testing
Internal design critiques with stakeholders to confirm brand alignment and clarity. Developer pairing to ensure components mapped to implementation realities. Usability checks on updated screens to confirm the system didn't reduce clarity or accessibility.
Results
Faster design-to-dev cycles for new screens because common elements were already defined.
Reduced UI inconsistencies across onboarding, dashboard, and activity flows.
Improved team confidence in making UI decisions independently (clear defaults + guidelines).
🚨
Results Caveat
Formal metrics (time saved per feature, QA UI bugs, design clarification requests) were not tracked at v1. Identified as a next step for future measurement.
Learnings
What I've Learned
Design systems succeed when they optimise for adoption, not completeness.
Semantic tokens create stability even when visuals change.
Documentation is part of the product, examples and do/don't rules prevent drift more than component count.
What I'd do differently
Add a clearer measurement plan from day one: track QA UI bugs, time-to-ship and reuse rate.
Align earlier on engineering component strategy: Storybook cadence, ownership and release notes.
Next Steps
Expand the library with higher-complexity components — tables, filters, modals.
Add accessibility checks as a formal gate: contrast, focus states, keyboard flows.
Create a simple release process for system updates: changelog and versioning.