In a perfect product development scenario, a designer could sketch some boxes on a napkin and hand it to an engineer who would know exactly what to build. The boxes would correspond to elements in an established design system that codified things like color, typography and structural components.
A design system ensures that everyone working on a product has a reference point for all of the features in the project. It allows teams to build and ship features faster.
When the NYT Cooking team started preparations to build an Android app in April 2019, we didn’t have a design system. At the time, our design team was made up of two designers and a design manager, which meant we often juggled a lot of work. As the sole designer on the Android project, I knew that it was the perfect opportunity to create a design system that the NYT Cooking Android team could use. These are some of the steps I took.
Getting Started
Because I had created design systems before, I knew it would be a process of trial and error. It’s normal to not know whether design elements included at the beginning of the process will still be there when the system is finished. To introduce some clarity, I defined loose guidelines, which anchored my decisions down the line.
Design principles. The team wanted to ensure that the app felt native to the Android ecosystem, which meant we would utilize native Android design patterns and paradigms. We decided to use Google’s Material Design framework as a foundation for the UI elements, while making sure that we upheld the NYT Cooking brand through styling and typography.
System users and software. The design system users were members of the design and engineering teams: designers would actively contribute to the system and engineers would reference the system. We used Figma because of its powerful Team Library feature and its ease of use for engineers.
Establish Format
A living design system document is the place where designers actively contribute to and update the system; it’s the most frequently updated document. A design system reference is a polished document that explains the system in detail, which is most useful for non-designers. Brad Frost describes the living document as the designer’s workshop and the reference as the shopfront. To streamline the workflow for future team members, I decided that the format of the design system documentation would be simultaneously a living document and a reference.
Styles, Components and Atomic Design
The two most important features in Figma for a design system are Styles and Components. Styles are basic elements such as color and typography. Components are more complex elements, such as buttons or navigation bars; I like to think of components as templates.
Metaphorically, a Style is an atom and a Component is a molecule. When combined, they become templates and pages, according to the atomic design structure laid out by Brad Frost.
Atomic design is the ideal way to structure a design system because it anticipates change. If we decided to change our brand color or the font size of a headline, we would update it in one location and it would be implemented throughout the entire system. This reduces the amount of time needed to make a style or design change and ensures the change is reliably applied in every design.
Define Styles
I had the benefit of our existing suite of products, so I audited our iOS app and website to decide what design elements to keep.
Audit
Our recipe pages are the most visited pages in our entire app, so the NYT Cooking product manager, design director and I decided to tackle this view first. Any recipe view — even a recipe in a book — is almost all typography, so the two things I needed to define first were the spacing system and typography.
Spacing
Since I was leaning on the Material Design framework, I decided to use their recommended spacing system. We use increments of eight, and occasionally use increments of four, for spacing, as Material Design suggests.
Typography
Recipes have many types of information, so to distinguish each part of a recipe and establish a clear hierarchy, I chose a succinct number of weights and styles from NYT Cooking’s three typefaces: Cheltenham, Karnak and Franklin Gothic. Recipe views were the most challenging to design, but once the typography was set, they informed the typography on other views.
Though we had the established iOS app that we could have drawn from, I used the new Android designs as an opportunity to modernize our typography from our existing platforms.
Color
From a product perspective, we use color minimally as a way to support the content that our editors work so hard to produce. We use a variety of grays; full black is reserved for the New York Times logo. To streamline the number of grays we use across NYT Cooking, I started designing with two grays and carefully added more when they were warranted. We ended up with eight grays, ranging from a dark, almost-black gray to a light, almost-white gray.
In addition to our palette of grays, I used the NYT Cooking-brand red as our accent color.
In digital product design, red is almost always reserved for cautionary actions and messaging. Using it as an accent color is not a common choice because it can conflict with the platform-native red of things like error messages in form fields. However, we do not use many form fields in NYT Cooking. I styled our UI elements with a tasteful amount of red without conveying that users made an error. I used a brighter shade of red to indicate error states.
Iconography
Because we were building a design system while simultaneously launching our Android app, we opted to use some of the icons provided by Material Design. I didn’t see the need to reinvent the wheel at that point of the app lifecycle. The only exception we made was for our save icon, which is prominently displayed throughout our app.
Creating Components
Components are templates for elements like a button or navigation menu; The key thing about components is that they are reusable. I started creating components once I found myself reusing the same element in multiple places, like our cards.
Cards
Cards are our primary components and are used throughout our entire app. Our cards provide an abbreviated look into the content, whether it is a recipe, a collection or a guide. These three content types are fundamentally different so we made them visually distinct.
It was hard to anticipate how these cards would look across screen sizes. While there are a standard set of breakpoints for iOS and the web, Android tends to have a wider variety of screen sizes. I defined the base card size to align with the smallest screen size on Android, so that the design would adjust to subsequently larger screen sizes.
We have strict rules about how our content is displayed. The hierarchy of the content on a card is: image, title, byline, action. Our recipes can have long titles that break to multiple lines of text, and they can have long or double bylines. I tried to display as much content on our cards as possible by slightly enlarging the card containers. The logic for text to be displayed on our recipe cards is borrowed from iOS and was adapted for Android.
Having a design system in place has helped our team immensely. Designers who are new to the system have used it to guide their designs, which has allowed the team to ship features faster than before. The Android design system is still a work in progress, but its proven success has kickstarted the process of cementing a design system for our iOS app and web product.
Jayne Lee is a product designer on the NYT Cooking team. Follow her on Twitter.
