Scaling & evolving a design system.
Noom’s design system had grown organically up until this point. But the growth of the company and the design team meant that investing in a design system and consistency was a must at this point. For both efficiency and sanity.
PROJECT SUMMARY
The context.
Noom had grown over the last five years. Over the course of this growth it had upgraded its brand identity twice. Which meant that we had a mismatch of old and new UI, colors and styles in the current app.
The problem.
Bespoke hipster development resulting in random UI and visual elements. That’s right, we’re talking about graphs coded by hand, and NO coded components shared across teams.
The opportunity.
A comprehensive design system and guidelines on usage. And — for the love of pixels — coded components. We had the chance to save all of the designers eyes and save the developers a huge chuck of time.
The hurdles.
Tight timelines, and a very basic design system that was incomplete in Figma and only half implemented in the app.
The approach.
Industry standard is often standard for a reason. In this case using the “Atomic Design” methodology just made sense. It would give us a scaleable way to organize and grow the current system all while still utilizing it for past and current projects.
WHAT DO WE HAVE?
Figuring out where you’re at is always a good idea. Luckily we didn’t have to re-invent the wheel, all we had to do was figure out which pieces we had and didn’t have. Below is a list of the basic components we needed in each category, and an emoji representing what our design system had/didn’t have.
✅ = have it
😬 = have this but when I use it I want to cry because I basically have to redo it
😡 = don’t have it and need it
Atoms
😬 Typographic styles
😬 Color swatches
😬 Icons
✅ Radio buttons
✅ Checkboxes
😡 Sliders
😬 Toggles
😡 Profile pictures (defaults)
😬 Buttons
😡 Links
😬 Input fields
😬 Tabs
😡 Pills
😡 Badges
😡 Tags
✅ Tooltips
Molecules
😡 Dropdown menus
😡 Dropdown buttons
😡 Date pickers
😬 Search components
😡 Breadcrumbs
😡 Cards
😬 Collapsible sections
😬 Loading components
😬 Notifications
😬 Pagination
✅ Toasts
😬 Error/empty states
✅ Modals
✅ Tiles
Organisms
😬 Navigation bars
😬 Tab bars
😡 Video players
😬 Audio players
😬 Media grids
😡 Progress indicator
😡 Tables
😡 Carousels
😬 Forms
And just like that it all made sense.
No wonder we spent so much time when we had to start going into high fidelity.The reason the developers were always asking for icons.Why choosing the right color for a new visual or piece of UI was so difficult (the list was longer but we’ll leave it here for now😆).
The foundation of our design system was only half built. The solution was to start at the atom level and iterate. So that’s what we did (me & and few other passionate designers that loved pixels).
ATOMS
Below are some of the atoms that I went after first (believe me they had it coming). There were others of course but these were the ones that I felt the most satisfaction when finally getting to redesign them.
1 Icons
Nothing in our design system hurt my poor designer eyes and soul quite like our icon library. Were they all in the same size bounding box? Yes. Were they all the same size, style or stroke weight? No. No they were not😭
It sounds like a very niche designer problem I know. But past making the app look sloppy and half finished it also made finding and maintaining icons a pain point for both design and engineering.
The problems
Not a cohesive set
All of the icons were added to the system basically as they were needed. Which meant that they were either hand made by different designers, or found on random open source websites.
They all look fine alone, but when they’re next to each other the differences between sizes and strokes was obvious. The number of times I had to redo icons so they actually match was too many to count.
Truly a pain to work with
We only had one icon size, which does not cut it. Especially when we had icons we needed for both mobile and desktop. Oh did I mention that they also didn’t resize. That’s right. To resize them I had to detach the component and manually adjust everything.
Random use of color
Why are these icons colored? I have no idea. Fun but not useful. What we needed was usage guides to avoid random color without meaning.
If we had had guidelines around color usage a lot of design hours could be saved, especially when it came to defining active states.
Icons 2.0
Defined sizes & guides
That’s right, only 24px and 16px allowed. No weird 11px tiny unreadable icons. And the grids to match, we’re talking rectangular, square and circular.
Easy to resize & swap
I restructured all of the attributes for each icon. This way they could easily be resized and swapped out for a different color. This tiny change was especially useful for prototyping.
Seems obvious, but it didn’t exist before😭
Consistent colors
A dark set of icons for standard use, and a light set for when icons need to be used with a colored background.
Usage guidelines
Do use blue for actionable icons
Icons that perform an action immediately (on tap) will have a blue/white variant that should be used with a filled/unfilled state.
Don’t use random fill colors
Stick to the standard fill and active colors.
Do use the standard sizes
The two sizes have been scaled to make sure that the stroke widths are uniform.
Don’t create random tiny icons
Smaller icons are difficult to see, and the strokes don’t scale if you manually downsize them.