Google’s Material Design, Atlassian Design, and Airbnb Design Language (just to name a few) are great references for designers and leaders, available to anyone interested in borrowing lessons from others with more expertise in the area. However, keep in mind, what worked for one of them will not necessarily work for any organization. Every process is different and every organization is unique: imagine the journeys each one of those teams went through, the roadblocks they ran into, the discoveries they made along the way.
Design-oriented teams frequently make use of design thinking notions in order to build the foundation for the design of digital products. A design system is a product in itself (not a by-product of an app or a website) and it should be structured around the particularities of the organization it’s being built for. That’s why we, as leaders within an organization or as external consultants, planning to get a design system initiative going, need to make sure we start by going through a process that helps us understand a few general aspects that are key in this early stage.
About the internal team
As mentioned earlier, a design system is a product and, as such, it’s created for people to use. Who are these users? do they already exist in the organization or will they need to be hired at some point? What are their strengths and weaknesses? Who’s going to be a contributor and who’s going to be a consumer? Who’s the ultimate decision-maker? Understanding all these nuances, learning about the users and developing empathy is essential. If this product is meant to be defined, built, evolved and maintained, it’s our responsibility to make sure that the organization has the required internal structure, processes and protocols to support that. And if it doesn’t, then that will be part of our job.
About the organization
Design systems are not just established and rolled out. They need to continually evolve and be valuable for everyone in the mid and long term. This requires dedication and organization-wide commitment, so buy-in from leadership is required. This guarantees that the team will have, at least, the required resources to define and maintain.
Sadly, the organizational challenges don’t end there: if the design team sees value in a design system but the product team doesn’t, then there’s a potential risk to be managed early on. Do the different teams see value in a design system? Is the design team aligned with the engineering team? Is there a collaborative culture built into the organization’s DNA?
About the products
A clear understanding of the big picture helps us be strategic from the get-go. Organizations, over time, can grow a collection of digital products, and these products, owned by different teams, become interesting collections of visual languages and seemingly arbitrary patterns. As we plan to dive deep into the complexity of these products, we’ll need to find out which digital products currently exist within the organization and which of these products are going to be supported by the design system. A comprehensive map of this landscape and an inventory of the patterns we find in this process will be our best allies. Knowing the size of the monster will help us and the team come up with the right approach.
Having gone through the points above, one question that we should always ask ourselves is: “Are we solving a real problem or just responding to a trend?” This question is bigger than it seems. Identifying a problem and mapping out the initiative’s objectives in the short–, mid– and long–term is the starting point to help us define a roadmap based on priorities. Design systems don’t need to be robust and mature from day one. They can begin as a collection of principles and loose patterns but can evolve to become more comprehensive and precise in the way every pattern is documented. The foundational characteristics of our design system as well as the scope of the initiative are expected to evolve and adapt over time based on findings made along the way.