A New Beginning

Before importing our outdated design system into abstract, I wanted to revalue the time and resources of import the old design system into Abstract compared to just start over. I took the app project as a testing ground to see how the abstract sketch files should be structured. At the time, we have the whole design system in one file, causing Sketch to crash like crazy due to the nature of the file sizes.

Sketch has also introduced a bunch new features like Auto Layout and Components view, so I wanted to take advantage of those new features when it comes to building out the new revised Design System. There was a great article on Medium by Joe Woodward in how his team at Microsoft uses Abstract Link.

Components

One of our main objective for the new mobile app refresh was to give both apps a native look and feel to their respected platforms. This means we need to follow the guidelines provided by Apple and Google, along with building out the native components inside of Sketch.

I did an initial check of the core components and realized we are missing almost all of the native iOS and Android components. It's clear that, along with building the web components in Abstract, I would have also build out the native iOS and Android components. Thankfully, Inside Sketch, you can download the official Apple UI Library, and Google does provide a plugin for Sketch to get their latest UIkit for Material UI.

Native First, then Merge with the Web

My strategy was to first focus solely on the native components, since both Apple and Google does provide excellent documentation, I can use that as the base of the revised design system. I also dive into many other great open source Design System from IBM, Atlasssian, and Shopify. Each gave great inspiration on how to write documentation and how they manage their files.

I wanted to keep the system small, so it's easy to maintain. Remember, this was at the time just a side project of mine. Many of the foundation components are shared between the apps and the web, which also mean that the Documentation I am writing for the Mobile App can be share across platforms. My hope is that at later time, that the work I am doing now can be merge with the web to have consistency across the board.

Approval from PM

It was essential to me that all of this side work is getting tracked. I talked to my PM and Engineers, who all agreed to open tickets inside of JIRA to track the work. In each of the sprint ticket, I would list all the Design System work I would like to tackle and size it accordingly to my overall workload.

File Structure

Before Abstract, All of our symbols were inside one sketch document, along with the UI. As time goes on, these files were getting hard to maintain. With Abstract, I wanted to define a new file structure for the team. Something that simple to follow, but most importantly, easy to maintain. I divided the new file structure into four tiers.

Foundation

In the Foundation file, it have all the core "atom" components of the Design System. Include Typography, Icons, and Colors. Ideally, if any significant changes in the future, we only needed to change them here, and then they will get updated across all the files.

Platform Components

For Platform-specific components, these files will include all the native components to their respected platform. For example, iOS and Android have different navbars and modals.

Complex Components

Tier three includes all the page components built from using the foundation and platforms library. It also consists of the different states of the component and its Documentations.

UI Comps

Finally, tier four consist of the final comps ready for Dev Handoff. In this file, you can also find the user flows or any documentation that’s useful for the devs. We normally uploading everything in this file to Zeplin, which then the dev can comment and ask questions.

💎 The Revised Design System

The Foundation

Having a clean canvas allows me to rethink and rebuild that leverage all the functionalities that Sketch offered. Building complex components with overrides was a very time-consuming, but it became a time saver as we started building multiple flows with many pages.

To fix any problem, you need starts at the core. Beside inconsistency, our current design system had many issue dealing with accessibility. My goal is to build a newly revised design system that have accessibility at the foundation.

As for the Color System, I took the time to expand our existing color palette to have more shades and taken into consideration for Dark Mode. Along with the video by Ed Chao on Design System, I also discovered a video on Color System at Lyft by Linda Dong.

Linda talked great length on their color system at Lyft. One of the primary key points I got from Linda's talk was that each of devices can emit light differently, and that effects how color renders on those displays. Coming from a print background, this isn't new, as color accuracy is also essential when it comes to printing. Screen technology has come a long way; from the old CRTs to now OLED, there's a wide range of display technology, along with color profiles.

The color profiles are probably the hardest to tackle. When I was working on the Web, our VP had our entire top navigation color changed just because he can't see it on his screen. We later found out that his display was poorly calibrated and that the light gray we used was showing up white on the screen. Looking at our data from analytics, we have many users who still using the older iPhones and Android phones, along with a lot user who still uses an older PC operating system that probably also uses an older screen. I'm hoping to address a lot of these issues when it comes to this revised design system.

At AutoZone, we have a very limited color palette. Our core colors, you probably can guess, it's red and Orange. It was tough to design around the color orange, plus we have no complementary colors in our brand guideline 🙄. So it was either Orange or some shade of grey. My goal was to at least expand our color pallets with different shades of orange and red, plus expand our core colors to include complementary colors.

Most of the time, when using white on orange it doesn't pass ADA Compliant, and black on range doesn't look pleasing. Building UI with only Orange, Black, and 5 Shades of grey can be challenging and at time frustrating. My proposal for the Color Expansion was first to expand our current colors into shades, so we have various Orange to work with in term of “Branding the UI”

Thanks to the talk by Linda, I discovered that one for the developer at Lyft had created a tool to help create color scales. It's called Colorbox. This tool has became super helpful in creating the expansion colors for the design system.

The scale was based on Primary Color’s Saturation and Brightness, which make sense since it’s how the real world expresses shades through light. The tool also helped with colors that work well in Dark Mode. The complete Documentation can be view below.

We also leverage color tokens that can be associated with multiple roles and theme. This allows for uniform color application across themes while maintaining full styling flexibility.

“Design system tokens are meant to be flexible and work cross-platform, which means different teams, different implementations, and different libraries will name things differently. This is where this specification would fit in. A lot of interoperability could be realized, if we all, for example, named our color palette colors and named the font sizes we use fontSizes. What you do beyond that and what data format you use to store these values, is up to you. It’s trivial to convert JSON to ES modules to YAML or even TOML, if that’s your thing. It’s also just a data structure, so transforming between other data structures (e.g. design tools or a GraphQL API) should also be possible. This standard also wouldn’t try to solve the extremely complex problems of how to name the colors themselves.” CSS-Tricks

📁 Naming Conventions

Good Design is also Smart Design; at the beginning of this project, our entire design group didn't have a naming convention for building symbols. Every file mainly was consisted of a bunch of nested folders named "Group #."

For the new revised Design System, which will now consist of complex nested symbols, having a clean file with the correct naming convention is critical. We came up with an Emoji system when it comes to naming the symbols.

🛠 Building Nested Symbols

We decided not to import our existing design file into Abstract and build from scratch to save time. It was an opportunity to rethink how we can make these complex components in a new way that we can accommodate all the different states and styles.

The above Form input Component might look simple, but once you click on it and see the overrides, it will give a better sense how the component was structured. The goal for a complex symbol is to take into consideration all the attributes of that components. Below I will go over how we structure and build these complex components.

Base Component 

We start with the foundation. For the Input Field, we begin with the background layer, which includes attributes that include Border Radius, Background color, Border Color, and Elevation Level. This base component will be the base for all input fields. In the future, if we do need to change any of the attributes, instead of manually fixing all the components, we only need this make changes to this based component. 

State Components

To account for all the different states of the input field, we will split those into their symbols. For the Input Field, we split the component into Left and Right. The left and the right component will have all different states nested into that one symbol, so you can change to another state in the override panel. Along with the component states, you can also override the typography. 

Complex Components

By combining both the base and state components, we now have a fully complex component for the input field. A single component can now account for all the different states and platform-specific fonts.

Overrides

Here look at the overrides. The naming convention really helps with understanding which of the attributes you are changing. Building these complex components really make one think how complex to implement the simplest components like buttons and input fields. But these components are the foundation, and its important to think to build for scale.