Building the Voices Design System

I first started at Voices in early 2018 as their first Product Designer (which also happened to be my first full-time UX job). I got tasked with figuring out how to set up the design practice for the Product department that was not yet fully established. Sure, no big deal! But really I had never felt the saying “fake it till you make it” more before this point.

Design systems were becoming common practice back then and I figured this was a good starting point to start establishing the foundations for our design process. In doing research it became clear that this wasn’t just a fad, but actually a way of structuring design that had benefits across the board for not only our designers and developers by allowing us to work more efficiently, but also for our users to be able to have a consistent and predictable experience using our platform. Now almost three years later, our design team has grown 300% and, with a little help from my friend Google and the support from our designers and developers, our design system has grown to what I think is a fairly well-established process. So now I want to share a bit of the behind the scenes and some learnings I’ve had along the way!

Read, Read, and Read Some More

At the early stages, I would take my laptop, find a cozy small empty room in the office, put in my headphones, and just research as much as I could about design systems. I started by learning about some of the fundamentals in design systems (like Atomic Design by Brad Frost) and then looked into publicly available systems like Google’s Material Design and Shopify’s Polaris as references. Design System Repo also has a great collection from several companies. Soaking in as much information as I could allowed me to level set how large-scale a design system could be, but also what really the minimum is needed to get the job started.

Get a Lay of the Land

It was important to get a good understanding of where Voices was as far as design capabilities. You don’t want to be the person coming in demanding all these changes and not really knowing why certain things can’t happen right away. That’s definitely not how you make allies in the journey for making your design system. During this time I learned that there was already a good start on a version of a custom internal UI repository website that developers were referencing during a large-scale project already underway by the time I arrived. I also learned that it was becoming harder and harder to maintain, especially so with the introduction of a design team (me) that wouldn’t be able to easily participate in its growth and maintenance.

Find Like-Minded People

Things just go so much better when you work together with team members who have the same end goal. Luckily enough for me, the Development Manager was, and still is, a pleasure to work with and supported the idea of a central design system at Voices. And even though I was the first Product Designer, we also had a couple Marketing Designers and Product Managers at the time who also welcomed the idea of a unified design language with open arms.

Leadership Buy-In

With this support at the ready, then came the grunt work of doing a rough list of the various components and foundational elements throughout our web app. Then the audit exercise of collecting all of the possible different versions of each component and grouping it together for a visual collage of inconsistencies. This was split up between myself and the Marketing Designers. Eventually, the fruits of our labour culminated in a presentation that included these component collages, a bit of background on design systems, as well as the benefits (stronger branding, time saved, etc) to making our design system a concrete (and ongoing) initiative. We were also lucky here in that our CEO is a very visual person and quickly saw the value of what we were proposing. Green light for our design system — yay!

Here’s a peek at a couple of the component audits we did in 2018, specifically highlighting our button and iconography inconsistencies.

Time to Organize!

I know documentation may not be everyone’s cup of tea, but I live for it — despite what my messy desktop may sometimes say. We wanted to largely avoid having information stored with single individuals because if they one day leave the company then we would essentially lose that information along with them or have a harder time training new employees. And by having a go-to spot to refer back to our guidelines makes it easier for knowledge sharing among team members, in turn increasing our chances of it being adapted internally and reduces back and forth on what was agreed on as a team. That’s why our main goal for a documentation platform was to have it complement our current processes and have more team members involved in the creation and maintenance. So at this stage we were faced with deciding what would be the best solution for our team. We had these options available to us:

Maintain the original coded UI website

• Pros: Live code so it updates as we make changes
• Cons: Not accessible to non-developers, doesn’t allow for easy in-progress documentation, can become outdated quickly

Purchase a design system tool like Zeroheight

• Pros: Able to connect to codebase for live samples, simple content management
• Cons: Additional cost, new tool to maintain

Use our existing documentation tool (Confluence)

• Pros: Teams are already familiar with it, no extra cost, can manage/connect to in-progress design system Jira tickets
• Cons: Not the most user friendly content management, not easily accessible to the entire company

