Formstack Brand
Design System

Creating & Implementing Formstack's First Brand Design System
Project Summary
After attending Smashing Conference in San Fransisco back in 2016 and hearing talks from Jina Anne and Alla Kholmatova, our design team decided to embark on our own Design System journey. We only had three designers and had to continue our regular work load, so the project took nearly a year. However, it has saved our team countless hours since pushing it out, and taught me a great lesson about scaling design and code across systems. You can view the design system here.
My Roles
+ Designer
+ Developer
+ Maintainer
Abstract component photograph

The design system not only shows all our design elements, but also our Brand and Content Guidelines.

It might seem unnecessary at this point to begin with an explanation about why design systems are helpful, as they are the norm these days. However, I think it's important to shine a light on the problems our team was facing which led to the creation of our design system.

At the time, we had three web designers, including myself, on the Creative team within our Marketing department. All three of us designed landing pages, graphics, icons, and other assets; and we also built everything we designed on the site as well. We started to notice that each designer had their own distinct style, which meant there wasn't a great sense of consistency across the site. We also realized we had designed and developed similar components across the site, when we could have just re-used a single component for various scenarios.

As mentioned in the project summary above, we decided to embark on a Designs Systems journey after hearing some enlightening talks and seeing examples at the SmashingConf in San Fransisco back in 2016. Our team had also just finished reading Atomic Design by Brad Frost, so everything sort of fell into place at the same time.
The Problem
The first step in creating our design system wasn't exactly sexy, but it was vital to the success of the project. Our site had become fairly large, and different sections of the site had been updated with new designs and new code, but other sections were still very outdated and ugly. So we began by creating a giant spreadsheet where we listed all the tokens, components, and modules on the site, with links to the  item for reference.

Naturally, this took a while. But after we had everything accounted for, we then went through and organized everything into tokens (the simplest form of something, such as colors, fonts, spacing, etc), components (items made up of multiple tokens such as buttons), modules (sections made up of multiple components, such as CTAs & navigations).
First Things First
Organized cargo yard

"Organization" 📸 Unsplash

Now that we had everything organized, it was time to slash it all to ribbons. We went through the giant list and removed unwanted items, and decided which variation(s) of a component we would keep when there were multiple similar components.

It was important that this step was a collaborative and democratic effort. The three of us on the team voiced our opinions about what we thought should be removed, combined, or redesigned altogether.
Now came the fun part. After having a better idea of what needed to be redesigned or combined, we split up the list between the three of us and got to work. When designing these components, it was important to ask myself a few questions, like how can this scale? what if the copywriters needed to fit more copy here? what happens when we need this on a different colored background? what's the simplest version of this component? and what's the most complex version? We ended up redesigning a lot of components (as it was a great time to do so), so it was important to think ahead so that we didn't find ourselves in a similar, messy situation in the future.

Something that is equally as important as designing better components is defining standards around when and how they should be used. This was our next step in the process and one that, when done poorly, can undermine the integrity of the entire design system. We spent a lot of time discussing and establishing rules for each token, component, and utility class.
Design, Define, & Refine
This was probably the trickiest step in the entire process. The design system was always a project that we had to do on the side, while making sure we continued to output new pages and designs for projects that were happening throughout the year which had hard deadlines. Because of this, we started to roll out the design system in chunks as we were launching other projects.

Once we were in a confident spot with the design system, we put all ongoing projects on hold so that we could officially launch the design system with all the new updated pages, components, tokens, etc.

Overall, the initial launch was a great success. With a project of that scale, there were of course a few minor issues, but we planned and organized this project extremely well for a small team of designers new to the design system game.

More screens from the design system.

We didn't create a design system just so we could feel up to date with current design trends. It has become a part of our daily workflow. By using existing components, we've cut the time we spend in our design and development workflow in half, leaving more time to optimize the site, exploring new better designs, and focusing on scaling the brand as Formstack continues to acquire companies.

What we delivered was a more unified user experience — not just on the marketing site, but also into the product. Now when a user visits our site and signs up for a trial, they won't feel a disconnect. Instead, they'll experience a connected and cohesive flow from site to app.
Back when I lived in Tulsa, I was asked to speak to the Tulsa UX group about my experience creating and implementing this design system. I was also brought in to be a guest lecturer at the University of Tulsa for their Intro to Web Design course, where I gave another presentation on this project.
Follow Up