SoWork - Design System

A vital project to set product standards and manage design and development at scale. SoWork's Design System established guardrails, created redundancy, and helped secure visual consistency across the company's core product and marketing offerings.

Cover image for SoWork - Design System
Client
SoWork
Tags
#Design System
#Figma
#Component Library
#Style Guide

We were all very excited at the company. Our team had just rebranded and we had launched and deployed a lengthy redesign of our entire SASS application to overwhelmingly positive user feedback. Once the dust had settled we decided to get things started on the right foot moving forward regarding design scalability and consistency. Product and Design banded together and I set off to create a Design System.

So what is a Design System? Mileage may vary but for the purposes of this project we defined the Design System as three sets of tools folded into one: a component library, a style guide, and our design principles.

Component Library

Our application was built in React and due to that we used Material UI as our base component framework (modals, switches, buttons, tooltips, etc.) Material UI is an open-source React component library that implements Google's Material Design. It's nice, light-weight, and remarkably consistent. It also ports over to mobile very well. Even so, our app had a lot of custom designed components after our redesign that needed a place to call home and even more importantly, a place that cross-functional design and development teams could access, use, reference, and discuss.

The result was a pairing of Material UI and the our custom component library into a working master Figma file along with a working prototype of said components in all their various states that engineers could click through to view important transitional states between elements and features.

Figma Component Library with custom components
A Figma preview of some of SoWork's custom components and their various use states

Style Guide

When creating SoWork's style guide we knew that being a startup we'd want to iterate and add as we go and so our first release of the style guide focused on a few distinct visual areas across the app, public, and marketing domain: typography, color, and iconography.

Since we had also just rebranded my first choice was to focus on color. Our color palette primarily relied on soft blues and greens to invoke cool, calm feelings but within that color set we had many different shades and we knew that the potential for "cross-pollination" and rogue use of the colors would be too easily accessible and to no fault of engineering. When someone says "make it blue" and you have 4-5 blues, you better know which blue they are referencing. We wanted to circumvent these situations as much as possible and therefore we gave every shade of color a distinct name for easy memory mapping with our team.

Screenshot of SoWork's colors in the Figma Style Guide
SoWork Colors excerpt from the Figma Style Guide. Colors contain hex and RGBA values as well as use case examples

Typography

One of the first things I did at SoWork was drastically simplify the typography. An initial branding audit revealed we had 6 different fonts active or archived within the public domain and codebase. This was to no ones fault of their own, this is the kind of thing that can happen when working within a fast-paced iterative startup at the beginning. You move fast and throw out features quickly, and this was just unfortunate tech-debt at the cost of the fast-paced growth. Let's simplify! We settled on Gilroy, a nice modern sans-serif font created by Radomir Tinkov. Gilroy has a nice geometric touch that works well on all modern devices. After that we scuttled all the other fonts (and provided safe-system use fonts as fallbacks), and regulated how many different font types and weights within Gilroy we would use. We whittled it down from 7 variants to just 3 (light, regular, and extrabold). Further reducing the variants helped us optimize our product and CSS load times. From there it was just a matter of creating consistent headings (H1-H4), body paragraphs, subheadings, and labels, and then combining them with our aforementioned new colors. We were off and running!

Iconography

One of our SoWork design principles is consistency (#spoilers!), and believe it or not iconography was somewhere where we found this most problematic before launching our style guide. The main problem arose from our sources of icons: Material UI, Font-awesome, and custom (via our art team or purchased), art. Between all these avenues of options we ended up with a lot of inconsistent iconography in terms of appearance and design. Many of our icons didn't match and our product looked worse for it. In a quick pinch designers, engineers, and product members were all recommending icons simultaneously during our testing phase which led to a lot of confusion. Users were quick to point it out and that was just the qualitative data I needed to act quickly!

Where we ended up was with a set of guardrails published in the style guide that defined icongraphy selection and acceptance criteria. We also shyed away from using emojis as a previous bad habit that although looked fun, cluttered up our original UI and introduced too many off-brand colors.

Design Principles

Aiding in all our user research and problem solving product opportunities were foundational design principles that we created to serve as a starting point for everything from lofi drawings on napkins and wireframes to Figma prototyping and A/B testing with users. These design principles are rooted in working backwards in trying to solve for the users problem and keeping you tethered in that experience.

Consistency

For anyone versed in web, product, or human-computer interaction principles this one is an absolute pillar. Consistency breeds success in most products, leads to healthy habits, helps accomplish goals, and much more, and that's just real-life! In plain design terms, consistency ensures that your product looks coherent and works harmoniously across all its different elements. Users might not know how to describe design consistency but they come to expect it and if you don't have it you can be damn sure your product will be worse off for it in terms of reduced activation, retention, and high bounce rates. If a product is confusing chances are that the user experience isn't consistent enough in it's delivery of a solution or navigation to said solution.

Simplicity

How straight-forward is the user experience? How can we aid the user in accomplishing their goals? What gets in the way? Keep it simple, and simplify more if possible. Design and product solutions should always be intuitive and keeping it simple helps ensure a positive user experience.

Extensibility

Extensibility is something that I don't think gets brought up enough, especially in fast-paced iterative product design and startup environments. Very rarely is product feature version 1 the homerun that you need it to be. In most cases iteration and adjustments are required for a product feature to have measurable success. Is your solution extensible enough that adding to it is seamless and intuitive (both from a design and UX lens), or would adding subfeatures/menus bring you back to the drawing board?

Bonus Russ Principle: RCC (reduced-clicks-to-content)

This is just a pet peeve of mine I like to throw out that aligns with simplicity. How many clicks does it take for the user to accomplish their goal? Can those clicks be reduced without negatively impacting the core user experience or inadvertently adding tech debt or sacrificing accessibility? Just some food for thought.

A visual aid of what a design system can be
One of my favorite images on the internet