In the end, we went with the path of least resistance (aka the path with the higher chance of adoption and ease of maintenance), which meant us becoming good friends with Confluence! And although we ended up using this existing tool we had access to, it’s always been intended as a “good for now and the immediate future” solution just so we could hit the ground running instead of having to worry about a beautifully documented publicly accessible design system. If in the long term we did have the capacity to migrate over to using something like Zeroheight we would at least have our core documentation at the ready to transfer over.

Our current home for our design system documentation, good ol’ Confluence!

Getting the Work Done

With the decision on where our core documentation would live now finalized, then came the time to figure out how the work would actually get done on top of all our regular roadmapped projects. This is where it’s even more crucial to understand that you need to do whatever makes the most sense for your team, and try not to overthink wanting to emulate other companies. For us, we knew it was important to make sure any design system work didn’t disrupt the core focus of a project. We also knew we wanted to set up our dedicated Jira board and fill it with a backlog of all the components we wanted to eventually revisit and update/unify. With this in mind we ended up with a process that looked roughly like this:

• Prioritize and Delegate • It started with prioritizing tasks for designers to start on the design guides and UI components respectively. These are broken down to just a few at a time per designer, and added to our quarterly objectives.
• Identify an Opportunity • When a product team was in the early phases of a project the designer on that team could identify if a design system component was used in the experience and bring it up as a candidate to be grouped with this work package.
• Early Research and Planning • For components we planned to move forward with, it then involved the Designer doing some general design best practice research, exploring UI options, presenting at our weekly Design Guild meetings for feedback, and prepping the design guide documentation and Jira ticket.
• Technical Review • IT folks on the team (devs and QA) would evaluate the effort and time required to make the update. Is this component used site-wide in several instances or just in a few areas which could be more easily managed without adding much scope. For the more widespread components, such as text styles and buttons, these still eventually got updated but had to wait for the right timing to fit them in like during a clean-up sprint between larger projects.
• Add to an Ongoing Project • Once a design system component was pulled into a sprint, the Product Manager would duplicate the Jira task and add it to their team board to track.
• Design Review • The designer would conduct design QA during development to double check for UI and UX accuracy.
• Dev Documentation • Once the sprint was completed, the developer would fill out a developer reference doc (this was paired with our design guide) with more technical details relevant to other developers who would use this component again in the future.
• Share Update • The design system dev lead would announce newly released components either in Slack or during their regular all-dev meetings.

Our ticket process has changed a bit throughout the years, but this was our original ticket lifecycle that helped us have a clearer understanding of how to keep track of our component progress and when to bring it into a product team’s project.

Rinse and repeat! By now we’ve gotten a good amount of our original components done and in the product, but that doesn’t necessarily mean the work stops. We’re still constantly finding ways we can make improvements to how we manage our tasks, as well as adding net new components or just adding new variations to existing components.

Maintenance is Key

Now that we’re a couple years into the journey of our design system, we’ve established a core design system team made of myself and three developers. In this group, we meet regularly to go over any ongoing tasks. We pull up the Jira board and make sure any active tickets are moving along, give a quick update on those, and double check that the documentation for completed tickets are done as well. This is also a time where we can discuss as a group any larger process changes we’d like to explore to improve our design system too.

Future Us

With this team that I’m fortunate enough to work with we always strive to improve and that doesn’t just mean with our product, but also with how we work together through on-going initiatives such as our design system. From a design tool perspective we’ve been starting the process of migrating from Sketch to Figma and in that comes exploring all of the different component management features, such as a recent variants feature update. And from a visibility perspective, we’d like to explore ways we could bring our design system to the broader company by utilizing a tool like Zeroheight for a more user-friendly experience when consuming our guidelines. These are some of the high level goals to try and evolve our design system.

From our early days in spreadsheets, to our current process with go-to team members and established processes, I’m so glad I’m able to say I was, and still am, a part of this ongoing initiative. It’s allowed me to learn how to work better with developers and made me realize how much I enjoy the process side of design. I hope this little behind-the-scenes was helpful to you and your team’s design system!