A research guide when starting a design system.
Design systems are a hot topic right now. Everyone talks about them and wants to build them. It is evident that software has eaten the world, and design has a major role in this. Undoubtedly, design systems are a much needed help to scaling design and development teams.
“A design system unites product teams around a common visual language. It reduces design debt, accelerates the design process, and builds bridges between teams working in concert to bring products to life. Learn how you can create your design system and help your team improve product quality while reducing design debt“
– Design System Handbook
A huge chunk of design process is often not mentioned, when talking about design systems; design research. This doesn’t mean that teams do not perform research work when creating design systems. However, it is a subject we have to address and establish well in our processes, as our systems mature. Especially when we preach that design systems are about people.
If we integrate a well structured and documented process for design research, we would potentially see more companies adopting methods like this. It could lead to more informed and sustainable environments for teams to mature and grow.
Design Systems are products
A design system is a product within your product line that serves specific customers. Nathan Curtis points out in his article “A Design System isn’t a Project. It’s a Product, Serving Products” that applying well-established approaches for product management and product marketing is a great start.
The point here is that you cannot just design and develop a product; you have to set up processes and a team to run it and market it as well. A design system needs to have a clear line of decision making:
– Teams for heavy lifting on design and development
– Stakeholders that are responsible for things like budgeting and resources (people, tools etc)
– A clear roadmap
All these affect your design system and therefore the products that the design system itself affects. At the same time, there has to be understanding as to which products will use it and when can it be integrated, which parts each product needs, and how you ensure that the design system is well presented and demoed.
“A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem“
– Nathan Curtis
Why some Design Systems fail
There is a plethora of Design Systems out there. Some of them have matured and become the point of reference for teams trying to create their own success stories in the field. But still to this day many design systems are built and forgotten, or fail and get replaced, or become vaguely outdated as products race in a ‘growth frenzy’ tech world. You can imagine the cost of something like this — how wasteful and unproductive it could be.
Many of those failed design systems are an outcome of many pathologies within a company. Teams end up working in silos with no open collaboration or clean ownership, or there is simply no adoption for your newly created design system. A big part in a failing product more often than not, is an improper understanding and lack of research. In this article, we try to remind ourselves of the established research methods we can use in order to build a design system that teams and products will benefit from.
“As with any product design process, it’s important to do your research. (…) Your design system will get used much more often if you create it to fit into the workflow of other teams“
– Jina Anne
Defining your research scope
The process of research in design teams follows the already well embodied research methods of many social science branches such as anthropology, psychology, sociology and linguistics. The choice of research methods depends on the questions a team wishes to answer at the time, but they contain both qualitative and quantitative methods to gain a wide understanding of customers.
– Qualitative research methods: concerned with the human behaviour, and why people act the way they do
– Quantitative research methods: collect numerical data based on users actions.
– Analysis: based on the research methods you choose, analyzing research data can differ. For example, for qualitative results you might consider content analysis because most data is generated in some form of narrative and comments by the researchers. For quantitative results, statistical methods may apply in order to understand and identify patterns in users actions.
It is fair to mention that that many companies that agree to build a design system, will not necessarily allocate dedicated research resources. The tasks might fall in the lap of the people who are actually building the design system, or external help like consultancies.
1. Understand the background
In order to start the research process, background work has to happen. With that work, the research team tries to map the current ecosystem and understand the parts that will be affected by the design system. Once they identify different user groups (designers, developers, and the rest of the stakeholders), they study their interrelationships and at what level they communicate with each other.
It is important to identify potential silos that might exist, and what levels of communication exist among them. This is because design systems often work in the favor of breaking those silos and align teams better.
While studying the teams, the research team can identify and map all the different technologies that teams are using:
– Current technologies used
– Potential solutions that have been studiedImmediate challenges that current/future technologies bring
– Opportunities that can exist with the adoption of more efficient tool set
On a broad scale, they try understand the life cycle of the design system. Where did it start? What previous attempts were made to study the teams? What tools did they use? What lessons were learned? Additionally what does the roadmap for the future looks like, with the maturity of the current products and the addition of future products?
Furthermore mapping the opportunities for adoption, it will be beneficial to understand what are the potential highly used or sought after components that would need to be in the design system first. This will speed up the adoption of such system once implemented.
At this point, the team has written a lot of notes on the observations of the teams, their background, their relationships, and their roadmaps. There should be a plethora of questions coming to mind regarding all that background information. And the next step is to take the questions you have and start planning on interviews.
2. Define the research questions
The team is planning and carrying out interviews with key people from the company teams identified. It is equally important to identify the questions that the users themselves are looking to answer. Those questions and answers will inform how and what things are being built in the future.
Company teams identified
– Designers & developers who will use the design system
– Designers & developers who will build and maintain it
– Marketing & branding stakeholders who will influence it with their vision
– PMs, VPs, CxOs who will manage it and fund it
Basic example questions
– What are your current pain points?
– Without a design system how many hours does it take you to X?
– What would be solved if you had a design system?
– How often do you have to refer to something you did earlier?
– What are the aspects of a design system that help you with your work?
– How should these aspects be delivered to you?
3. Gather data
The research team has gathered a lot of background information. Also they have gained sufficient knowledge of the inner workings of the teams that will use the design system, as well as the stakeholders. They gained understanding on what goes on on their minds, what their pain points are, and how they would want to ideally work with a design system in place.
All that information has been archived and now they have to make sure that everything is gathered together for closer analysis. Everything is on the table. And everything is a valid point at this moment. There is no worry about quality of information; just make sure that every stone is turned. The data is now in a “raw” format, and it does not matter.
Although this step might feel more logistical and operational, rather than creative, it is much needed in a design research process.
4. Analyse data
After gathering the data, it is time to make sure that all information the team has gathered is organized in a way that makes sense.
Data synthesis is the next step and as important as the rest of the steps. It takes the ability to read through different kinds of information bits, understand them, find the patterns, and connect the dots.
Here the research team starts creating clusters of information, and seeing areas of focus emerging. Based on the research and knowledge gained, they can then define the prioritization of tasks and development. Out of all those, they should now have clear actions for the future of the new product — the design system. It is good to remember that this process (research, design, and the building of the design system), is not a one time process. Going back to Nathan Curtis’ comment at the start of the article; “a design system is a living, funded product”.
5. Learn from the findings
The research team has to bring all they have learned together in the end, and present the findings with the ecosystem. Gather feedback, and create a transparent dialogue for what happened, and how to move forward. A design system is a great opportunity for organizational design. And of course it is important to create ways of working that will ensure a healthy environment and a stable basis of product/service building.
The actions that define the next steps have to be done in a similar fashion. A team does not want to release a design system in 2 years, where most of the products would already have changed. They do not want to release a design system in a company setting where information is not flowing between teams. If they do not understand their needs, their design system may quickly become obsolete. Furthermore, they do not want to build a design system where there are no processes in place AND they cannot scale the operations of the work on the system as fast as the rest of the products.
Conclusion
Obviously this is the part where I tell you the right answer is; Your mileage may vary. Treat this guide not as a step-by-step process, but as a reference. Like with any design tool or methodology, it all depends on the dynamics of your teams, the intricate relationships and politics of your company and the willingness of your teams towards change versus inertia. If you do your research well, and understand your users and their needs, you are less likely to fail at building a good system. A systematic approach to design research is never done, but ever involving. Doing it once will not guarantee you success. Iteration is a keyword you should keep at the core of the process. Luckily there are several examples in the field to draw inspiration from. At Clarity in 2016, Donna Chan and Isaac Hayes gave an insightful talk on how to build empowering style guides with practical research.