Creating my first design system

DATE OF PROJECT

August 2018 - January 2019 (~5 months)

RESPONSIBILITIES

Research
Competitive Analysis
Design Token Architecture
UI Design
User Flows
Surveys
Branding
Documentation

TL;DR

As a young team (a majority straight out of post-secondary) who stumbled upon a great solution to a problem, given large investments of cash, and having an attitude to "build fast", there was no surprise when things were built with little regard for consistency or even the slightest thought of what was "on brand".

Auditing our system, creating a "Mission Statement" for design, documenting brand guidelines, and creating a library of reusable components helped revert inconsistency, and established a shared language for the entire product team to work more efficiently.

Problem

Even as a relatively young company of only three years, simple inexperience had us building and designing without many best-practices and "vision" of what the future would require.

Our product looked like a quilt of UI inspiration, with more than 5 date picker styles, 14+ button styles, 9+ input styles, colors used differently on every page, multiple font families used without a strategy, and a plethora of other issues.

However, the biggest problem came back to communication and understanding within the team as there were no guidelines of what was right and wrong.

Audit

This initially started as just a diagnosis of our design and identity; a full-fledged Design System was not the original goal. We didn't even have a project scoped for this in the beginning, it was merely a search and asses. However, after discovering so many inconsistencies early on, a plan to create a visual system and component library began to make sense.

I began auditing our design from front to back by capturing and organizing every style and component in a large Figma sheet to get a better lay of the land. This audit spanned throughout our product, web pages, marketing collateral, internal documents and slide decks, all the way to social media content and ads.

Hypothesis

If we created a set of documented guidelines and reusable components, it would drastically speed up both designers and developers while improving our products consistency and professionalism.

Vision

We started by creating a "mission statement" for how we were supposed to look and feel.

"Our platform is to be a stage for our users and their content."

It was almost the opposite of what we were currently doing. We wanted a minimal UI where our customers and their content were the highlights, but up until this point, our UI was heavy and attention grabbing.

Design System Architecture

Atomic Design:
Identifies a relationship and hierarchy in which products are built from fundamental design conceptions that form together to create building blocks, that continue to combine to create more substantial and complex objects. #AlmostScience

Style & Branding

Accessibility laws, color palette, typography, grid systems, responsiveness and breakpoints, borders options, corner radius, shadows, tone, and product personality, were all defined before touching the design of an actual atom.

These things, in my mind, are essential to understand before creating anything so that we knew who we were going to be. Pieces were slightly adjusted and tweaked as we moved along, but having these guidelines first gave us a constant reminder and boundaries to ensure things stayed feeling like part of the same system.

Atoms

Using these laws, we were able to begin creating atoms, the fundamental building blocks for everything our product would be. Inputs, dropdowns, buttons, check boxes, toggles, profile pictures, status bubbles, and many more came together to be our first set of atoms.

We were also documenting everything to capture the "why" behind the decisions we made, and each element we created. This much documentation can get tedious and no doubt, but the results can make things easier on the entire company. We complemented our documentation by mapping design tokens to everything in our design system so that every style and element could be easily mapped to our CSS. This allowed everyone to know exactly how things were built, and it created a common language between every corner of the business.

Organisms

Organisms for us included input forms, comment cards, date pickers, mini calendars, information cards, calendar post tiles, and more.

Since the design system project was not a primary objective in any sprint, it became something we tried to update whenever we had free time. Once we began finishing our set of organisms, we started using them in our designs for new projects. This allowed us to test and feel things out while it was still being created to speed up our process of finding what would work and what needed tweaking.

The feeling that you're close to v1.0.0 becomes a tease, and every time you find something needing a tweak, it breaks your heart a little. We had to continually remind ourselves that this project was never going to "finish". A design system is an ever living, ever improving project from the day you begin to the day you stop growing your product.

Templates & Pages

Once Atoms and Organisms were approved upon, we began putting things together to create larger objects that held their own functionality. Things like navigation bars, text input areas such as comments, long form text editors, short and long-form text areas, settings panels, etc.

And then a few days later... we had the first version of a design system! Documented, built in Figma, and shared across the entire product team ready for its first feature, and a product ready to be slowly refactored with a new front end.

Implemen-
tation

Creating a visual design system, guidelines, and documentation is one thing; implementing it into a product is a whole other beast. Updating our front end architecture, tech stack, and getting the dev team onboard with all the new documentation, design tokens, and terminology was a project in its self.

It's here where design tokens required a lot of adjustment and tweaking to make sure things looked and worked exactly as envisioned, it was also here where I began studying React.js so that I could better understand how things were being built and so that I could dip my hands in code and help out if ever needed.

Results

Not only did this drastically speed up designers working on fixes and new projects, but it also helped reduce assumptions and concerns from developers. The team became better aligned, using a common language shared across the product team to help quickly translate and explain ideas and functionality.

Atomic design, although seemingly implemented differently between every company, is a great mindset to share with everyone in product and gives a perfect hierarchy to understand how things are pieced together.

And finally, documentation is the most important key. Documenting why things are designed, their use cases, their restrictions, as well as anything that could help other teams or new designers such as design tokens removes assumptions and second guessing. And if you can keep everything nicely organized and searchable, it allows everyone in the company find information and become product experts at a glance.