From the course: Practical UX Weekly: Season Two

Design systems: What they are and what they do

From the course: Practical UX Weekly: Season Two

Design systems: What they are and what they do

- Our world has become more complex. We continue to have new devices and new services, which means more people with a rich set of devices to design for, along with a larger population to support. This gives product creators even more responsibility in this day and age. And it doesn't feel like it's going to be slowing down anytime soon. Voltaire, French philosopher and writer during the Age of Enlightenment once said, with great power comes great responsibility. Well I like to say, when complexity is in your life, design a system. Design systems can come in many shapes and sizes, but the system I'll be talking about here are the ones that you'll use to help you move faster, reduce duplicated efforts, leverage your team's thinking and solutions, as well as the ones that drive the biggest impacts, especially when you're dealing with scale. This week we're going to talk about design systems, what they are and what they can do for you. Design systems are not just patterns on your product that you drag and drop into a design program. They're a way for your to reduce risk, move faster and smarter. And they're also a way to think about systematizing the tasks that you complete over and over. Consider the fact that hundreds, maybe thousands of decisions were made with the best intentions for the product that came before your time. However that doesn't mean they were systematic decisions. What do I mean by that? The big question is, were those decisions, that were made in the past, decisions that not only had the company's best interests at heart, but also the best interests of its most valuable assets, the people. Each and every one of these decisions affect the company's experience, as well as the people who are going to continue to evolve it. When you're building a product that will serve hundreds of thousands of people, you need to start thinking systematically. Design systems help you do this. Have you ever thought to yourself, how can I make a difference in my big company? I'm just one contributor. And how could a design system help my business? A design system is a unique language that a company generates to enable its employees, business, and customers to operate better, smarter, and faster. It might be obvious why you would want that, but let's break it down anyway. Let's first talk about startups. When a company first starts out, they're developing, designing, and strategizing, about how to get to the core minimal viable product that is a delightful experience, and in the quickest possible way. Designers are thinking about solving problems. Engineers are thinking about writing code to support the concepts. And the product manager is working hard to make sure it all comes together on time, while being thoughtful about if it's solving the correct business problem, and everyone is trying to measure the impact. What ends up happening a lot of times, is the team needs to get their product out as soon as possible, and throughout the process it's common to skip a few necessary items, like cutting some priorities to get the feature out. They might skip the following: organizing the design file, project documentation, or having that extra code review. Each one of these skipped items will end up having an impact on the next person who needs to pick up the project. What this does is it causes you to have to go back, spend hours trying to package it up, wrangle multiple people to find out who did what, and when they did it, and if they had any research at all. This is not just a problem of lost information and misplaced insights, this causes the company to make similar mistakes over and over again. This causes turmoil, frustration, and anxiety, because now designers are spending time playing Where's Waldo, and where in this case, Waldo is just information. This is something that can be remedied by a more holistic approach to building, designing, and documenting. With design systems you can make this a more frequent habit because you can make it a part of the process. And we have the ability to set clear expectations about the responsibilities in our role, so we can document and share our insights, our work, and the thinking behind why we made it. Teams also have gotten into the habit of segregating their roles and responsibilities almost like they're playing the board game Monopoly, when they have to take turns and continue working around a square board. Working hard to collect that $200, which in product land equates to completing that feature or completing that project. But creating a product is not a game. It affects millions of people, and the fact of the matter is, it also affects us, and the team that was creating the experiences. The design systems we build need to embody a feeling that is warm, inviting, understandable, and supportive while offering an effortless user experience. Now let's look at the enterprise. Depending on your complexity, a design system for an enterprise product needs to be thoughtfully resourced to have a better chance of succeeding. Design systems can generate behavioral changes. If you create a button group component and the primary call-to-action button is always on the right across the entire product, you are naturally training your customers to expect the primary buttons to consistently be there. You're training your engineers that the button group is a component, and it will need to be reusable, which changes the way they need to write the code correctly. You're training your designers to understand the primary button to the right of the group has tested better and they don't need to waste time debating where it should go. Every one of these decisions in your system is thought about carefully. These decisions you make have systemic effects even if you haven't reached scale in your company, which by my definition, scale is not only the size of the team your work with, but the size of the customers you serve. In this example, let's say you serve 100000 customers and have a team of 20 designers, 150 engineers, and four product managers. Just between these three groups you have 174 people. That's not including legal, marketing, product marketing, sales, support, and customer success. In two weeks time this group may have the following happening, kick-off meetings, research, decision-making meetings, working time, design reviews, user interviews, coding, code reviews, and the list can keep going. Given a typical 40-hour work week, that's almost a whopping 14000 hours spent working. Consider what could happen if each of these hours were spent working on the same thing. Let's just say we take away 4000 hours because two of the teams ended up building the same element. So now we're at 10000 hours, and then we realize a month later that we needed to combine those two experiences because priorities shifted for our customers, and the experiences needed to be consolidated. We sort of knew this was going to happen but we felt like we just needed to build it anyway. That's another 3000 hours gone, because the team that was building the experiences had to eliminate the tech debt that had been created, alongside integrating the new variations that the other team had created. Remember, when you're working in the enterprise and need to make some larger-effort updates, it's usually not a quick fix. These massive problems are due to the poor systems thinking and design language in place. It's up to the team to start thinking about these things ahead of time. And you can't always catch it but you need to be mindful of it. Scaling your efforts without a design system is like driving a car without a transmission, once you get it going it needs the ability to automatically function. You don't want to have to do a massive amount of manual work, every time you need to improve it. A governance model can help with this. The governance model is a shared understanding of how the team will work together. The governance framework you establish is a team decision. It affects everyone and when a decision affects the team, it should probably be decided with the team. A governance framework consists of establishing shared expectations of how we operate, learn, and grow, and for it to be successful it needs to be co-created, and then welcomed by the company. Typically when there is no governance model of your system in place, it will result in having many different processes and solutions for similar outcomes. This defeats the purpose of having a system in the first place. When there's a pile of teams working on a ton of different solutions, it's important to be thoughtful, and try not to assume that they're all going to work together magically. It's not realistic for a business to put one single person on a design system to be tasked with everything it takes to put together a visual language of practices, processes, and patterns that service the entire company and its customers. This is a team responsibility. One final thing I want to leave you with. When you've put on your design thinking cap, try to be mindful about the environment you're creating, not only to make great experiences, but to position yourself and your team for a successful outcome. Remember, you're not only training your customers on behavioral patterns through your design system, but you're also designing the behavior of your team of designers, and engineers, and your company as a whole. If you have more questions about what design systems can do for you, then check out this article I wrote on InVision's Inside Design blog. It's called, The Value of Investing in Design Systems. You can also find me on LinkedIn, Instagram, and Twitter @abridewell, or you can join my Practical UX Weekly LinkedIn group. Thanks for watching and I look forward to seeing you next time.

Contents