Oko • Senior Product Designer

Back

Building Amartha ‘Funds’ design systems

Design Systems are now common in leading companies due to large-scale, complex projects. Varying versions maintain design integrity and scalability across evolving products. This case study discusses the creation of a design system created by the Amartha design team.

Company

Amartha

Role

Product / Visual Designer

Scope

Design System, Design Governance, Quality Assurance

Period

April - Dec 2024

Background & Problems

Initially, our team had no design system in place and we relied on meetings, team syncs, and mini-style guides in order to maintain a cohesive UI and consistent UX patterns. While this is manageable in a small team and a relatively simple product, we quickly realized that this wouldn’t be sustainable as more parts of the Amartha product ecosystem were being merged into one mobile app.

Objectives

By creating an updated centralized design system, we aimed to:

Align our teams by giving them a more structured and guided way to build products.
Speed up our design and development process: with a ready-made library and patterns teams can create and test layouts much faster.
Improve brand perception and user trust through consistent experiences that work for everyone and allow users to accomplish their goals.
Promote accessibility of our products by building accessibility and inclusion into our component libraries, both from a design and code repository perspective.

While it was clear that this project would require a lot of resources, planning, and time commitments, we knew that this work was a justified long-term investment in our company, brand standards, and our customers.

By creating an updated centralized design system, we aimed to:

Align our teams by giving them a more structured and guided way to build products.
Speed up our design and development process: with a ready-made library and patterns teams can create and test layouts much faster.
Improve brand perception and user trust through consistent experiences that work for everyone and allow users to accomplish their goals.
Promote accessibility of our products by building accessibility and inclusion into our component libraries, both from a design and code repository perspective.

The Process

There is no ideal process for everyone, but we think this process is quite ideal for our design team. We started with outreach to the relevant teams, then started working on the project by assembling a team that was divided into a research team, design team, writing team, engineering team, and project manager.

Buy In

In order to ensure the success of this project, it was important to get stakeholders on board before we started building our design system.
We systematically promoted the initiative via:

A kick-off company-wide presentation where we shared the current pain points and the anticipated benefits of the project for the company as a whole.
Involving engineering into the conversation early on through bi-weekly design system meetings and workshops to collect their input.
Sharing with squads work in progress and the roadmap of the project.

By getting other teams involved from the onset and as the project evolved, we strived to promote understanding of the project and inspire a sense of co-ownership throughout the entire process.

In order to ensure the success of this project, it was important to get stakeholders on board before we started building our design system.
We systematically promoted the initiative via:

A kick-off company-wide presentation where we shared the current pain points and the anticipated benefits of the project for the company as a whole.
Involving engineering into the conversation early on through bi-weekly design system meetings and workshops to collect their input.
Sharing with squads work in progress and the roadmap of the project.

By getting other teams involved from the onset and as the project evolved, we strived to promote understanding of the project and inspire a sense of co-ownership throughout the entire process.

Development Phase

After completing the buy-in process, it's time to start developing a well-structured design system. To achieve this, we will proceed through four distinct phases:

Research

I researched competitors, target audiences, and industry trends to gain insights and identify improvement areas.

Review

Next, I reviewed the existing design to identify pain points and inconsistencies, understand the current product state.

Design

The initial research was vital in shaping Amartha's new brand and visual identity, guiding the overall design strategy in the rebranding and redesign project.

Documentation

This phase involves documenting all components, styles, and guidelines clearly and organized, including their purpose, usage, and examples for implementation.

2. Review

To better understand the current state of our existing design ecosystem, we started with a UI Inventory of our main interface components. We used Brad Frost’s interface inventory guideline as inspiration to conduct a full-day audit that we ran as a team of 5 designers. We split into three groups and assigned each a set of components to go over on our site and build an inventory around.

2.1 Create UI Inventory

