Nowadays many organizations embark upon a design system project. Some view it as a silver bullet to address experience issues, while others see it as a way to optimize their development process, save time and money and ultimately deliver a consistent user experience. However, even in the most successful journeys towards a production-ready design system program, there are many pains and struggles that teams face.
In a recent event hosted by Aquent & VitaminT Brad Frost delivered a presentation on Atomic Design. Following the keynote, Brad moderated a panel, where Jeff Piazza, Andrew Browne, and I discussed some of the biggest challenges we encounter creating, building and working with design systems. We shared perspectives from different viewpoints including the enterprise, agency and consulting environments.
Key Challenges with Design System Projects
Lack of executive support
In complex environments, an executive champion is critical, but it may not be enough. There are many political forces that come into play where a coalition of executives across different functional areas and business units need to come together to provide strong support, remove obstacles and get their teams behind a design system program. In a Fortune 500 organization, a Global CIO told his leadership team — “the question is not if we are implementing this program but by when.” This level of support is important, and by extension, having C-level support in different business units increases the likelihood of adoption and reduces the resistance barriers.
Design systems are not just for the design team
As designers, we may be accountable for the readiness of the design system, but we are not single owners. The fact that the word design is included in the design system’s name, does not equate to what designers do and what designers own. It is our responsibility as design leaders and practitioners to ensure that all disciplines in the organization understand that they have an ownership stake in the design system. It is important to create a sense of alignment, understanding and shared ownership for designers, developers, product managers, and stakeholders.
Design system is treated as a “nights and weekends” project
Some organizations do not treat the design system as a product. It is relegated as a side project that a single person or a few volunteers can take on as a side project. In perspective, when this is the case, the design system cannot respond to the demands of the organization to scale, add components and evolve to support a wider set of needs. In addition, if there are issues in production associated with the design system development libraries, someone has to be responsible for addressing them.
Lack of communication and participation
As designers, we need to listen and understand what are the pain points and the frustrations in the organization. The design system work should be disseminated across the organization in a periodic manner. In some companies, the team responsible for the design system would organize periodic meetings including weekly development meetings to address issues, monthly updates to the community at large, and regional summits around the world to onboard and train teams in the different aspects of the design system program.
Managing the Design System as a closed project
Some of us have been guilty of this problem. We treat the design system as a “restricted area — authorized personnel only.” This is an easy path to create resistance in an organization, if not the full rejection of the design system.
In the early phase of a design system project, I partnered with a Technology Architect who was critical in getting the development assets of the design system “production-ready.” In addition, this partnership was instrumental in training, communication and also in creating the managed open source community that contributed and helped address issues we encountered along the way. If we would have continued with the “restricted area” approach we started with, we had ended up with a very expensive design system shelf-ware, gathering “cyber dust.”
The Chinese menu approach
One common organization antibody to design systems is the attitude — “it is not invented here.” From that perspective, designers and developers who were not involved in the creation of the design system believe that they can produce something better so when it comes to adopting the design system, they only take parts of it. In a similar manner, when you are in a Chinese restaurant in the US, you ask for items 1, 5 & 10 in the menu. The team would decide to take some components of the design system, and replace the rest with some they created on their own.
This “create & replace” approach diminishes the value of the design system for the organization and undermines the ability to grow and evolve it. It also introduces potential issues of code conflict and maintenance.
It is important to invite participation from different areas of the organization early and often. It is also critical to welcome contributions to design patterns as well as development libraries.
One and done
A development executive told me “we have the design system now, we are done.” The executive wrongly assumed that teams adopting the design system would automatically have (a) compliant UIs with the “standard”, and (b) usable UIs. Do we think that we do not need to do any new UX research in products that are created based on a Design System?
This is probably as far from the reality of today’s digital products. Design systems are built to evolve and with the change in today’s technology, it is fundamental that design systems are modular. It is also important that they support different technologies, that component can be plugged in or simply replaced to account for the demands of the products that integrate with them.
Design System is busy work for an already busy team
Many teams, from startups to established organizations, consider that shipping the product is a higher priority than the design system. However, in situations where a growing organization wants to scale and realize the vision of building new products, they realize that they do not have the foundation of a design system that can be reused, it can be shared, that can scale up, can be extended.
At that point, these organizations realize that they have to slow down and invest in a design system now, otherwise it’s going to take them many times longer to build the new products or modules they need. It is it is a matter of investing the time and effort of to create and document the design system as you go, rather than waiting to do it later and having to invest more in terms of money, time and people to get it done.
Always selling, doing more than talking
Once you sold the value to one area of the organization, like developers or designer, next thing, you have to sell it to stakeholders. Andy Browne says that you have to always be proactive in reaching out to different areas of the organization and be ready to pitch the value of the design system.
As a team, it is important that you are able to define the vision in a manner that it is easy to communicate and share within your organization and if necessary, with investors or analysts. A short video of the new experience you are building the integration of multiple products into one, or the creation of reusable components, will help you get support and buy-in for the design system.
Getting started with the design system
It is important to identify and outline what are the key elements of the design system. Brad Frost shared his approach with the Style Guide-Driven Design System. In a two-day workshop, you can get a cross-functional team in an organization to fill in the blanks of the style guide outline with existing assets that are distributed and not readily accessible. In a short period of time, different team members can contribute to components to the style guide. In the end, the team realizes that they already have a lot of the foundation, to begin with. By doing this up front, on day 1, Frost gets the team to understand what they have, showcase it and educate one another on what may need to be done next.
A design system is not a single version or a single format
One thing that is critical is that the design system team has to get the design system available in many different formats and disseminate the information in many different ways. Each different persona that uses the design system can adapt it from different entry points. For example, the design system team may need to make the design system library available in many different libraries like Adobe Creative Cloud (i.e. Adobe Illustrator or Photoshop), Sketch, InVision, and production code in a development toolkit.
Identifying a Pilot Project
In large organizations, when you have a few hundred applications, or in a higher education institution, where you have the university, the schools, the departments. you would not try to do everything at the same time. Jeff Piazza suggests that in a school when they have specific priorities, you have to learn what those are, learn about the terminology and about the components that are important. You work with the team to define what are the elements that would create enough of a system to enable the stakeholders to understand what the design system is what are some of the key benefits.
In enterprise environments, picking a pilot project that has visibility, that gets the people in the other side of the fence excited about it and wanting to get in is important. Those teams are great candidates to be picked as the next projects in the design system program.
Streamline the prototyping process with Design Systems
For some designers, the quickest way to prototype is the best way to prototype. However, in many instances, those quick prototypes are not easy to test because they lack some functionality. An approach is the “one-hour prototype” concept to sell the idea and do some quick testing.
Jeff Piazza says that we need to have a clear idea as to what exactly we want to get out of the prototype and what we want to learn. By knowing this, we can determine what is the right tool and the right approach to prototype.
Andy Browne highlights the fact that the design system frees the team up to test the actual product, rather than worrying about the details of the component. For example, the team can focus on designing and testing the call to action that makes the most sense to users, rather than the rounded corners or the gradient of a button because those are already addressed by the design system.
Getting the Design System to appreciate in value
As your organization adopts the design system, it is important to showcase the products that integrate with it. You could share examples of complex problems that those teams have solved, share the code assets and the design libraries that they used, so that others can reuse them, extend them and build upon them.
The design system should always be power other products and systems to add value to your organization. It is important that your design system team identifies the metrics that demonstrate whether the design system is successful or not. Those metrics could be defined from an adoption perspective to the productivity growth rate.
It is important to document and promote the success stories with product teams that integrate with the design system program. It is better if you can get the product owners or the business unit executives to promote that success story for you.
Forging the path
Embarking on a design system program is not easy, and requires a lot of work on everyone involved. It requires trust and support from the executive team and a substantial investment of time and money for the entire organization. As design leaders and practitioners, it is our responsibility to make the process anticipate hurdles, get others involved and ensure that our investment in these initiatives is successful for our customers and our organization.