Jun 2021 - Jun 2022 · 1 Designer, 1 Design manager, 5 engineers · Toddle
How we took Toddle's design system from 5 components to a foundation that scales
When i joined as one of the first designers int he design system team, it was just me, and my manager. I took time to understand the current atomic status of the company, and saw that colours, icon guidelines typography had been implemented along with 5-6 components. A design system is a living breathing entitiy, the backbone of every brand, that ties the brand language together, while speeding up developmental and design processes, demanding consistency and attentinoal to detail
What did we achieve?
Over the course of six months, we transformed the design system from a fragmented set of patterns into a cohesive, scalable foundation. I led efforts in building reusable components, iconography, and illustration libraries—while also documenting the system for scale. By focusing on system thinking, adoption metrics, and onboarding friction points, I was able to track tangible impact across the organization
Component coverage of 25% to 85% in 6 months
Systematically audited and rebuilt components across the product, ensuring every core pattern had a documented, reusable equivalent in the library.
Created over 100+ icons and 30+ illustrations
Built a consistent iconography system from scratch and an illustration library covering all empty states, onboarding moments, and product storytelling needs.
Dropped from 70% of screens having custom components to under 20% after the system matured.
As component coverage grew, designers stopped building from scratch. Reuse rate climbed from 30% to 85% across active product files.
Dropped from 200+ inconsistency-related bugs per quarter to under 20 after full component adoption.
Full component adoption meant fewer visual discrepancies making it into production, reducing QA cycles and developer rework significantly.
Increased onboarding efficiency by creating component and icon playbooks
Component and icon playbooks gave new designers a structured onboarding path, cutting the time to productivity by over 60%.
Mentored junior designers and supported system-wide adoption, establishing rituals for contribution and quality control.
Ran regular design system office hours, reviewed contributions, and set quality standards that allowed the system to scale beyond a single owner.
Modern Software requires modern design systems
The design system was a one off solution created by different stakeholders and different periods of time, resulting in a mixed visual language. Implemented designs were hard to keep track of because they lacked consistency and scalability from the development side as well. in a fast growing startup, these occurrences are inevitable.
As one of the first designers in the design system team, with the system still in its nascent stage, I faced the challenge of setting up processes and methods to research, document, create design components, and hand them over for implementation in the storybook. The goal was to develop a scalable approach for research, documentation, handover, structure, and organization while designing new components and conducting design audits. I collaborated with my manager to understand the current design system and refine these processes.
I worked with the design system manager to build icons, illustrations, and components
Collaborated closely to define component structure, contributed to the iconography library, and built illustration assets that covered product needs across empty states and onboarding flows.
I defined the design system's structure, language, and process for the future
Established documentation standards, naming conventions, and handover processes so new components could be added consistently. Created a scalable approach for research, auditing, and contribution that the team could build on.
I led the mobile design system once I learned the ropes of the web system
After ramping up on the web design system, I took ownership of bringing the mobile system to the same level of maturity, ensuring parity across platforms and giving developers a reliable foundation to build from.
But Toddle was still at a very early stage
I analyzed instances from the product, focusing on an enterprise-level system. After identifying these issues, I cataloged all the components requiring design and assessed their impact on the product. With my manager's guidance, I tackled each component individually, ensuring a robust process and documentation were established for each.
The process accounted for three key issues:
Existing components with inconsistent visual language
Incorrect usage of components
Categorization of component variants
How might we create components that align with the existing design system's visual language without reinventing the wheel?
How might we document processes and methods to establish a framework for new designers onboarding?
How might we document component guidelines effectively?
Our guiding principles
Before building anything, we aligned on what the system needed to stand for. Three principles shaped every decision we made.
Functional
Toddle should expedite the design and dev teams work
Everything should be available on figma to drag and frop from the assets panel
Iterative
We would research best practices well and be iterative about our processes
We will take coninuous feedback from designers and developers and also adapt to constant and change requirements and patterns fast
Documented
We would document everything and it would constantly evolve to the teams changing needs
Should have a clear onboarding guide and a communications channel to jump into the system quickly
The team that built it
The design system team included product designers, UX designers, visual designers, QA, and frontend engineers who actively contributed to building and maintaining the system. Backend engineers and QA teams were closely involved in implementation and testing.
We also collaborated with the broader UX team to regularly test usability and gather feedback across modules. For large and complex components like document editors or data grids, we worked with dedicated cross-functional pods to ensure quality and scalability, while the core team focused on driving the main system forward.
Everything in the system is built from the same small parts
A design system is only as consistent as its foundations. We structured ours around atomic design principles, starting at the smallest possible unit and building up. Atoms become components, components become patterns, patterns become product. Getting this layer right meant everything built on top of it would hold together without constant correction.
We built an iconography suite across four sizes, with a shared grid underneath all of it
Icons are one of the most touched parts of any product and one of the easiest things to let drift. We designed icons at 16px, 20px, 24px, and 32px, each size serving a specific context, from dense data tables to large empty states. Every icon sits on the same underlying gridline structure, which means they feel like they belong to the same family regardless of where they appear in the product. The consistency isn't visible, but the inconsistency would have been.
Toddle's colours were failing WCAG. We fixed that before building anything else.
The foundation colours had already been laid out in the system, but when we audited them against WCAG and APCA accessibility guidelines, a significant number of combinations were failing.
I ran a full colour analysis to identify every failing combination, then built a step by step implementation plan to bring them into compliance without breaking the visual language that already existed. This meant solving for edge cases like progressive colour variants and the yellow palette, which are notoriously difficult to make accessible without losing their character.
With the foundations solid, I moved on to building the components.
Atoms were in place when I joined. The components built on top of them weren't. I worked through the component library systematically, starting with the most touched parts of the product. Every component was built with full state coverage: default, disabled, hover, focus, and pressed. Fill buttons, text buttons, outlined buttons, each one documented with the exact token values for fill, border, and text so developers could implement without guessing.
Breaking down components for Handoff
To improve the hand-off process from design to development, component breakdown was introduced as a means of communicating this aspect. It has also proven to be a valuable documentation tool for component behaviour and attributes. Figma’s Dev mode helps too!
Aligning use of language
When implementing the design system, I noticed the lack of consistent naming for various components. To bridge the gap between designers, developers, and other stakeholders, I introduced attributes (design tokens) in the design system documentation. This facilitated clearer communication about design decisions and improved discussions around components at a granular level.
For instance, what some called a "menu," others referred to as a "dropdown" or "sheet." Such inconsistencies often led to detailed discussions and potential miscommunication. To address this, I emphasized the 'Anatomy' of a component, detailing the different variables, like the example below. This approach ensured everyone was on the same page and minimized misunderstandings.
RECAP FLOW
Setting up processes
I established the design systems way of working, research, planning, comeptitor analysis and organizaiton
I built a template to audit every component in the product
To streamline this process, I created a template. For instance, tables were grouped into categories such as tables with group headers, data grids, standard tables, lists, cells with avatars, cells with subtext, icon cells, and button cells. This helped to clearly identify and create the necessary variants
This table was originally made on Coda, and distilled here as a template
We looked at how the best design systems in the world built the same components.
I also researched best practices, examining how components are made in other design systems. Instead of reinventing the wheel, I reviewed their product documentation, played with their components in Storybook, and analyzed their construction in Figma (where available).
This table was originally made on Coda, and distilled here as a template
Every solution started with the audit
Throughout this process, I consistently referred back to the product audit to ensure I was addressing actual problems, not inventing new ones. Ideas and inspirations for non-existent variants were noted for future phases in the product roadmap if they proved relevant.
When presenting the solution document, I compiled existing problems and proposed solutions to create components and variants. The document was structured in phases, detailing current issues and potential future challenges based on my research. This phased approach ensured a comprehensive understanding and a clear path forward. Designs were then explored.
We made sure every component came with a manual.
One of the main challenges in creating a unified design and development language is effective documentation and guidelines. To address this, I created comprehensive dos and don'ts for each component, including examples of their usage within the platform. The documentation also covered best practices, specifications, variants, sub-variants, and different component states. This ensured clear communication and consistency across the team. Below is an example for a dropdown component and a button component.
Every component got its own documentation page.
Each page covered what the component is, where it lives in the product, how it's structured, what triggers each variant, and what edge cases to watch for. The dropdown documentation alone covered anatomy, best practices, variations, sub-variations, and trigger states. If a designer or developer had a question about a component, the answer was already written down.
CREATING PLAYBOOKS
Created an icon playbook that standardised how every icon gets made, from grid to final asset
After six months of building icons and illustrations, I put together a playbook to standardize icon creation across the company. This documented best practices around grid usage, stroke weight, corner radii, visual balance, and metaphor consistency. It also included templates and process guidelines for contributing new icons to the system. The goal was to maintain visual coherence while giving designers autonomy to expand the system confidently and efficiently
CREATING PLAYBOOKS
Created a component playbook that became the single source of truth for the entire design system
To streamline collaboration and reduce inconsistencies, I created a detailed component playbook. It served as a single source of truth for how and when to use components within the design system. The playbook included usage guidelines, anatomy, states, variants, and do-don’t examples. It helped bridge the gap between design and development, reduced back-and-forths, and enabled faster onboarding of new designers. Over time, this became a critical artifact for scaling the design system across teams
CREATING PLAYBOOKS
Established guidelines so the system could grow without losing consistency
After six months of building icons and illustrations, I put together a playbook to standardize icon creation across the company. This documented best practices around grid usage, stroke weight, corner radii, visual balance, and metaphor consistency. It also included templates and process guidelines for contributing new icons to the system. The goal was to maintain visual coherence while giving designers autonomy to expand the system confidently and efficiently
We tracked every component, every request, and every sprint in one place so nothing got lost between tools.
We used Coda to maintain a shared roadmap and drive sprint planning. This acted as our single source of truth; opening every sync with it to align on priorities, unblock work, and track progress.
The roadmap was built on a master table with multiple views to:
Plan next steps and record tasks
Track changes component wise
Record requests for icons, illustrations and more
This space also served as a collaborative space to document product requirements, research notes, and system decisions, ensuring full visibility for all contributors across the project.
Created a dedicated Slack channel so any team could request components, flag issues, and stay in the loop
We ran #design-system-request channel on Slack to:
The roadmap was built on a master table with multiple views to:
Provide a central space for teams to request new components or updates
Respond quickly to questions and unblock design or engineering teams
Keep everyone aligned with regular updates on progress and changes
This space also served as a collaborative space to document product requirements, research notes, and system decisions, ensuring full visibility for all contributors across the project.
Created a system for tracking requests and communicating changes
To streamline tracking and communication, we used Coda and Slack canvases together to:
Log and manage icon and illustration requests via a shared Coda tracker
Communicate upcoming design system changes to designers and engineers, giving clear visibility into what’s being built and when their request would be addressed
