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
My role
Product design, user research, Competitive analysis, Stakeholder management, user testing, Product management and project management.
The team
1 designer, 20 Engineers, 1 Engineering Manager
Timeline
Jan 2025 - May 2025
OVERVIEW
What i did
I worked with the design system manager to build icons, illustrations and components for the design system
I defined the design system's structure, language, and process for future
I led the mobile design system once i learnt the ropes of building the web design system to bring our mobile designs to the same level to fruition
OVERVIEW
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.
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?
NORTH STAR METRICS
Our guiding principles
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
Who we are
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.
DESIGN PRINCIPLES
The atomic patterns
Design system requires a solid foundation. Atomic design principles were at the core of how the design system was evangelised.
Iconography suite
We created icons for 4 different sizes, 24px, 20 px, 16 px and 32 px
All icons have an underlying similar gridlines structure
Some icons I created
Colour exercises
Components building
Since the atoms were established once i had joined, i begun work on the components.
Component breakdown
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.
DOCUMENTATION
Setting up processes
I established the design systems way of working, research, planning, comeptitor analysis and organizaiton
Conducting a product audit
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
Market research
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
Creating a solution document
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.
DOCUMENTATION
Presentation and handoff
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.
CREATING PLAYBOOKS
Icon playbook
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
Component playbook
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
Establishing guidelines
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
THE METRICS
Measuring the impact of a design system
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
Created over 100+ icons and 30+ illustrations
Increased onboarding efficiency by creating component and icon playbooks
Mentored junior designers and supported system-wide adoption, establishing rituals for contribution and quality control.
And more!
i also created a layout and grids system which provides guidelines on how to apply grids, breakpoints, spacing and guidelines. I also created a presentation on it for the design team followed by hamds on exercises where people use the layout component breakpoints and recreate screens and create web and mobile verisons of them. Please reach out to me for further details!
PLANNING
Sprint planning
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.
COMMUNICATION
Staying connected
#design-system-requests
We ran #design-system-request channel on Slack 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.
slack canvases and Coda documents
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
