Design system

Avengers Design System 1.0

In our daily work, the design team often faces a problem where we don't have a main reference for components to rely on. This causes designers to have to communicate about each and every component on how to build them, which creates more tasks and more time spent. That is why we are trying to revamp the design system.

In our daily work, the design team often faces a problem where we don't have a main reference for components to rely on. This causes designers to have to communicate about each and every component on how to build them, which creates more tasks and more time spent. That is why we are trying to revamp the design system.

Overview

My Role

Explored competitor research, benchmarking other design systems to inform our structure and approach.
Defined token architecture and naming conventions for colors
Built 10+ main components in Figma, covering anatomy, variants, and states.
Wrote usage guidelines and documentation for each component.
Supported developer handoff, helping the team understand how to implement components without hardcoding.

Explored competitor research, benchmarking other design systems to inform our structure and approach.
Defined token architecture and naming conventions for colors
Built 10+ main components in Figma, covering anatomy, variants, and states.
Wrote usage guidelines and documentation for each component.
Supported developer handoff, helping the team understand how to implement components without hardcoding.

Timeline

Feb - April 2025

Team

Asama P.
Thongthod K.
Rawisara L.

Asama P.
Thongthod K.
Rawisara L.

UX/UI Lead
UX/UI Designer
UI Associate (Me)

Tools

Figma, Figjam

Before & After

Before

Without a design system, every new feature started from zero. Designers had no shared reference to rely on, so each screen was built from scratch with different patterns, colors, and components, even for the same UI element. For developers, translating these designs into code meant constant back-and-forth, taking more time for every team.

Without a design system, every new feature started from zero. Designers had no shared reference to rely on, so each screen was built from scratch with different patterns, colors, and components, even for the same UI element. For developers, translating these designs into code meant constant back-and-forth, taking more time for every team.

After

With a shared token and component library in place, the team finally had a foundation to build on. Designers could pick up any new feature with confidence. Development became faster because components were already defined and consistent across the board. And when the brand needed to evolve or a component needed updating, one change in the system cascaded everywhere automatically, no more manual fixes screen by screen.

With a shared token and component library in place, the team finally had a foundation to build on. Designers could pick up any new feature with confidence. Development became faster because components were already defined and consistent across the board. And when the brand needed to evolve or a component needed updating, one change in the system cascaded everywhere automatically, no more manual fixes screen by screen.

Impact

When design is consistent, everyone benefits. Developers ship faster with reusable components, product and QA move with better alignment, and the business benefits from a consistent product. Most importantly, end users get an experience that feels coherent and predictable, making Salary Hero easier to navigate and trust.

When design is consistent, everyone benefits. Developers ship faster with reusable components, product and QA move with better alignment, and the business benefits from a consistent product. Most importantly, end users get an experience that feels coherent and predictable, making Salary Hero easier to navigate and trust.

Developers

Developers 😎

😎

Faster development
Consistency in code
Less communication overhead

Faster development
Consistency in code
Less communication overhead

Product

Product 👩‍💼

👩‍💼

Better alignment across features
Improved decision making
Faster time to market

Better alignment across features
Improved decision making
Faster time to market

QA Teams

QA Teams 🕵️‍♂️

🕵️‍♂️

Fewer bugs
Consistent testing criteria

Fewer bugs
Consistent testing criteria

Branding

Branding 🏢

🏢

Brand consistency
Faster campaign execution

Brand consistency
Faster campaign execution

Business

Business 💼

💼

Cost efficiency
Scalability as the product grows
Stronger brand recognition

Cost efficiency
Scalability as the product grows
Stronger brand recognition

End Users

End Users 👤

👤

Consistent experience
More intuitive and predictable interactions

Consistent experience
More intuitive and predictable interactions

Design Process

Why we built

While working on the product, we kept running into the same problem. There was no shared standard for designers to work from, which meant we constantly had to check in with each other just to make sure our designs were aligned. Small decisions like which color to use, what spacing to apply, or how a button should look were being made differently by different people on the team.

The more we dug into it, the more we realized this wasn't just a designer problem. Developers had to interpret inconsistent designs and fill in the gaps on their own. QA had no clear baseline to test against. New team members took longer to get up to speed because there was nothing to reference. The lack of a shared system was creating friction across the entire team, and we knew a design system was the right way to fix it.

