This article was originally written for Wolters Kluwer and published on February 2018.
Today, many larger companies have built their own custom, in-house design systems. Airbnb, Salesforce, Google, IBM, Uber and Atlassian have all built comprehensive systems that keep the design of their products in check. At Wolters Kluwer, the GPO UX team has started working on a design system as well. In this article I want to give you an overview of where we are and what challenges lie ahead, but first it’s good to give you an understanding of what design systems are, how they emerged and why we need them.
What is a design system?
The term design system is used to describe a philosophy that encourages designers to define the rules of their designs as instructions that can be used on more than a single product. This sounds complex but it can be easily explained using Legos as an analogy. You can build freeform with Legos and create to your mind’s limits, or you can build a car from Legos using a guide that has a system and a design language that you can follow. Design systems help you achieve the latter.
Design systems marry two concepts, making something more powerful than its separate parts: standards and components. Defining the purpose and style of color, shape, type, icons, space, and motion is essential to creating a brand aligned and consistent user experience. Without standards, decisions become arbitrary and difficult to critique. Not only does this not scale, it creates an inconsistent and frustrating user experience.
Components are portions of reusable code within your system and they serve as the building blocks (Legos) of your application’s interface. Component-based development reduces technical overhead by making code reusable. Only using components, without standards, is the same as sprinkling Legos all over the floor. Sure, you have a lot of solid pieces, but since there is no context there is no guarantee that the car will be built right.
Standards govern the purpose, style, and usage of components. Together, you equip your product team with a system that is easy to use, and you give them an understanding by linking the what with the why.
How did we get here?
Simply put, a design system is useful for when you need to design not just one thing, but a whole set of things that you want to feel like a coherent family. This concept is of course nothing new. Many design systems have been created over the years, from NASA’s Graphics Standards Manual to Google’s Material Design.
You can trace the concept of a design system back to the early 20th century. Bauhaus and De Stijl originated as design philosophies in which artists, designers and architects operated by the same concepts and produced work that systematically fits together as one, both aesthetically and conceptually.
Swiss designers from the 1970’s explored the idea of a design system even further, such as Karl Gerstner who wrote the book Designing Programmes or Grid Systems in Graphic Design by Josef Müller-Brockmann, which provides directions for using grid systems to work correctly on a conceptual level.
So, instead of designing a logo for an organization you might develop a visual language for representing that organization in all sorts of different contexts. What is new is that today design systems can be more than printed design manuals. We have the ability to write design systems in code and use them directly in our digital products.
The benefits of a design system
Without a design system in place it’s like placing band aids on to fix a product – products lose consistency and they get confusing and dense as time goes by. One of the biggest headaches when leading digital design teams is ensuring consistency across all the products that a company owns. Design systems can help ensure consistency across platforms on a global scale.
Many designers work with traditional design tools and the finished designs are then delivered to a development team for implementation. This creates a waterfall process that might not seem bad when starting a project but is really unhealthy for the later stages of a project. A design system can fix this by introducing healthy habits for software development.
Design systems are also very effective at standardizing interface elements, which allows designers to spend more time on features that actually matter. If we need to spend time on redoing the same interface elements over and over for different pages, we have less time for rethinking the key elements that actually matter. Design systems free up resources, allowing designers to work on stuff that matters.
Last but not least, standardization of interfaces is a good thing for users. Design systems ensure consistent interaction patterns.
So, where are we right now?
Our ultimate goal is to provide an umbrella, an overarching system for all of Wolters Kluwer’s digital products and services. We have hundreds, probably even thousands of products, so this may seem like a daunting task and it probably is.
When we started building our design system we focused on our guidelines and standards first. We started with our design principles and worked on the foundation – the grid, our color palette, typography, and branding guidelines for products. In the future we want to look at other fundamental things such as voice and tone, writing style and motion.
As you may know, GPO provides business units with a comprehensive component library, but for a design system to function properly, the standards and components need to inform each other. Currently, our components are too far separated from our standards and we need to bring them together.
In order to do this we are bringing our standards, patterns and components together in something we call the Reference Application. We are building the Reference Application in parallel to our efforts getting our design system off the ground and it will be a framework containing our best practices in UX and showcasing GPO’s technical capabilities.
There are still quite some challenges we need to address in the near future. One challenge we’re facing is how to determine what patterns to include next. When we started, we picked the patterns we know best: search, search suggestions, various document views and SEO patterns. For the long term, however, we want the system to include patterns of other types of products as well. There are transactional patterns, patterns specific to the health market, marketing patterns and many more.
We don’t want to be pedantic and claim to be experts in areas we are not heavily involved in. We have fine UX people spread across our organization who are specialized in specific areas. We need to reach out to them and partner with them, but we need to determine the best model for optimal collaboration.
Today, many businesses are investing heavily in design as they recognize that the customer experience of their products offers a competitive advantage, attracts and retains customers, and reduces support costs. Furthermore, organizations are striving to get things out the door quicker. By creating minimum viable products and shipping often to iteratively improve the experience, organizations are able to better address user feedback and keep up with the ever-shifting web landscape.
This comes with many challenges. How will you design consistent user interfaces across platforms when many teams own various parts of your products? How will you empower all of these teams to iterate quickly? How will you maintain the inevitable design debt that will build up as many designers create new and tailor-made designs? In order to confidently face these challenges, the need to create thoughtful design systems is becoming more apparent than ever.
If you are interested to learn more about design systems, I recommend reading the following articles:
- Building a large-scale design system: How we created a design system for the U.S. government. Maya Benari.
- Creating a Design System: The Step-by-Step Guide. UXPin.
- Solving Fifty Shades of Blue, or how we built our design system. Kristy Marcinova – Intercom.
- The User Experience of Design Systems. Rune Madsen.
- Design System Handbook. Invision.
- Atomic Design. Chapter 1 – Designing Systems. Brad Frost.
- Starting a Design System. Nathan Curtis.
- Things you could be doing instead of designing & building that card component for the umpteenth time. Brad Frost.
- What is a Design Language… really? Nate Baldwin.
- Designed for Growth. Marco Suarez.
- The Way We Build. Alex Schleifer – Airbnb.
- The full stack design system. Emmet Connolly – Intercom.
- From Pages to Patterns: An Exercise for Everyone. Charlotte Jackson.
- The Language of Modular Design. Alla Kholmatova.
- Github’s Design System: Interview with Diana Mounter. Jerry Cao.
- Design Systems are for People. Jina Anne.
- Design is Never Done. Nicholas Jitkoff.