The plan was to screenshot unique instances of our main design assets such as typography, buttons, icons, input forms, dropdowns, etc., and add them to our Figma Audit file we had prepared ahead of time. Then each group shared their findings with the team.

As a result of this exercise, we identified a lot of inconsistencies in our design assets and many variants of some existing products. These results prove the need for a more systematic approach to documenting, communicating, and maintaining our design systems.

The inventory process helped us clearly see all discrepancies and inconsistencies across our site and product. It served as a foundation for our design system work. With the audit results in mind, we created a priority list for our design system minimal viable product (MVP), and started assigning designers that would lead the exploration and documentation of each component.

2.2 List out components

After researching other system designs, I circled back to create a list of patterns and components we needed based on the research and labels we had in the audit file and compared them to other system designs. This gives us an idea of what needs to be reviewed, used, or just a name change, so we can track and plan the time accordingly.

I organized components into the following sections based on their functions — Buttons, Data Input, Data Display, Feedback, and Navigation. The list gets revised continuously and ticked off whenever we finish discussing a component.

3. Design

We decided to focus first on the foundational elements (atoms) of our design system, such as color palettes, typography, system grid, spacing, icons, etc., and then move on to more complex blocks and pieces (molecules, organisms, templates, pages). Some of the activities at this stage involved:

Researching other design systems and interfaces for components common practices and inspiration.
Analyzing the instances and use cases captured during the audit and ideating on the solutions that serve our goals best.
Unifying: we merged different variations of components to leave only the essentials. For example, we limited our color schemes to a maximum of 9 shades for each hue, and all the excessive variations were matched and merged with the decided upon schemes based on proximity. Below is our final color palette:

Researching other design systems and interfaces for components common practices and inspiration.
Analyzing the instances and use cases captured during the audit and ideating on the solutions that serve our goals best.
Unifying: we merged different variations of components to leave only the essentials. For example, we limited our color schemes to a maximum of 9 shades for each hue, and all the excessive variations were matched and merged with the decided upon schemes based on proximity. Below is our final color palette:

3.1 Building Foundations

Because the app was constantly evolving, our secondary criteria for the design system was to create a flexible architecture that could adapt to future changes easily and seamlessly. Together with the lead developer, we defined a generic structure upon which we would build the system - essentially breaking down all elements into their most atomic form. Most importantly, the most common elements like typography styles, colors, inputs, and buttons would be detached from any specific context.

For example, we defined our typography styles with generic names instead of specific ones (i.e. “title” instead of “card-title”).

This decision proved to be key to the success of our design system. Utilizing this centralized method of control makes communication between devs and designers much simpler and most importantly enables us to make cross-app changes very easily.

Similarly, our color palette was broken down into system colors spread across several tints. This proved to be flexible enough for use but also scalable if needed for future expandability.If we ever want to change the main color of the app, we could do it in one place and instantly change it across all components. Besides the system colors, we automatically generate these tints for any color chosen by our user - allowing for true customization while still staying within the design system’s logic.

3.2 Atomic Design

Based on Brad Frost’s Atomic Design, good design systems are style guides, which document and organize design materials while providing guidelines, usage, and guardrails. It includes brand identity, writing, voice and tone, code, design language, and user interface patterns.

With a good design system, you can reuse all the design components in your product development process. It will reduce your product's time-to-market. You don’t have to focus on building the details of the design components. You can be more focused on user requirements, product testing, market validation, and other business-related things. When there’s an issue with the design components, you can quickly fix the source and all the pages that using the components will get the fixing patch.

3.3 Applying properties and variables

Component properties and variables in Figma allow designers to create reusable and customizable components. By defining properties and variables for components, designers can easily make changes to multiple instances of a component simultaneously, ensuring consistency across the design. This is particularly useful for maintaining design systems, as it allows for quick and efficient updates to components without the need to manually edit each instance.

Additionally, properties and variables make it easier to collaborate with team members, as they provide a clear and standardized way to define and update component styles and behaviors.