Design System ownership
- Role
- Senior Product Designer
- Period
- 2021-2024
- Focus
- System architectureGovernanceDesign handoff
- Product context
- ScomplerSaaSDesign system
Context
Scompler is a complex B2B SaaS platform for enterprise marketing and content teams. Its planning, collaboration, editorial and reporting workflows span several modules and user roles, yet the interface had no shared design foundation.
I joined as the second Product Designer and took ownership of creating a scalable system and the working agreements needed to keep it consistent across design and frontend delivery.
Users and product landscape
The platform served planners, editors, community managers and system managers. They moved across modules with different goals and mental models, so inconsistent patterns increased cognitive load and slowed work in already complex workflows.
- Editors, creators, spokespeople, content specialists and copywriters created and refined content.
- Community managers managed social-channel activity and engagement workflows.
- Topic, channel, campaign and content-strategy managers planned direction and timing.
- Product, target-group and SEO managers, project owners and team leads configured and governed the platform.
Challenges
- Fragmented UI across modules: the same interaction used different patterns.
- Slow delivery from rework and inconsistent handoff between design and frontend.
- Low scalability: new features often created one-off UI and more maintenance cost.
- No governance: even strong components could drift over time.
Goals
- Create a consistent product language across modules and personas.
- Increase delivery speed through reuse and less rework.
- Improve UI quality through standards for states, content rules and accessibility.
- Build a maintainable governance model for intake, review and prioritisation.
- Establish a reliable Figma ↔ Storybook implementation pipeline.
What I owned
- Design-system architecture: tokens → components → patterns and templates.
- Component variants, states and usage guidelines.
- Governance, review, prioritisation and documentation standards.
- Figma specs aligned with Storybook implementation and Confluence documentation.
- Asana epics and tasks that made design-system delivery visible and trackable.
Start with tokens
The system started by standardising the fundamentals: typography, colour, icons, spacing, radius and shadows. These foundations were tokenised as a shared consistency contract for design and implementation.
Typography system
Typography tokens locked in hierarchy and readability across dashboards and dense workflows. Text styles defined size, weight, line-height and usage guidance so custom styles did not creep into new screens.
Colour tokens and semantic palette
A semantic palette standardised status meaning, interaction states and accessibility-aware contrast. Surface, text, primary and critical tokens carried intent rather than raw values, so the system could evolve without per-screen overrides.
Spacing, radius and icons
A deliberately small spacing and radius scale removed arbitrary layout decisions. Icons were also standardised as a reusable foundation so common actions and meanings remained consistent across modules.
Build core components first
High-frequency UI came next: buttons, form controls, switches, chips, accordions, dropdowns, avatars and pickers. Each component defined variants, states and usage guidance so it could be implemented and reused consistently.
Actions and form controls
Data and feedback components
Scale into patterns and templates
To support workflow complexity beyond single components, I standardised navigation, forms, search, modals, tables and lists, filters, empty states and recurring create, edit and delete flows. This is where the design system directly shaped product behaviour—not just UI polish.
Modal and navigation patterns
Modal structure and navigation behaviour were standardised so critical flows had predictable close rules, focus handling, actions, pagination and wayfinding.
Object lifecycle and usage guidance
Patterns made recurring administrative actions, component usage and empty states easier to recognise and apply. Teams could choose an established solution rather than inventing one-off behaviour.
Establish a working source of truth
A design system only works when people can trust and use it quickly. Figma held the design source and specifications, Storybook represented implemented component behaviour, and Confluence documented usage rules, examples and edge cases.
This Figma UI Kit ↔ Storybook ↔ Confluence mapping reduced ambiguity, prevented design-to-code drift and made onboarding easier as new features shipped.
Governance and delivery workflow
To keep the system healthy over time, I introduced a visible governance workflow instead of treating design-system work as an unowned side project.
- New component and pattern requests entered an intake, review and frontend-alignment flow.
- Requests were prioritised and tracked through Asana epics → tasks covering design, documentation, implementation and rollout.
- Documentation standards and implementation references made the expected solution inspectable before new variants were created.
Validation and iteration
As analytics and feedback loops matured, patterns were validated and refined through customer and stakeholder feedback, qualitative sessions where possible, and quantitative signals such as task-completion improvement and reduced friction.
The aim was to move decisions from opinions about UI toward evidence about workflows.
Migration and adoption
Legacy UI was migrated gradually, module by module. Work prioritised the most important or actively improved areas, while legacy components were rebuilt or replaced as part of ongoing product delivery.
- A gradual path avoided blocking feature work with a disruptive rewrite.
- The adoption rule was clear: all new features were built using the design system.
- That rule stopped new fragmentation while the legacy surface was brought into alignment over time.
Impact
The result was a more consistent product experience and a clearer delivery contract across product, design and engineering.
- Approximately 35–40% faster design and frontend delivery through reusable components, aligned tokens and a predictable handoff pipeline.
- A foundation of 200+ UI components and patterns for ongoing product development.
- Less design–development friction through an operational shared source of truth across Figma, Storybook and Confluence.
- A sustainable path away from fragmented legacy UI through gradual migration and a new-feature adoption rule.
200+
UI components and patterns
35–40%
Faster design and frontend delivery
3
Connected sources of truth
Reflection
The durable result was a product capability: teams could reuse an agreed solution, understand how it was implemented and know where to take the next decision.
What worked
- Starting with tokens and aligning with Tailwind/atomic CSS made the system implementation-friendly from day one.
- Prioritising core components and then patterns and templates addressed the workflow complexity where users actually worked.
- Figma, Storybook and Confluence made the system usable rather than theoretical.
- A new-features-must-use-the-system rule and gradual migration made adoption real.
What was hard
- Legacy migration required patience and cross-functional coordination; it could not be solved in one release.
- Limited frontend capacity meant governance and documentation had to keep prioritisation focused.
- Without formal versioning, process discipline and clear rules carried more of the system’s maintenance load.
What I learned
A design system scales when it is treated as a product capability: a solid token foundation, reusable components and workflow patterns, a trusted source of truth with governance, and an adoption strategy that prevents drift.
Featured Projects
My product design cases from the last few years.
