A Figma publication for design systems creators, designers, developers, and managers
Article

Building ChimeKit with Atomic Design and a collaborative process

Authors
Aoni Wang
Aoni Wang

UI/UX designer creating meaningful and engaging experiences for Chime.

Hass Lunsford
Hass Lunsford
A decade of designing mobile experiences in Silicon Valley/San Francisco, working with small to mid-size teams on highly-rated mobile apps in a variety of consumer spaces.

Chime celebrated a lot of milestones this year - 7 years old, 5M accounts opened, over 100 million dollars spotted to members. The company is growing and scaling, and as a design team, we've spent a lot of time working on how we grow and scale alongside the company. One of the biggest tools that can help a product development org scale is a design and development system. This wasn't something we had historically invested in. The team had a sticker sheet in Sketch, like so many other companies, but that sticker sheet wasn't a system. It wasn't serving anyone beyond the design team. This year, we invested in building ChimeKit, our design and development system.

There are many benefits to a joint design and development system. Not only does it bring benefits to the design team, but it also brings benefits to engineering teams. It makes sure that our experiences have a consistent look and feel, not just in our design specs, but in production. It helps unite all teams across the company around common components and a common language. It helps make sure we're all spending time in the right place - standardizing reusable components and clearly defining behaviors means that both designers and engineers are spending less time debating the look and feel of each screen, and more time focusing on the problems that are so acute to our members.

As we continue to build and implement ChimeKit, here are some takeaways I’d love to share:

1. Treat it like a product

From the very beginning, we decided to treat ChimeKit as a product, not a project. This is because a design and development system is not a temporary endeavor. It is a continuous effort and should adapt to meet the needs of designers, developers, and end-users, Chime members. There is no clear deadline when it is done. In fact, a design and development system is never “done”.

Like any other product, we organized a cross-functional team for ChimeKit. Hass is the lead of ChimeKit, setting up the team and the process. Every designer is an owner of ChimeKit by owning different components. Dennis is the product champion for ChimeKit. He is responsible for getting resources and advocating for our continued investment in the system. Also, as any design team can be guilty of getting too "designery" about things or getting carried away with rules, Dennis keeps us grounded and makes sure that we're keeping an eye on the practical, too. Lucy, Diego, and Jessica are the dev owners of ChimeKit. As the developers for our iOSs and Android app, respectively, they own the app interfaces and work closely with the designers on ChimeKit implementation.

ChimeKit team

In addition to a cross-functional team, ChimeKit has stakeholders across our company, such as the research team, the marketing team, etc.

Not everyone needed to be working on ChimeKit full-time, given the size of our teams. However, with the team and roles, we were able to assign designer owners and dev owners, and implemented processes and rituals to maintain and publish ChimeKit.

2. Implement processes and rituals

For ChimeKit 1.0, we wanted to lay the groundwork for future versions and get all existing experiences properly documented. For this reason, we started by componentizing all existing app patterns using the atomic design approach.

We started by defining a grid, including different spacing units.

chimekit-grid

At the same time, we audited all the font styles and colors and other atom-level components in the app and standardized those components in Figma. For example, we standardized and documented our shadows. The drop shadow was coded differently on iOS than on Android so we made sure to put that in the specs, even though Figma has a code view. To make the upward shadow consistent across all platforms, we worked with devs to use a gradient as a workaround.

Standard shadows

With the atomic design approach, we continued to standardize the organization of atomic components into screen templates, and finally pages. Below is an example of how we componentized the educational screen template. The educational screen template turned out to be one of the most commonly used screen templates in the Chime app.

ChimeKit atomic design

For collaboration and progress, we set up, and continue to use, a JIRA board.

In the beginning, we listed out all the components in the “On Deck” column and assigned design owners in the JIRA ticket. Things that were paused in process, or planned for the future, went into the "Backlog".

JIRA-Start

Once we made a list of items, we started to move them forward step by step. This is the process we continue to use today. Each item, once created and defined in the Figma file, is moved into "Design System Review". We also propose new components or iterations on existing components by adding tickets under “Design System Review”.

JIRA-DSR

We started a ritual where every Monday, the design team reviews the items in the "Design System Review" category. Together as a team, we decide if the component is ready to be considered "standard", or if it needs more iteration. The items that get the team's blessing move onto “Component Review”.

JIRA-CR

Every Friday, the ChimeKit council (design owners, PM, and dev owners) reviews all the items under “Component Review” to decide if the component is ready to add to the code library. If everything goes well, a ticket (representing a component) will move from left to right on the JIRA board to finally get published in the app.

JIRA-Done

When deciding if a ticket (component) can move to the next column, we ask ourselves:

Is it following the basic guideline?

Is the component following the rules of the type ramp, the rules of color usage, as well as the spacing unit? If there’s an exception, is there a strong case for the exception?

Are the use cases and different states clearly defined?

For example, a list item - what are the use cases for a list item, is it always actionable or unactionable? How many lines of text can it fit? Is there a disabled state and what should the universal disabled treatment be?

Is the component flexible or scalable?

If there’s a banner component, what kind of content does it contain now? What other content can it hold in the future and is there a general rule around that?

3. Evolve

Like we talked about in the beginning, ChimeKit is never done. Like any good product or experience, it continues to evolve over time. In just the short time since we built ChimeKit 1.0, we've already evolved to versions 1.1 and 1.2. The biggest changes were our type ramp and colors. Once those were componentized in both Figma and code, it was easy for us to transition from Source Sans to Circular, and from inaccessible colors to accessible ones. All of the mocks changed with just a few taps, and the Chime app changes with just a few new lines of code.

Chimekit alleviates the pains of modern product development by offering a design and development system that takes care of the mundane stuff. By systematizing frontend engineering, and freeing our team to focus on the harder (funner) problems, we can be more productive at building high-quality experiences for Chime members.

SpotMe iterations

Design + Development

Design + Development

Exploring collaborations in code
Aoni Wang, Hass Lunsford

Building ChimeKit with Atomic Design and a collaborative process

Like any good product or experience, design systems continue to evolve over time. ChimeKit takes care of the mundane parts of building a design system so that designers & developers can spend more time building high-quality experiences

Ryan Seddon

React containers, some assembly required

Introducing react-containers: a new open source library to help elevate no-UI containers, with a focus on accessibility, brought to you by the Zendesk Design Systems team.

John Choura

Stack mirroring: Designing for code and coding for design

What modern design systems can learn by taking direction from how programming already functions.

Read all articles

Ready to Contribute?

The team at designsystems.com is always looking for interesting content. Share your ideas with us — we’d love to hear from you.

Subscribe for Updates

We will be rolling out new articles and guides on a regular basis. Sign up to get the latest delivered to you.

Design Systems

version 2.0.0