Pattern Library & Design System
To promote consistency, scalability, and more efficient delivery of effective, well-designed products, UX teams at companies and organizations big and small are creating their own design systems and component libraries.
Most of the time, there is no official resource to which developers can turn when making design and architecture decisions so they'll come up with their own solutions independently. Or, in the case of legacy applications, they may copy existing solutions from elsewhere in the product that may no longer even adhere to current web standards.
This was during the redesign of our legacy application, it became painfully clear that we needed to establish a central point of reference for future UI design and development. Here, developers could find out how to follow brand standards, how to construct UI components, and how to build an experience that would be consistent, efficient, and occasionally even delightful for our users.
We decided to build our UI design library on top of Salesforce’s Lightening Design System.
OVERVIEW
I designed and led the ongoing evolution of a pattern library for developers and designers on the product team, as well as a brand manual for customer communications. These included:
Branding guidelines (colors, fonts, copywriting)
Detailed explanation of how to use each and every component in the design library
Best practices for everything from user flows to data organization
GOAL
Establish a comprehensive set of design standards and patterns, to serve as a resource for developers and designers working on the application and customer communications.
WHY BUILD A DESIGN SYSTEM?
After every release, it gets overwhelming to constantly “clean up” after other developers to bring their work in line with the design standards I was establishing.
I also found myself trying to remember how I solved problems before, so that I could use components, layout patterns, and user flows in a more standardized way. How did I set up that other form workflow that was so similar to this new one? Did I capitalize this phrase elsewhere? Should this panel be initially collapsed—and didn’t I deal with this before?
I realized our product team needed some central repository or reference system where we could document and retrieve:
reusable components and templates
plugin documentation
frequently used page layouts
guidelines for UI elements such as form inputs, data grids, and modal dialogs
A DIFFERENT SET OF USERS
In this project, I faced a new challenge—the users were my own colleagues (developers).
A few months after introducing the pattern library to the development team, they were successfully using the patterns, but my team often found ourselves doing quite a bit of reworking when we conducted our “UX review” on their work.
I addressed most of these issues by patiently sitting with developers on a one-on-one basis when I knew they’d be using the pattern library for a given case. I talked them through the steps of deciding, for example, which grid column widths to use for a given form, or whether radio buttons or select drop-downs made more sense in a certain circumstance.
After doing this once or twice, I found that a developer seemed to adopt a more conscious way of making UI decisions and even make requests for new component use cases and examples to be added to the pattern library!
SOLUTION? Crafting a system that fit our particular needs
After the pattern library had been established for awhile, component libraries and design systems seemed to become a pretty hot topic in the UX world, so I took some time to study some comprehensive and well-known examples (Salesforce, IBM, 18F).
Right away I realized there were a few key differences in how our pattern library should be used, compared to these large enterprise-level implementations.
This meant providing more comprehensive “page template”-based patterns, rather than presenting a buffet of all the possible components including button variations, font sizes, etc.
