For the past 18 months, our product team has been working on a major iteration to our platform called ‘Percolate Next’. This update introduces a new infrastructure and features to better support our global customers. As part of this we have refreshed the Percolate UI to ensure an intuitive user experience. I’ve spent the first half of 2018 building a design system to support these efforts.

If you work in product, you’ve probably heard the term ‘design system’ before. At its most basic level, a design system is a shared set of principles, components, and supporting documentation for design and engineering teams to use when building software. People like Nathan Curtis, Brad Frost, and Josh Clark have published some great articles on the topic, so I won’t spend too much time defining it here. Rather, I’d like to focus on the lessons I learned from building our new design system at Percolate.

Lesson 1: Know where you stand before starting the journey

Putting the right team in place

Our design, product management, and engineering teams worked closely in the early phases to plan out the stages of the Percolate Next project. We decided to create a dedicated team who would be in charge of orchestrating the redesign. This ‘Design System Team’ would consist of two full-time designers and two full-time engineers. The plan was to design and develop the design system while the other teams worked on product features. Managers would then block out time for applying the new framework to their product areas.

Understanding the health of our codebase

Over the lifespan of our product, there were times when engineers wrote custom or duplicative code instead of using the existing component library, which resulted in an inconsistent and bloated front end code base. Before kicking off the Percolate Next project, we had established a part-time team focused on the standardization of our code in order to ensure any updates to our components would be reflected globally. Investigating this with engineering helped us realize that we needed clearer and more accessible guidelines for our teams.

Carrying out an interface inventory to set goals

We spent a couple of weeks on an interface inventory which led us to find design inconsistencies across our platform. The issues we identified fell into two buckets; visual design and interaction design.

Visual design issues ranged from 15 button styles to too many headings, to our limited color palette that led to confusion, and in places lacked the contrast to render our interface on the monitors our customers were using. We also saw how the spacing across our form framework made it difficult to determine the relationship between objects.

Interaction design issues had also crept as we had built out our product. From issues like user-flows diverging from intended behavior, to overflow menu interactions that contained too many options for users to make sense of. We also saw inconsistency in control types used for common actions, like submitting a form.

Doing the inventory helped us set clear goals for how we wanted to improve our UI.

Visual design goals

  • Color palette: Create an accessible color palette that clarifies information and interface states for our users.
  • Information density: Create rules for spacing and alignment between objects so users can easily determine the relationships between each other.
  • Type hierarchy: Create headline, subhead and body type rules that could be applied to all instances of the new design system.

Interaction design goals

  • Global navigation: Create a clear hierarchy and a consistent relationship between global and app specific navigation.
  • Progressive disclosure: Create patterns that provide appropriate levels of detail without the need for users to navigate away.
  • Actions: Create consistent placement, style, and interaction for actions, including progressive and regressive buttons.
  • Condensing page types: Create consistent layout and functionality for common page types throughout the system.

Lesson 2: Make sure everyone is speaking the same language

Establishing a product vocabulary

We knew aligning on a shared vocabulary would be essential in order for collaboration between product teams. We were inspired by Brad Frost’s‘Atomic Design’ methodology for naming our UI framework. It was imperative that our naming conventions used in Sketch matched that of our code base. This would ensure that our engineers, product designers, and product managers were all speaking the same language moving forward. We customized the Atomic Design classification to fit our own needs and internal lingo.

  • Foundations are the building blocks of every piece of UI in our system. Eg. color, typography, grid.
  • Elements are the smallest pieces of functional UI. Eg. buttons. Wherever possible, we will present elements as states within patterns.
  • Patterns are Percolate specific component groups. They appear system-wide in different states and are composed of multiple elements.
  • Templates are page-level objects that place patterns into a layout and articulate the design’s underlying content structure.

Documenting everything

We built the design system to be an internal tool. We wanted our documentation to enable product team members to problem solve and brainstorm ideas, and it also needed to support our marketing and customer support teams when talking about the Percolate interface with our customers. With this in mind, we built the documentation to be concise and supported with examples. If additional information was needed we defined how, why, and when to use the component.

Building out our design resources

Our design team didn’t have an up-to-date resource of UI components and documentation before we started Percolate Next. An audit revealed that most of these pieces were in various stages of completion. We had started creating a Sketch Library and researched how to properly structure UI components and organize our master files, and we had recently a completed a workshop for determining our design principles. This stage was really about pulling the parts together to see where the holes were and building from there.

Lesson 3: Integrate the right tools into your team’s workflow

Pick tools that work across teams

Whilst the design system lives in code, the design team uses a static version in Sketch to illustrate flows and prototype new features. The reason Sketch is our tool of choice is because it can enforce component consistency between design files; that way, we can guarantee that designs shared with engineers are always using the latest version of our UI. Our master Sketch Library lives in a shared Google Drive folder with ‘View Only’ access to prevent other team members from editing it.

We’ve also leveraged Zeplin in order to communicate changes and provide updates on the progress of in-flight components. Zeplin is a collaboration tool for designers and engineers in which designers can turn their designs into specs and guidelines, and engineers can generate platform-related code snippets. The entire product org has access to the Design System Zeplin project, with everyone being encouraged to leave feedback and ask questions on what is being created. The annotation feature in Zeplin is really handy as it provides context on what component is being commented on. This helps our team respond quickly.

Another way we collaborate is through the Zeplin-Slack integration. We created a #design-system channel that generates a message anytime someone updates the DS project in Zeplin.

Creating new processes to speed up production

Once the design system was underway, we started receiving requests from product team members. The speed at which these requests were coming in required us to create a simple system for capturing and prioritizing them. We found Google Spreadsheets to be hugely helpful.

We also introduced a second sketch library for full page templates. The ability to drop full-page layouts into design files drastically increased our speed from design to code because designers no longer had to do the upfront work of finding and placing components into empty art boards. In other instances, having these page templates removed our need to create screens to share design updates because the templates used symbols from our master library. Detailed wireframes only became necessary when either introducing new page types or a major change to functionality.

Conclusion: Provide incremental value because it’s never ‘done’

As I’m writing this article, Percolate Next is about to be released in Alpha to a limited group of customers. We’ve improved the Percolate user experience and instituted a beautiful new UI for our customers to plan and execute their global marketing initiatives.

I like to think that our design system is in constant iteration. The first release of our component library, documentation, code guidelines and principles are packaged nicely in a shared resource and our product teams are actively using this resource as part of the Percolate Next initiative.

Our focus has now shifted to establishing a process for integrating the system into our project plans moving forward. We know that this will be a work in progress, so we’re treating it like any other product initiative. It will involve research, prototyping, and continuous iteration in order to define the right process.

Whilst it feels like a lifetime ago that I worked on the Penske UI project, the audit we did helped guide my approach with Percolate Next. My recent experience has instilled in me the value of planning, vocabulary and workflows. These three lessons that helped us go from an idea for a new product experience, to a living design system that benefits our customers and teams.

Some key screens from Percolate Next

Thank you

This project wouldn’t be possible without the help of some very special people. A huge thanks to the entire Percolate product team, especially Keith Price — Design Director, Lucia Cozzi — Product Designer, Anne Foley — Product Designer, Stuart Eccles — Chief Product Officer, Peter Schrader — Engineer, Max Kostow — Engineer. And a very special shoutout to my editor in chief and all around amazing person, Dom Goodrum.

Also, we’re looking for a passionate, exceptional, designer to join our Product Design team in Percolate’s NYC office! Here’s the info.