Introduction
I’m someone who thrives on structure and process—they’re my go-to tools for tackling most challenges, both in life and at work. This mindset naturally aligns with my love for design systems.
In this write-up, I’ll walk you through how I approached building a practical design system from the ground up at Upraised. We named it ‘Rising’—inspired by our brand name, with ‘raise’ at its core and the addition of ‘ing’ symbolising the evolving nature of design system work.
Let’s dive into the journey of how we built ‘Rising’ at Upraised and the impact it created.
Why Upraised Needed a Design System?
At Upraised, we empower learners and coaches to learn and teach product management through our in-house digital platforms. Delivering a seamless user experience within tight timelines was critical to our business. But as we scaled, we began to drift from this goal.
Here’s why:
01
Team growth led to inconsistencies
When our design and engineering teams expanded (from 2 to 6 designers and 4 to 7 engineers), cracks started to show. Without a unified standard, each designer brought their own style to the table, and as a result, our interfaces began to feel disjointed.
02
Our designers and engineers weren’t just working with different tools; they were speaking different languages. For example, what a designer called a “toast,” a developer referred to as a “snackbar.”
Neither was logically incorrect, but the misalignment led to confusion and friction in implementation. We gradually got slower with more people and no documentation of design decisions.
03
Focus drifted from impactful problem-solving to repetitive work
Significant time was spent on minor tasks like adjusting colors or fixing visual inconsistencies for hand-off. This distracted the team from solving other product challenges with a bigger business impact like optimising designs for drop-offs during onboarding.
While these challenges might seem internal, their ripple effects were far-reaching.
For our end users—learners and coaches—the result was a fragmented experience.
For our teams, it meant frustration & inefficiency.
We knew we needed a solution that could address all these issues under one umbrella:
A Design System.
Solution Showcase
Let’s look at some visuals built with the design system before I talk about my process.
Few of these elements are interactive, you can play with them.
Which of these tools do you use the most?
Enforce two-step verification
Require a security key or code in addition to a password
Select all activities you prefer doing on a weekend
Which of these tools do you use the most?
My Role
In this initiative, I was responsible for:
Auditing existing designs and identifying inconsistencies.
Collaborating with designers and engineers to define a unified design language.
Creating and documenting foundational elements (colors, typography, spacing, etc.) and reusable components.
Educating and aligning teams on the design system to ensure adoption.
Iterating based on feedback and monitoring its usage to continuously improve the system.
I obviously had the support of amazing designers and engineers from Upraised in helping me move this initiative smoothly.
The Process
I followed a simple, step-by-step process to build the design system:
01
Auditing and researching to understand the current state
Created an interface inventory to gather existing design elements and make a note of the observed UI inconsistencies (e.g. 10 button variations, redundant colors, differences in input fields etc.)
Interviewed designers and engineers to understand pain points in their workflows.
02
Prioritisation after the audit
Once the audit was done, we split design system work into manageable parts:
Foundations: Colors, Typography, Layout, Brand, Iconography.
Component Library: Reusable UI elements (e.g. buttons, input fields).
Pattern Library: Reusable solutions for specific goals (e.g. onboarding flows, forms).
At Upraised, we worked in 2-week sprints. To track our design system progress, we created a tracker in ClickUp with the linked documentation as a single place for reference.
03
Execution
With the audit and research already done, we had an understanding of the problems.
I’ll take the example of how we fixed our colors. We were to fix the following problems:
Lack of semantic nomenclature.
No shades and tints for our brand colors.
Usage of different colors for the same purpose because of absence of a system.
Some colors did not pass accessibility guidelines set by WCAG.
We started off by generating shades and tints from our base colors. Manually checked the contrast ratios for each color to ensure adherence to WCAG. The Stark plugin was really helpful here.
After which we explored nomenclature and ended up creating definition and semantic tokens.
As soon as the library was set in figma, we published it for other designers to test the new colors.
We did a similar exercise for other elements and components. Foundations took the most amount of time as it was the backbone for everything in the system.
All of this would mean nothing if it was not implemented in code so we ensured that our developers are aligned with our nomenclature and are satisfied with each of the elements we are creating. Debates and disagreements were always welcomed in the process.
04
Feedback and Iteration
As design elements were created, we took feedback from designers and developers on how an element was doing in a bi-weekly call and captured it in ClickUp.
Impact
01
We got to consistent interfaces with defined standards
Most of us got used to designing using defined elements and components, which meant consistency across designers and it was easy to spot as Figma adds a purple border to whatever is a component.
Simply put, “If consistent interfaces are handed-off, consistent interfaces are developed”.
02
Increased Speed to Ship by ~50%
After adopting rising, it took us only 4 days to ship the Coach Landing Page. (3 days in design and 1 day in development) A landing page typically took us 8-10 days to ship earlier.
This meant success. I wish I tracked the time other kinds of tasks took before and after adopting rising but I really do not have that data with me.
03
Single source of truth was established with detailed documentation
Unified nomenclature (e.g., tokens for colors, typography roles) eliminated confusion between designers and developers. We documented everything on Click-up with a link to the documentation in the component file.
Learnings
What would be ideal? A life without problems but with problems would disappear learnings. That being said I didn’t have an ideal life with this project. Building rising taught me a lot about design systems, some of the things worked really well, others just prepared me for the next iteration.
01
Challenge with responsive typography
When we defined typography for rising, we had to create two separate styles for desktop and mobile breakpoints as Figma did not come up with variable modes just then. The challenge was using typography in components, should we be using mobile typography or desktop typography or create new typography definitions as components did not have a breakpoint associated with them. We ended up creating new styles which led to a lot of redundancy.
02
Naming things is hard
Really really hard. But if you find names that make sense and everyone in your team adopts, there’s nothing better than that. Be it naming colors, typography or names for tokens. This is the most effortful and the most rewarding part of the process. The color nomenclature that we set-up turned out to be truly scalable as we are still using it without having to change a thing.
03
Plugins are your best friends
There is so much of renaming, style creation and operations involved in a design system file that you can’t go without using plugins for specific use cases. Plugins like styler, color scale generator, token studio, stark etc. were very helpful. I used so many plugins that people from my team wanted to call me Pluginkya. 😂
04
Organising library files is more important than you think
Instead of making just one file for the entire design system, we separated our typography, colors, icons, layout and components into different files and toggled them on and off depending on the project, this approach helped us as we shipped design system in phases. Some projects just needed the new colors, some just needed the new typography. This approach shines when newer versions of an element are published and also keeps the file light-weight.
05
Porting from no design system to a design system is a bumpy ride
When we wanted to move to the new design system, planning the transition was a challenge. What happens to the old screens? Is there a state where the user sees an old screen and a new screen together in the same flow? A proper transition plan had to be made so that the end user’s experience did not get hampered.
06
Having a tool that supports your work is a blessing
Figma has been really pushing updates to help design system creators, with every update the work that we did became increasingly easier. When they introduced variables and color scoping followed by variable modes, I was really happy as it solved for the responsive typography problem that we faced earlier. Kudos to Figma for shipping so fast.
Figma has been really pushing updates to help design system creators, with every update the work that we did became increasingly easier. When they introduced variables and color scoping followed by variable modes, I was really happy as it solved for the responsive typography problem that we faced earlier. Kudos to Figma for shipping so fast.
07
Lack of usage metrics
I really wanted to find out how our components and styles were being used in order to look for improvement opportunities. How many components were detached and how many were not used at all. Unfortunately Figma only offered that capability in a specific plan which we did not have. Would have loved this for tracking adoption.
Conclusion
While building a design system from ground up was challenging and came with its own set of learnings, I’m proud of the progress we made as a team.
We still have a lot of new design elements to be added, the process we set up will definitely help us make the system more robust. And as I pointed out earlier, design system work never truly stops. It just keeps on ‘Rising’. (pun intended)
You’re amazing for making it all the way down here
You’re amazing for making it all the way down here
I’m currently writing about more projects as you read this, so stay tuned.
In the meantime, feel free to explore the rest of the website.