Design Systems at NaviNet and Toast
I was brought into both NaviNet and Toast to build a robust User Experience discipline from the ground up. One of the first things my teams and I did was create a Design System, recognizing that this was a critical piece of any mature UX organization. We constructed an initial set of patterns by breaking down our most recent product designs into identifiable, common components. Our goal with this library was consistency, standardization, and clear, transparent design direction that the entire organization could leverage. These design systems were used everyday by the UX team, engineers, user acceptance testers, product managers, solution architects, and marketing folks. They became the official reference for UI design that all our products adhered to.
The Project Story
Why a Design System is So Important
In a mature product organization, a design system is critical for socializing design standards, while simultaneously strengthening brand and unifying the customer experience. It gives products a common thread and an identity that users find familiar, as well as comforting.
Such a system ensures that design decisions are captured and consistently applied across all product interfaces. It allows both interactive and visual design standards to be transferred from the designers’ heads into a publicly accessible vehicle.
Inspirations and Competitive Analysis of Other Design Systems
When we started to build out our own design systems at NaviNet and Toast, we looked at quite a few well-known, public design systems that have already been established. Our goal was to determine the best way to construct each pattern, including all the definition sections that they should contain.
Evolving Best Practices, Design Trends, and Conventions
A design system is meant to be a living, breathing reference that continuously evolves along with an ever deepening understanding and empathy of the organization’s users. It is a moment-in-time snapshot of what the User Experience team considers to be best practices for web and mobile interactive design. As trends and conventions shift, or as new UI interaction scenarios are identified that the current patterns can’t sufficiently support, the system must be expanded or modified, rather than just taking any existing pattern and trying to squeeze a round peg into a square hole. New proposed patterns should be analyzed, debated, reviewed, and usability tested within realistically applied contexts before they are added to the design system.
Key Aspects of a Design System
In order to achieve buy-in and successful, cohesive adoption across an organization, a design system must involve cross-functional collaboration across all departments. Marketing must weigh in on branding, voice, tone, and editorial writing style. Product owners must ensure that the design system supports their strategic vision, as well as iteratively schedule the required UI work into upcoming epics and sprints. Engineering needs to be able to build the specified components and keep their CSS up-to-date with the design system style guide. Along with ongoing UX research, account management, customer support, and sales teams need to continuously provide voice of the customer feedback that they are receiving, so that the design system can evolve accordingly.
UX Software Toolkit
It is important for the UX team to strategically put together a robust software toolkit that supports the entire user-centered design process. As a manager, if I don’t have buy-in from my team on these tools or they don’t understand how and when to use them, we won’t be nearly as efficient, effective, or consistent in our work output. These software applications need to seamlessly fit into the broader IT ecosystem across Product, Engineering, and Marketing. This is key for cross-functional collaboration in terms of access to materials produced and minimization of redundant work. Our UX processes and workflows need to be compatible with the full software development lifecycle.
The software tools we use for prototyping and even the design system itself need to offer interactive, cloud-based deliverables that are always up-to-date and highly accessible to everyone in the organization. They must support collaboration, conversation, and a persistent historical record (e.g. version control in order to quickly see what has changed across two prototype iterations).
UX/UI Inventory (Audit)
When we first constructed the design systems at NaviNet and Toast, we started by doing a meticulous audit of the current product interfaces, taking inventory of all existing patterns, identifying inconsistencies, gaps, and opportunities for design improvement. Of course, this comprehensive heuristic evaluation and UI audit exercise was paired with user research (e.g. contextual field studies and usability testing) to better understand what users need, expect, and currently struggle with.
Visual Design Style Guide
I worked closely with my lead visual designer to piece together a style guide that included all critical look and feel aspects of our products, such as grid definition, color palette, typography, icons, and graphics. It also provided detailed style specifications for basic UI elements including buttons, form inputs, dialogs, and other common screen components.
Interactive UI Design Pattern Library
At the core of any design system is a library of UX-validated interactive design patterns. The libraries we created contained over 100 patterns. They were divided hierarchically into various categories, such as form elements, navigation, and help/status. Each pattern was given a status based on how much of our prototyped design had actually been implemented in real, live code.
Examples of UI Design Patterns
Here are just a few simple examples of UI patterns that we had in our design system library at NaviNet. A pattern can be as small as a field label or as large as a whole search form. Often more complex patterns are made up of multiple simple patterns, following the principles of “atomic design.”
The Anatomy of an Interactive UI Design Pattern
Each pattern in our library contains an overview section, as well as various configuration options and a list of related patterns. We describe what problem the pattern solves, when to use it, how to use it, and why it should be used. We also detail any accessibility concerns, such as keyboard only support, and we list any inspirational sources or article links that discuss this sort of pattern.
Interactive Demos and Visual Style Specifications
The most important part of of each pattern is the interactive demo. If a pattern has been implemented in actual code, we provided an example that users can play with. We also provided a demo of the fully functional Axure prototype that illustrated how the pattern should ultimately look, feel, and behave. Finally, we provided in-context CSS style information for all elements contained within the pattern. The user could rollover various areas of the pattern in order to highlight the CSS specifications for that element. Recent design system management tools such as Invision and Zeplin have made documentation of these specs much more automated, dynamic, and easy to communicate.
Complementary Interactive Component Libraries for our Primary Prototyping Tools
We created corresponding interactive Sketch and Axure components for each pattern in our design system pattern library that accurately emulated the pattern in all key respects. As we evolved the patterns in the library, we also updated these prototyping components in tandem. These libraries of pre-built widgets made it incredibly easy for anyone to quickly construct a highly functional user prototype, while still adhering to the look, feel, behavior, interactivity, and best practices defined in the design system. Such coordination of libraries helped ensure consistency across all user interfaces, as well as a cohesive, predictable experience that customers most certainly appreciated.
Editorial Writing Style Guide
I worked with marketing and the documentation team to come up with a editorial writing style guide. This helps designers and copywriters conform to consistent language usage when producing UI labels, instructions, and any other copy that exists within the product interface, marketing website, or other published, customer-facing materials. This guide included clear examples of what you should and should not do when writing copy in various scenarios.
Tone and Voice
Voice and tone are often thought of only in terms of written copy, but it also can be expressed visually and audibly as well. Above is an example of voice and tone represented through a friendly bootup animation/jingle, created by my awesome lead visual designer at Toast.
On the surface, it may seem like a trivial thing, but defining a set of naming conventions and organization standards across files, folders, Sketch/Illustrator artboards, layers, symbols, styles, and prototyping component elements, can save a lot of headaches down the road, especially as a UX team grows larger. It helps when one team member needs to step in on a project and continue the work that someone else started. It also ensures that resources and materials can be discovered, reused, and leveraged across the entire team with little effort.