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.

1. Research

Following a series of interviews with individuals from various departments such as front-end developers, product managers, and marketing managers, we have recognized the need to accomplish two primary objectives:

01 Solving Design Challenges

Identify and address all the design-related challenges present in our product.

02 Mastering the Principles

Learn the common standards and principles of a successful design system.

1.1 Benchmark

We had to find open-source design systems that share common design principles with FunDS. We picked these 3 as a result:

Material Design 3 by Google (has good documentation)
Atlassian Design System by Atlassian (responsive design and has a good foundation)
Polaris Design System by Shopify (good design craft & micro interaction)

We had to find open-source design systems that share common design principles with FunDS. We picked these 3 as a result:

Material Design 3 by Google (has good documentation)
Atlassian Design System by Atlassian (responsive design and has a good foundation)
Polaris Design System by Shopify (good design craft & micro interaction)

Material Design 3

Atlassian Design System

Polaris Design System

Through this process, I gained valuable insights into the construction of design systems at these three companies, understanding their foundational elements and how they optimized their design systems performance. These findings allow my team and me to adopt best practices and work towards achieving our targets.

1.2 User Research

After getting an idea of the design system that will be created, we conducted user research to get the latest insight into the current condition of our product, as well as looking for other findings that could strengthen Amartha's branding and design principles.

Key findings:

The UI of the app was a bit outdated and needed a revamp.

Accessibility of colors and some components needs to be improved.
Strengthening the brand by creating a new design concept that’s more suitable to users.

The UI of the app was a bit outdated and needed a revamp.

Accessibility of colors and some components needs to be improved.
Strengthening the brand by creating a new design concept that’s more suitable to users.

1.3 Set a Timeline

Next, we created a weekly timeline outlining what needed to be done and by whom. This kept stakeholders and everyone involved in the design system updated on progress and facilitated resource allocation. We prioritized discussing the most commonly used components based on use cases in Asana. We addressed foundational patterns like Typography, Colors, and Layout first, as subsequent components would build upon them.

FunDS Project Timeline

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.

Amartha UI Design Inventory

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.

Inventory of Uploader components

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.

Component list

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.

Component planning

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”).

FunDS Typography

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.

FunDS Colors

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.

FunDS Iconography

Atomic Implementation

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.

Component properties & Variables

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.

Applying properties to the FundS button

Documentation

Documentation

High-quality component documentation is crucial to an effective library, allowing everyone to quickly and efficiently make consistent decisions. We wanted to create detailed documentation that would support every single aspect of our design system, and also be organized, consistent, and easy to use. We referred to several design systems, such as IBM’s Carbon, Material Design 3, Atlassian, Polaris Shopify, and other design systems for some good practices, guidelines, and tools that we could apply in our design system.

Google's Material Design 3

4.1 Design-led Documentation

In this process, documentation is created by considering needs and design perspectives. This means that documentation doesn't just focus on technical or functional details, but also pays attention to aesthetics, user experience, and design principles that are consistent with the company's visual identity and design values. With this approach, documentation becomes not only a functional reference, but also a powerful communication tool to strengthen the Amartha brand and product design quality.

At a high level, most of our component documentation usually includes:

Introduction with component description
Component usage
Component behaviour
Accessibility guidelines
Best practices
Component spesifications
Examples of components in different contexts to demonstrate how design patterns would be applied in real products and specific use cases

At a high level, most of our component documentation usually includes:

Introduction with component description
Component usage
Component behaviour
Accessibility guidelines
Best practices
Component spesifications
Examples of components in different contexts to demonstrate how design patterns would be applied in real products and specific use cases

FunDS component documentation - Ticker

4.2 Storybook Components Repository

Storybook has become The DevOps tool for developing and maintaining design systems. The platform's excellent documentation, intuitive UI, built-in testing, and collaborative features make it the perfect tool for building and releasing components. Understanding how Storybook works can help designers collaborate with front-end devs better and leverage the platform’s features to improve prototyping and testing.

However, this is our long-term target, once everything is settled we'll start using Storybook between Q3-Q4 2024.

4.3 Tracking Progress

To track and communicate the progress of the different steps, we created a Jira board that can be viewed and updated both by design and development. We create tickets for specific components that link out to all the relevant documentation and move them to corresponding status columns (In Design, Needs Feedback, In Development, etc.) throughout the process.

Apart from that, we also track component creation and development in a simple table on Google Spreadsheets. By modifying the table in this article, we redesigned the tracker according to our team's needs.

Funds Design System Tracker

