Building the Cardhub design system
Using atomic design principles to build an accessible & scalable design system for our iOS/Android apps.
SUMMARY
As many design teams know, a comprehensive design system is key to efficiently build consistent UI. I lead the process of building Ondot's entire mobile design system from the ground up, as well as making accessibility a priority.
MY ROLE: AUGUST 2020 - PRESENT
Lead designer through end to end process, from initial audit and research to maintaining the current system.
🚦 The Green Light
Ondot, a mid-sized fintech startup, had little focus on design within the organization. When I joined, the Sketch files were stored with haphazard names in cloud storage; within the files themselves, the UI was made with "on-the-fly" components (no symbols, just copy-pasting for consistency). I had a pretty major challenge of learning the design language from these files alone, and then trying to help onboard new designers with our lack of a system.
My first stab at trying to quell the internal design fire was to introduce Abstract to our organization. I'm proud to say this was a huge step in adding a process to our documentation and a structure to our design files.
Next was the harder part, which was getting the buy-in to even free up my working time to implement a design system. I became a bit of a broken record to my manager about the following benefits:
-
Consistency throughout our UI
-
Efficiency when we create high-fidelity user journeys
-
A process to the madness of introducing and validating new components
-
Documentation so that the knowledge isn't living in one person's head
And we finally got the green light!
🔬 Research
How should I structure the design system? Where should it be hosted? What are some guiding principles to follow and mistakes to avoid?
Every project starts with the research. I knew great design teams have already tackled this problem, so I looked for external examples and tools.
As I was getting dazzled by the fancy tools available, my teammate introduced me to Brad Frost's book on Atomic Design; atomic design principles seemed like a simple and manageable solution for us to get started, while giving us the framework to scale.
Since we are a really small team of 2 designers and a manager, we settled on just using a Sketch linked library to house our design system, and using Abstract to share certain documentation with other teams (dev & QA).
🔍 Audit
As I mentioned earlier, our existing "system" was in disarray. The app had already been around for several years and therefore had lots of existing, in-production UI.
We also had the additional challenge of building a unified branded system for a white-label app:
-
What was the appropriate color palette for our app, if customers could re-brand certain UI components to their own colors anyway?
-
How should we handle the fact that some UI components could be branded in different colors, depending on the customer?
-
Did we have a unified tone/voice to maintain?
I combed the Sketch files and came up with a list (or rather, dump) of components, colors, and text styles I knew we would be including in our new design system. Here's a peek of the notes:
🚧 Obstacles
I was ready to jump in and start getting my hands dirty with creating the first "atoms". However, there were a few lingering questions that needed to be answered in parallel, and many required more hands on deck:
RE-BRANDING
Problem: Our product is a white-label app, wherein customers can choose specific colors & assets to be used in their apps. What branding should be applied to our design system?
Solution: Our existing designs were all styled in an orange-and-white color palette that reflected our actual company's branding colors, and our assets all reflected a fictional entity "OneBank".
One issue with this existing construct was accessibility. The bright orange color we were using everywhere either did not pass WCAG AA guidelines for contrast, or barely passed. Although end users would not be using an app with this palette, the UI would still be presented in marketing and sales use cases.
Another issue was brought up by the marketing and sales teams, who had been concerned for a while that the demo UI they were presenting did not align with the prospective customer base.
Working with these teams, we settled on a brand-new branding that all future designs would take, and that the design system should live as.
I wanted to go with a dark blue color as our primary based on some research into color psychology. Although I'm personally a fan of bright, vibrant yellows and oranges, I thought blue would be a good option for the following reasons:
-
In color psychology, blue evokes feelings of security, trust, and stability. We wanted both the app and the fake financial institution to appear secure and reliable.
-
The dark blue color passes contrast ratio checks with flying colors.
ACCESSIBILITY
Problem: There were several red flags for accessibility throughout the existing UX, and I knew a great time to address them would be while I was doing a thorough audit of everything for the design system.
Solution: I could change the design patterns to be more accessible, but the effort wouldn't really mean much without the changes going out to our users in the existing app. We got the engineering team to agree to several sprints dedicated to making ADA UX changes. This included fixing what I considered some "low-hanging fruit", like too-small text, as well as some pretty major efforts like adding proper focus order and voiceover text to each page.
I got to work on ADA and WCAG research, as it was my first time learning about the guidelines and best practices. I had the task ahead to not only fix WCAG failures and provide focus order and voiceover guidelines for our whole app, but to educate others on the engineering and product teams about ADA.
Suddenly my task got much bigger.. the project now included the design system, rebranding effort, and accessibility overhaul!
Suddenly my task got much bigger.. the project now included the design system, rebranding effort, and accessibility overhaul! I was definitely overwhelmed by the amount of learning, execution, and support that would have to take place. However, I'm happy that it meant another step towards improving our UX and our internal design operations.
⚛️ The Design System
STRUCTURE
As I mentioned earlier, we used Brad Frost's Atomic Design as our North Star. It was a great learning process for me to break down our components to their basic building blocks, and to fiddle with all the Sketch symbols over and over until they behaved the way I needed them to.
"Atomic design is atoms, molecules, organisms, templates, and pages concurrently working together to create effective interface design systems."
ATOMS
My first task was putting the atoms together. I did not use Atomic Design as a strict rule book, but rather interpreted the principles in a way that would make sense with our specific UX. So I first collected the following in Sketch:
-
Branded colors (the colors that can be changed in the UI for each customer) as layer styles
-
Unbranded colors as layer styles
-
Branded text styles
-
Unbranded text styles
-
Icons
Icon Library
MOLECULES
This step was a bit more difficult for me than I had expected. I originally thought, "All right - now I just have to put the atoms together into the standard components like buttons, inputs, etc." So I started building this out, and got pretty far into the exercise before I realized my mistakes.
Different states of our Action Card component
I started adding a new symbol for each of these different states of an Action Card. There are even more states than the ones shown above, so it became a task of the same component created and duplicated multiple times. Only then did I realize that components like this could be separated into smaller building blocks, and each variation could be made by plugging those blocks (molecules!) in.
So, I scrapped the first approach and redid the library of molecules as left and right states. It's not a learning process without mistakes!
Different variations of the left and right states for an Action Card
COMPONENTS
The process of putting molecules together to form our standard, recognizable components was another task that was a bit more complicated than I thought it would be. This stage saw me very frustrated and jittery on caffeine, as I fiddled with Sketch settings for overrides, layout, and resizing. I don't have much to showcase on this front except for the confirmation that practice and iteration really are the keys to success!
iOS component overview document
🐕🦺 Accessibility
In this phase of the project, we accomplished three major tasks:
-
Putting together focus order & voiceover requirements for the developers
-
Fixing some parts of the existing UX that did not pass WCAG AA guidelines
-
Getting a full VPAT audit and certification
DEFINING FOCUS ORDER & VOICEOVER GUIDELINES
This is where I spent the greatest chunk of my time; I did not have any prior experience working on focus order & voiceover, so I had to educate myself a lot on best practices. I spent about a week with Voiceover enabled on my iPhone, which drove my roommates crazy!
It didn't seem humanly possible to specify requirements for every existing screen in the app, so this is where the design system came in. As part of the design system, I added an "ADA design system", which included:
-
General rules of thumb for establishing focus order within a screen
-
Standard voiceover text for the common UI components (as previously identify in the design system)
-
Focus order and voiceover text for several special cases, where general guidelines wouldn't be sufficient
This system exists as part of our process for new UX today; when new user journeys are created, the design team takes into consideration any behavior that might require additional focus order and voiceover definition, and provide those specifications to the developers.
iOS focus order + voiceover specs for common UI components
FIXING THE GLARING ISSUES
Here are a few additional areas of improvement that we were able to cover. I'm pleased that we were able to improve the experience as part of a design system standardization process, as it became two birds with one stone; inconsistencies in the existing design were fixed and replaced with a standardized, accessible UI.
Problem: The red/green colors were the only visual indicator that the card was turned off/on, which may be an issue for color blind individuals.
Solution: Add text in addition to color to communicate card status, and darken the green/red colors to ensure proper contrast ratio for reading the text.
🔮 Takeaways + The Future
It's not an exaggeration to say that every day at work, I'm so glad that we were able to take the time to implement this project. We made great strides in improving our UX and our internal design operations, and will continue to do so as the design team adds to the system over the years!
What's next:
-
We're currently working on adding templates to our design system.
-
There are some parts of our UI that technically pass WCAG AA but I feel are at the bare minimum of accessibility and that we can improve upon.
-
Adding a design interaction library has been on my mind for a while.
My personal takeaways:
-
Don't overpromise and underdeliver; choose what you won't do (for now). After my audit, I was keeping tabs on so many areas that I wanted changed across the board for improved visual design, usability, and accessibility. However, we have defined time frames and project scopes for a reason! There were a lot more improvements that could be made that would be costly to the team, and we'd be at risk of spreading ourselves too thin. I learned how to make compromises on the MVP while still fighting for UX.
-
Education is the first step, and it's never completed! I had to do a lot of research to take the lead on this project, especially around accessibility. Personal education is the easy part; teaching other stakeholders about design is more difficult. Helping folks understand what we're doing and why it's important was key to making sure we were successful.