The importance and the priority of having a good design system continues to grow. However, design systems are still not being viewed as a product in many organizations. So, what is the importance of putting a design system into the product category?
Product development teams are held accountable in many ways. There is an expectation that certain things such as features, improvements, or major product milestones will be delivered on a timeline and that there is some measurable outcome. You have a roadmap to help guide you (whether it changes monthly or not) and you are held accountable to deliver things on that roadmap.
Delivering against a design system should be setup the same way. If you want to be taken seriously you should have a roadmap that breaks out quarterly priorities. This should also be covered in employee objectives / goals for those on a design system team. This is a major step in changing how the design system is viewed and will help you think through how you measure success.
Product development teams are often formed to work on a specific feature area, an entire product, or even a suite of products. You would rarely (if ever) see members from across an organization occasionally pitching as they have time to work on a product. It would never work in an efficient way compared to a formed team being held accountable.
The whole scenario of pitching in for product development sounds silly, so why do some organizations take this approach to a design system? This is different than allowing contributions into a design system, so don’t think that this means a contribution model is a bad idea.
If you view your design system like a product it flips your mentality. Creating a design system team is always the most efficient way to drive value. Relying on people to pitch in means that you’re at the mercy of their schedule. If they get hit with a big feature they need to work on, then they’re going to focus on that, and you’ll burn your timeline for a component that may be needed by a certain date.
If you can prove the value of your design system, then you can also justify your resourcing needs whether it’s keeping who you have or expanding the team. If a product team can prove that an investment of $1.5 million will in return generate $10 million in revenue for the company, then they can often get an executive sponsor that will allow them to move forward.
If you treat your design system like a product and prove its value, then you can also begin to make resource requests as needed. If you show that your library packs and templates are reducing the amount of time it takes designers to create mockups and prototypes, then there’s value. If you can show that developers can reduce the amount of time it takes to create a feature because of available components, then there’s more value. You can also take that combined value and talk about how you’re reducing time to market.
Testing your product in various stages will get you the feedback you need to make necessary improvements and ultimately deliver a better experience for your product. We won’t dive into user testing, but we’ll assume most know the value behind doing it.
User testing is often overlooked when it comes to creating a design system. You have several different types of internal users and you also have your end customers that use products consuming your design system. Your internal users are designers, developers, product managers, marketers, and more. They may be consuming all the different parts of your design system, or it could just be one piece such as the guidelines. Testing with these users will help you understand how people are using your design system and where you can improve it.
An example of testing your design is setting up a few tasks for your designers to create something. Have them try to link up to your library pack, find certain components, and use them in their design. This may also include them having to use overrides on those components. If they don’t know how to link up to your library packs, or if they can’t find specific components, then you can identify areas that you can improve.
Design System Maturity
When you place a design system into the product space you show accountability, drive for more efficiency with a strong team setup, strive to show value by setting and measuring key results, and testing your design system to put you in touch with your users to have a better outcome. All of these items will help boost the maturity of your design system. It’s also not surprising that some design system teams have a product manager assigned to them.