Thinking design systems

- When it comes to building a platform or redesigning a product, there are many things to take into account. Yes, you need to make sure your designs are solving problems for your customers. And yes, you want to design the most beautiful experience they've ever seen. But there's a little more to this picture. How is your design going to be sustainable as you scale up your team from 10 designers to 50? Or, even 100? In this episode, I'll discuss what design systems are and how they can help you scale your design organization. I'll also give you some insights of why planning the system up front, can you save you and your engineers time and money. Let's begin. You might have heard the term design systems, or maybe you've heard of a pattern library. These are the building blocks that will help you design your product. These are the guidelines that help you stay aligned with your team and beyond. Why do we need design systems? We need design systems to help design, product, and engineering speak a common language during implementation. For example, if one team has been working on a video player that can be used across the entire platform, every team should be able to leverage what was built. Another example would be creating a component. A component is a module on the page that consists of a certain level of functionality. This could be a social share component that lives across all pages, or even a search type head, or car design, and the list goes on and on. You can see a list of typical components by downloading the exercise files below, named Component Checklist. This can give you an idea of typical components, you'll want to consider. So, how might one decide whether or not you need to build a component? It comes down to a few determining factors. Could other teams leverage the functionality? Could this feature or component be used in more than one place? How much effort is it to componentize this feature? If it's multiple weeks, then you'll need to rationalize if it's worth it. This is an incredibly difficult decision to make. However, it can easier by determining where your product is at in its lifecycle. For example, if you just started on a new product, and your design patterns and core functionality have not yet stabilized with your user base, you might want to consider moving fast, breaking things and settling in to an experience. This way, you could potentially get your feature out two to three weeks early, learn, and iterate. You might want to consider doing this before investing in a longer term strategy of componentizing your features. Work with your product and engineering partners to make this decision. Let's jump back to the overall design systems and discuss how designing systems can help your design team both big or small. Having a universal design language that each designer can contribute and utilize is essential. We all strive to have consistency in our user interface, regarding typography, grid, visuals, or even voice and tone. Building a design system helps establish these. When you set these guidelines upfront, you can empower your team to move faster, smarter, with a shared perspective. You can also take into account best practices and implement your solutions with accessibility in mind. This can be a core part of how you and your team design. Once you have a system in place, you can also iterate from one source of truth. This way you don't have two or three teams working on something incredibly similar. You find out that each team cannot benefit from each other's hard work in user testing or iterations. When you have a design system in place, all can contribute and all can reap the rewards together. But design systems can not only help your design team, it will help your engineering team thrive. Nothing is more powerful than a common CSS language that your engineers can leverage, or even a common list of components that they can pull from a library when they need to. Engineers love pattern libraries and design systems, because it's something they can plan for and utilize. They won't have a bunch of one-off requests and inconsistencies that they have to keep going back and forth with design on. This reduces bugs and helps time to market. They also love it because they can build components that consider accessibility, tracking, and localization up front, saving everyone time and energy. We talked about how systems benefit designers and engineers, but what about the customers? Customers get to see a common and consistent experience. They might see a blue button for primary actions and they will see that same blue button throughout the site when they have an important action to accomplish. They'll see a common interactions as they browse from page to page, or from device to device. This is leveraging your design system. It truly helps everyone win. I just captured some benefits of creating an amazing design system. However, I want to leave you with a few things you should look out for before you jump down this rabbit hole. Design systems are meant to evolve. Don't get stuck on the same solutions and visual aesthetic or it will be difficult getting designers to want to design on your team. If a pattern works, don't redesign it because you can, consider accessibility, form, and function. Design your components to be responsive. If they look great on large displays, then you're missing the point of having component in the first place. Test before you componentize a pattern. Put your design through rigorous user testing and validate them before spending the effort to build. Create a system to disperse, organize, and manage your pattern and component library. For examples of these in the wild, check out Bootstrap, Google Material Design, and Microsoft's Fluent Design System. If you'd like to continue the conversation, or have more questions about design systems, then I'd love to discuss them with you. Find me on Instagram @abridewell. Tweet at me @abridewell. Or, you can post a question on our Practical UX Weekly LinkedIn group. Thanks for watching and I look forward to seeing you next time.