While working on the product, we kept running into the same problem. There was no shared standard for designers to work from, which meant we constantly had to check in with each other just to make sure our designs were aligned. Small decisions like which color to use, what spacing to apply, or how a button should look were being made differently by different people on the team.

The more we dug into it, the more we realized this wasn't just a designer problem. Developers had to interpret inconsistent designs and fill in the gaps on their own. QA had no clear baseline to test against. New team members took longer to get up to speed because there was nothing to reference. The lack of a shared system was creating friction across the entire team, and we knew a design system was the right way to fix it.

Consistency  and Governance

Consistency  and Governance 🕴️

🕴️

Ensures uniformity across all products with standardized design components and clear governance rules.

Faster
Onboarding

Faster
Onboarding 🧑‍💻️

Faster Onboarding 🧑‍💻️

🧑‍💻️

New team members quickly understand design principles, components, and coding standards by referencing the system.

Improved Collaboration

Improved Collaboration 👬👬

👬👬

Smoother communication when everyone refers to the same components and guidelines.

Easier Maintenance  
& Updates

Easier Maintenance  
& Updates 🚧

🚧

Update components systematically without missing details or creating inconsistencies.

Efficiency in Design
& Development

Efficiency in Design
& Development 📱

📱

Reusable pre-built components speed up the process and reduce bugs and misalignments.

Planing

The project ran from February to May. We spent the first month planning and researching the right approach, then moved into building tokens and components in March. On 25th April we published the first version, and May was dedicated to working with developers on integrating the system into production.

The project ran from February to May. We spent the first month planning and researching the right approach, then moved into building tokens and components in March. On 25th April we published the first version, and May was dedicated to working with developers on integrating the system into production.

Exploration

Before jumping into building, we took time to explore what the best approach to a design system would look like for Salary Hero. That's when we discovered atomic design, a methodology that structures everything from the smallest elements like colors and typography, all the way up to full page templates. It gave us a clear mental model for how to build in a way that's consistent and scalable.

We also looked outward, studying some of the most well-regarded design systems in the industry to understand what good actually looks like in practice. Uber's Base and LINE stood out as strong references.

Before jumping into building, we took time to explore what the best approach to a design system would look like for Salary Hero. That's when we discovered atomic design, a methodology that structures everything from the smallest elements like colors and typography, all the way up to full page templates. It gave us a clear mental model for how to build in a way that's consistent and scalable.

We also looked outward, studying some of the most well-regarded design systems in the industry to understand what good actually looks like in practice. Uber's Base and LINE stood out as strong references.

From Uber's Base system

Uber gave us a strong foundation to reference. Their atoms-to-templates hierarchy confirmed we were structuring things the right way. We adopted their approach to token naming : clear and scalable and used their component documentation style as the benchmark for our own, covering anatomy, variants, states, and specs in one place.

Uber gave us a strong foundation to reference. Their atoms-to-templates hierarchy confirmed we were structuring things the right way. We adopted their approach to token naming : clear and scalable and used their component documentation style as the benchmark for our own, covering anatomy, variants, states, and specs in one place.

From LINE

LINE reinforced our color token decisions. Seeing how they organized colors into primary, secondary, and semantic layers gave us confidence in our own structure. It also echoed what we'd already taken from Uber, which told us we were heading in the right direction.

LINE reinforced our color token decisions. Seeing how they organized colors into primary, secondary, and semantic layers gave us confidence in our own structure. It also echoed what we'd already taken from Uber, which told us we were heading in the right direction.

Solution

Atomic Design

Atomic design gave us a clear, logical structure to build from, starting with the smallest building blocks and scaling up layer by layer into full page templates. Rather than designing screens in isolation, we could now build a system where every decision connects back to a shared foundation.

We structured the system into four layers.

After exploring different approaches, atomic design stood out as the right methodology for Salary Hero. It gave us a clear, logical structure to build from, starting with the smallest building blocks and scaling up layer by layer into full page templates. Rather than designing screens in isolation, we could now build a system where every decision connects back to a shared foundation.

We structured the system into four layers.

Atoms

The smallest building blocks of the system. Foundational values like colors, typography, spacing, shadows, and icons, all defined as tokens so they can be reused and updated consistently across the entire product.

