Design system programs — overcoming challenges and leveraging lessons learned
Defining and implementing design systems
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 a single champion 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 or target users. 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 manage the design system as a product. It is relegated low priority 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 and align those needs with the design system. The vision and the value of the design system should clearly articulate what the benefits are. 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 on-board 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 would have been left 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 the time 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 to make design systems modular. It is also important that they support different processes, methodologies and technologies. Modules and component could 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 creating a design system. However, in situations where a growing organization wants to scale and execute the vision of building new products, they realize that they do not have the foundation of a design system that can be reused, that can be shared, scale up, and be extended.
At that point, these organizations must understand that they have to slow down and invest in a design system now, otherwise it will take them many times longer to build the new set of products or modules they need. It is a matter of investing the time and effort to create and document the design system as you go, rather than waiting to do it later and having to spend more money, time and resources to get it done.
Key Lessons Learned Creating Successful Design Systems
Always be selling, doing more than talking
Once you sold the value of the design system to one area of the organization, like developers or designer, you have switch gears and sell it to stakeholders. Andrew 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 — always be selling.
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. like 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 compressed amount of time, different team members can easily contribute components to the style guide. At the end of the workshop, the team realizes that they already have a lot of the foundation available and that they do not need to start from scratch. By doing this exercise up front, on day 1, Frost gets the team to understand what they have, showcase it and educate one another on what they need to do next.
A design system is not a single version or a single format
The design system has multiple facets. Many people view it as a code library or a design kit. However, there is training, processes, workshops, and yes, the tool kits.
The team has to develop all aspects of 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 kit 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 have every area adopt the design system at the same time.
Jeff Piazza suggests, for example, that in a higher education 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 identify a department or a program within the school as you define what are the elements baseline elements of the design system needed to showcase the key benefits to the stakeholders.
In enterprise environments, picking a pilot project is important. The pilot project has to be visible and get people in the other side of the fence excited about it and wanting to get in and start integrating the design system. Those teams who show interest 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. The design system team could build a gallery to showcase and share examples of complex problems that those product 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.
It is also important that your design system team identifies the metrics that demonstrate and measure success. The metrics could be defined from an internal perspective like adoption and productivity gains or an external perspective like growth rate.
It is important to document and promote the success stories with business units and product teams that integrate with the design system program. It is even more powerful if you recruit the business unit executives or the product owners 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 approach it as a collaborative endeavor, get others involved, anticipate hurdles, and ensure that our investments in design system initiatives are successful for our customers and our organization.
Acknowledgment
Special thanks to Aquent & VitaminT for hosting the event — Creating a big bang around customer experience with atomic design. To Brad Frost for sharing his wisdom with us and to the rest of the panelist Jeff Piazza and Andrew Browne for sharing their stories.
Share your Design System story
Join the conversation — Share your design system stories:
- Are you involved in a design system in your organization, as part of an in-house team or a consulting team?
- What are your biggest challenges? What are your lessons learned in success and in failure?
- What obstacles have you encountered? How did you resolve them?