Implement design system

The first step that needs to be taken in the implementation process is outreach to the team of engineers and other stakeholders regarding the latest state of this system design. Then engineers can start developing each component in order based on the component's priority. We prioritize components that are on pages that are rarely visited by users, so as not to interfere with their activities when using our apps.

Collaboration Tool

The collaboration tool we used to implement the design system is Figma Dev Mode. This feature is designed to help developers accelerate the UI implementation by generating code snippets. When you activate the dev mode, you can simply hover and click objects to get details like measurements, specs, and styles, all within a safe space that won’t impact the design file.

Thanks Figma for this feature ✨

After the development process by engineers, in parallel, we also socialize it with other designers so that they can use the new components in the design system library. We also hold weekly sessions to replace new components so that the app merger process becomes faster.

FunDS - Avatar components

Examples of component usage

Below are several examples of the use of new design components that have been created

Avatar

Avatar component to provide a visual representation of users across the application.

Tabs Menu

Tabs typically consist of a set of clickable elements (often text or icons) that represent each section of content.

List

A list is typically composed of multiple items, each represented by a text label, icon, or other visual element.

Progress Indicator

A progress indicator is often displayed as a horizontal bar or a series of circles, each representing a step or milestone.

What's the impact?

For designers

It has become a lot easier to create, share, and synchronize quite an extensive set of components at a much faster rate. Also, going forward it will eventually help us in easy knowledge transfer to the new team members.

For developers

The component library they created based on the UIkit helped them maintain the sanity of code and consistency in the final product.

For company

We achieved the goal of making all the businesses look consistent across platforms.

Tracking Adoption and Satisfaction with the module

After the design system release for design teams, we socialize them to use the component library for their ongoing and next project. Also, for read all the component guidelines. While doing that, we also measure these metrics in the first 3 months after the introduction.

And the results are:

±80%

Adoption Rate

Around 80% of the existing apps have already been recreated using the new component. While the new project always uses this new component.

4.82 Satisfaction Score

The new design systems achieves a 4.82 out of 5 for ease and satisfaction scores from all designers and developers who use it.

The Future

The design system is an ongoing project. We iterate, change, and learn a lot in the process. So far, we have a set of basic components ready, which has been game-changing for our team in terms of efficiency, as well as consistency, and standardization.

Some of our team’s next steps include:

Continuing to grow our component library and supplement it with more complex components.
Adding sections on brand, illustrations, and animation.
Cultivating processes and best practices for maintaining the documentation to ensure that our library stays up to date-and perfectly in sync both on the design and code side.
Raising awareness across the teams and promoting adoption and contribution to the documentation.
Building processes for testing the components on compliance with guidelines and accessibility standards.

Some of our team’s next steps include:

Continuing to grow our component library and supplement it with more complex components.
Adding sections on brand, illustrations, and animation.
Cultivating processes and best practices for maintaining the documentation to ensure that our library stays up to date-and perfectly in sync both on the design and code side.
Raising awareness across the teams and promoting adoption and contribution to the documentation.
Building processes for testing the components on compliance with guidelines and accessibility standards.

💪🏻

Special thanks to Mas Angga (design lead), Mas Edwin (PM), Denny & Mas Nino (Eng lead), and the rest of the design team for your valuable contributions and support! :)

[

02 /

02 ]

FOOTER

[

02 /

02 ]

FOOTER

Thanks for

stopping by!

Feel free to reach out for collaboration

purposes or just a friendly hello 👋🏻

sasongkobr@gmail.com

Get in touch

Instagram

X/Twitter

Dribbble

Made with ♥ in Framer

Thanks for

stopping by!

Feel free to reach out for collaboration

purposes or just a friendly hello 👋🏻

sasongkobr@gmail.com

Get in touch

Instagram

X/Twitter

Dribbble

Made with ♥ in Framer

Thanks for stopping by!

Feel free to reach out for collaboration

purposes or just a friendly hello 👋🏻

sasongkobr@gmail.com

Get in touch

Instagram

X/Twitter

Dribbble

Made with ♥ in Framer

Thanks for stopping by!

Feel free to reach out for collaboration

purposes or just a friendly hello 👋🏻

sasongkobr@gmail.com

Get in touch

Made with ♥ in Framer

Instagram

X/Twitter

Dribbble

Thanks for

stopping by!

Feel free to reach out for collaboration purposes or just a friendly hello 👋🏻

Copy email

Get in touch

Instagram

X/Twitter

Dribbble

Made with ♥ in Framer