The smallest building blocks of the system. Foundational values like colors, typography, spacing, shadows, and icons, all defined as tokens so they can be reused and updated consistently across the entire product.

Components

Functional UI pieces built by combining atoms. A text field, a button, a dropdown. Each component is documented with its anatomy, variants, states, and specs so designers and developers are always working from the same definition.

Functional UI pieces built by combining atoms. A text field, a button, a dropdown. Each component is documented with its anatomy, variants, states, and specs so designers and developers are always working from the same definition.

Patterns

Reusable combinations of components that solve common user flows. The employee login screen below is a good example, two input fields and a button working together as a single repeatable pattern, removing the need to redesign the same flow from scratch every time.

Reusable combinations of components that solve common user flows. The employee login screen below is a good example, two input fields and a button working together as a single repeatable pattern, removing the need to redesign the same flow from scratch every time.

Templates

The outermost layer, where patterns and components come together into full page structures. Templates define the layout and hierarchy of each screen, ensuring every part of the Salary Hero app feels like it belongs to the same product.

The outermost layer, where patterns and components come together into full page structures. Templates define the layout and hierarchy of each screen, ensuring every part of the Salary Hero app feels like it belongs to the same product.

Tokenization

Atomic design gave us the structure, but tokens are what make it truly scalable. Every visual value, from colors and spacing to typography and border radius, is defined once and referenced everywhere. We are able to update a single token and it cascades across the entire product automatically.

Atomic design gave us the structure, but tokens are what make it truly scalable. Every visual value, from colors and spacing to typography and border radius, is defined once and referenced everywhere. We are able to update a single token and it cascades across the entire product automatically.

Colors

Every color in the product is defined as a token with a specific hex code, organized into primary, secondary, and semantic layers. Updating a color token automatically updates it across every component and screen that uses it.

Every color in the product is defined as a token with a specific hex code, organized into primary, secondary, and semantic layers. Updating a color token automatically updates it across every component and screen that uses it.

Typography

Text sizes are defined on a consistent scale so nothing feels inconsistent. Each token maps to a specific use case, from display headings down to captions, keeping the hierarchy clear and readable across the app.

Text sizes are defined on a consistent scale so nothing feels inconsistent. Each token maps to a specific use case, from display headings down to captions, keeping the hierarchy clear and readable across the app.

Spacing and sizing

We used a 4-point grid system as the foundation for all spacing and component sizing. Every margin, padding, and element size is a multiple of 4, which keeps layouts consistent and makes it easier for developers to implement without guessing.

We used a 4-point grid system as the foundation for all spacing and component sizing. Every margin, padding, and element size is a multiple of 4, which keeps layouts consistent and makes it easier for developers to implement without guessing.

Copywriting

We documented all UI copy as part of the system. Every label, button text, error message, and placeholder is recorded in one place. This makes it easy to maintain consistent tone across the product and straightforward to switch between languages when needed.

We documented all UI copy as part of the system. Every label, button text, error message, and placeholder is recorded in one place. This makes it easy to maintain consistent tone across the product and straightforward to switch between languages when needed.

Guideline

We wrote detailed guidelines covering component anatomy, usage rules, tokenization standards, date and number formatting, and a copywriting guide with a shared glossary. Everything a designer or developer needs to work with the system independently, without having to ask.

As we built each component, the team discussed the use cases together to make sure everyone understood not just how it looks but when and why to use it. For developers coming into the Figma file, the guidelines serve as a clear reference so nothing gets lost in translation.

We wrote detailed guidelines covering component anatomy, usage rules, tokenization standards, date and number formatting, and a copywriting guide with a shared glossary. Everything a designer or developer needs to work with the system independently, without having to ask.

As we built each component, the team discussed the use cases together to make sure everyone understood not just how it looks but when and why to use it. For developers coming into the Figma file, the guidelines serve as a clear reference so nothing gets lost in translation.

Results

Atoms

These are the atoms we built as the foundation of the system. Typography, colors, icons, spacing, shadows, image ratios, and logo usage. Getting these right first meant everything built on top would naturally stay consistent.

These are the atoms we built as the foundation of the system. Typography, colors, icons, spacing, shadows, image ratios, and logo usage. Getting these right first meant everything built on top would naturally stay consistent.

Components

