The three lessons that changed how I think about design systems

Design Systems workshop with Josh Clark and Lucia Cozzi

My first product design job was at a design consultancy in Philadelphia called Electronic Ink, where I helped redesign Penske’s online truck rental experience. Their competitors had a quick and easy process for renting online, requiring just a few clicks in order to receive a quote. Penske on the other hand, took several steps to do the same, resulting in huge drop off rates and revenue being lost to their competition.

As an aspiring young designer, I was eager to redesign the entire Penske rental experience from the ground up. In reality, though, I was a rookie and my responsibilities were limited to auditing Penske’s existing UI and helping senior designers wireframe new concepts. This project would become my first exposure to design systems.

Countless hours aligning components, fixing broken page layouts, and documenting interaction patterns eventually led to a design resource for teams to use. The Penske project took about six months and ended with a very happy client. We were able to cut the users ‘time to quote’ by two thirds which resulted in a hefty increase in online rentals after launch.

However challenging this project was, I am super grateful for having worked on it. It instilled in me the importance of system design for both building and maintaining a digital product — knowledge that I would carry with me throughout my career as a product designer.

The path to my biggest design system challenge

Following the Penske experience, I worked on products with amazing companies like American Express, Deloitte, and Apple, designing everything from mobile applications to enterprise software. I eventually landed at Percolate, a tech company creating software that streamlines how marketing teams collaborate.

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.

Author: Jeremy bloom

Collect by: uxfree.com

Comment

Top