These are the components we built on top of the atom foundation. Buttons, dropdowns, input fields, navigation, badges, tables, toast notifications, and more. The more complex ones come with detailed guidelines covering anatomy, variants, and usage rules. Still growing.

These are the components we built on top of the atom foundation. Buttons, dropdowns, input fields, navigation, badges, tables, toast notifications, and more. The more complex ones come with detailed guidelines covering anatomy, variants, and usage rules. Still growing.

Patterns & Templates

Patterns and templates are where everything comes together. Some patterns we kept in the working product files since that is where we actually build the features. For templates we made a separate page so it is easy to find and reference when we need it. Every screen here is built from the same components and tokens underneath.

Patterns and templates are where everything comes together. Some patterns we kept in the working product files since that is where we actually build the features. For templates we made a separate page so it is easy to find and reference when we need it. Every screen here is built from the same components and tokens underneath.

Hand-off & Implementation

To keep everyone in the loop, we announce design system updates on the 25th of every month. The announcement covers what changed, what is new, and anything the team needs to know before using the latest version.

We also set up a clear update process. The design team makes the changes, stakeholders including the design lead, product manager, and frontend lead sign off, and then we publish the updated library and post in the group chat. If needed, we also present the new designs to other stakeholders before publishing.

So far we have built 702 components in total and more are on the way.

To keep everyone in the loop, we announce design system updates on the 25th of every month. The announcement covers what changed, what is new, and anything the team needs to know before using the latest version.

We also set up a clear update process. The design team makes the changes, stakeholders including the design lead, product manager, and frontend lead sign off, and then we publish the updated library and post in the group chat. If needed, we also present the new designs to other stakeholders before publishing.

So far we have built 702 components in total and more are on the way.

Reflections

This was one of my very first projects after moving from the admin team into the product design team. Honestly I had no idea what anyone was talking about at the start. Design systems, tokens, atomic design, it was all new to me. Figma was also still new to me at the time, so I was learning everything on the job, from how variables and tokenization work, to building nested components, setting up auto layout, and working with the 4 point grid system. Looking back this project taught me more about design and Figma than anything else. It is where I really started to grow as a designer.

This was one of my very first projects after moving from the admin team into the product design team. Honestly I had no idea what anyone was talking about at the start. Design systems, tokens, atomic design, it was all new to me. Figma was also still new to me at the time, so I was learning everything on the job, from how variables and tokenization work, to building nested components, setting up auto layout, and working with the 4 point grid system. Looking back this project taught me more about design and Figma than anything else. It is where I really started to grow as a designer.

Learning

Looking back now there are things I wish we had done differently. These are the lessons that stuck with me the most.

Prioritize one platform first

Building mobile and console at the same time was too ambitious. Starting with one platform would have made adoption much more realistic.

Involve developers early

We should have talked to developers before we started building. Understanding the technical constraints earlier would have saved a lot of time.

Focus on quick wins

Prioritizing the most used or most painful components first would have built momentum and shown the value of the system much sooner.

What's next

When the project resumes, the plan is to tackle console components as the next phase, starting with the highest-impact pieces rather than trying to cover everything at once.

Focus on console components

The mobile side is more established so the next priority is bringing the same consistency to the console. This means building and documenting components that work within the console's existing setup including its dependency on Ant Design.

The mobile side is more established so the next priority is bringing the same consistency to the console. This means building and documenting components that work within the console's existing setup including its dependency on Ant Design.

Make sure components are actually being used

We want to set up regular check ins with the developer team to make sure they are using the components we built rather than hardcoding their own solutions. We also want to agree on a clear timeline together for when and how each component will be implemented in production, so adoption happens in a structured way instead of being left open ended.

We want to set up regular check ins with the developer team to make sure they are using the components we built rather than hardcoding their own solutions. We also want to agree on a clear timeline together for when and how each component will be implemented in production, so adoption happens in a structured way instead of being left open ended.

Keep maintaining and updating the system as the product grows

A design system is never really finished. As Salary Hero adds new features and evolves, the system needs to grow with it. This means regular updates, clear announcements, and making sure the team always has something reliable to build from.

A design system is never really finished. As Salary Hero adds new features and evolves, the system needs to grow with it. This means regular updates, clear announcements, and making sure the team always has something reliable to build from.

Design system

Avengers Design System 1.0