At VMware Tanzu Labs, we take the phrase “meet the client where they are” into great consideration and rarely kick off an engagement where we’re unsure of where the clients are in their project. Even rarer is us not knowing where our expertise can bring the most value to a project.
A proliferation of articles have been written about how to evaluate design systems and their use value in recent years. The common trope is that design systems increase efficiency, streamline workflows, and deliver value for the people who build software, as well as the users of that software. For the sake of argument and for the purposes of this blog post, let’s agree that design systems are a foundational tool to help designers and developers get started and move faster.
The debate about design systems centers around the fact that they can lack flexibility, making it difficult to innovate so as to meet user needs. Design systems usually involve a rigorous review process and often contend with incomplete documentation, while product teams tend to move faster than design system teams. Nevertheless, design systems are a living, breathing apparatus that becomes an integral part of how organizations function and ship software.
However, not a lot is written about how aligning your design system goals with organizational outcomes helps foster balanced teams and a psychologically safe workplace. So how is a design system a reflection of an organization's ethos? That is the journey I want to take you on today.
Just enough context
During a recent engagement, one of our goals was to help a suite of applications adopt and embrace the organization’s design system. Originally, these applications had been designed and built in a siloed environment. The applications became linked together in a shared workflow, so the organization created a portfolio out of the formerly disconnected software applications. The result of this decision was that the portfolio needed seven applications to adopt the design system from the UI front end to back-end code.
My first objective was to understand what stage this initiative was in and how I could best support it. I asked the lead designer to outline the current process and review retrospective (retro) feedback that was recently acquired to gain additional context. In terms of progress, where was design system adoption currently for this portfolio? What would success look like and what did we need to know in order to achieve that success? After listening to my pair and mapping out the current process along with roles and responsibilities, I sensed they were frustrated. The designer had tried many lean experiments that hadn’t produced much traction due to a portfolio-wide directive that took precedence in the organization.
When working with clients and stakeholders on legacy systems and processes, Tanzu Labs often invites teams to participate in a service blueprint workshop to understand the bottlenecks and pain points that materialize. When you frame a design system team and internal individual contributors as its own software product, you can ascertain how the organization is performing and how operative functions can be refined along with your design system.
A design system is a central source of truth for the way your products interact with customers. It’s simply a mechanism for building products where essentially, you’re designing for two sets of users. The first is your customer, the end user of the software. But, you also have teams of individual contributors who need to focus on user needs and creating efficient UX navigation, instead of spending time designing solutions that have already been well researched and tested. Analyzing how individual contributors are interacting with your design system is just one of the first steps to achieving adoption.
Since this organization was having trouble achieving adoption of the design system for its portfolio of applications, it meant our customers (the individual contributors) were not happy with the product being delivered to them. We as the design system team needed to find out where the misalignment was taking place. Was there friction between product teams? How was the design system being managed? Were individual contributors battling internal priorities? How was this design system aiding or hindering designers and developers?
In order to understand this misalignment, we generated a feedback loop by creating surveys and interviewing our own product teams to gain a robust context within these spaces of discrepancy. This type of qualitative research can accompany a front-end and back-end code audit to determine whether developers are utilizing a design system properly. Looking at code provides the ability to operate from a space of neutrality, as spaghetti code that appears congruous makes your organization susceptible to security risks and convoluted vulnerabilities.
In a recent interview, Erika Hall (author of Just Enough Research) offered a reframed perspective of research by saying, “The most important research that you need to do is internal. You need to understand the decision makers (the people who are controlling that aspect of your reality). You need to understand them because, if you understand those people, well then you can explain to them how your work makes them more successful.”
In regards to our engagement, there were a few structural problems:
- There were no comprehensive design system guidelines across the organization, requiring various use cases for different portfolios and components.
- The designers responsible for overseeing proper component usage and guidance for this portfolio were separated from the design system team responsible for developing and designing the UI library for the whole organization. This caused guidance confusion among app teams, who didn’t know who was responsible for design system and consistency-related issues.
- The design system website and Figma library were not sufficient for designers’ needs. Many junior designers were detaching components and engineers were deferring to Material UI.
- Past efforts had included workshops and parallel app component critiques with designers to collaborate on solutions for inconsistencies. This resulted in various new designers wanting to be given a solution because they didn’t have enough robust knowledge about the complex user flow to advocate for their needs.
- Teams wanted to know why certain components were being prioritized; and they wanted to see the data and research for those decisions.
- The design system team previously tried focusing on quick wins, but those wins—according to the portfolio—were not valuable for users.
- There was no consistent accountability and collaboration to track technical action from a product manager and engineering leadership level. This resulted in design system stories sitting in team backlogs without being prioritized.
Measuring adoption
After understanding the current process and bottlenecks, our next goal was to discern some of the granular context that was lost in conversations before my arrival. I spoke with the design systems lead, and they gave me additional feedback and shared their own experiences working with other portfolios to achieve adoption.
We had an ideation session, which involved a dump and sort of ideas on ways we could improve the operations of the design system adoption. We prioritized solutions based on feasibility, risk, and ease of implementation. Previously, the design system lead had measured their progress of adoption for another suite by collecting metrics from developers, so they shared some of the strategies and types of metrics they obtained.
Next, we created a survey for developers, while the rest of the team set up interviews with individual portfolio teams to gain clarity on the data that was uncovered during the retro. The organization had recently hired a new designer to support this effort and needed to learn more about the individual contributors’ pain points. I learned that before this initiative began, the leaders of the organization allocated 10 percent of every team’s backlog to prioritizing the design system. In conducting this survey, we asked teams to reflect over a period of six months:
- How many teams used a design/developer pairing as part of the balanced team?
- Were designers approving completed work in GitHub before it was released in production?
- How many stories were shipped regarding the design system, and on average, what were the complexities of those stories?
- How long did it take to complete those stories?
- On average, how many design system stories were in the teams’ backlogs, and how many were in their iceboxes?
The results of the survey produced some conflicting information. It seemed that on average, the design system stories didn’t take much effort. The majority of the teams had designers approving designs before releasing them to production. Developer–design pairing was evident. The complexity of the average design system story was low. Teams currently had stories in their backlogs and iceboxes tagged as design consistency. One glaring gap existed—no one was there to qualify the code on the back end.
Loss of context
Having worked in the public sector with various organizations, I have noticed a common hindrance that is reoccurring: Turnover! This happens in regards not only to employees, but comparably with users of software as well. This can be a good thing for the latter, but less than desirable for the former. In this case, plenty of contractors in this organization joined teams for short durations, but then all context was lost after their departures. There was a high yield in cognitive ramp-up time to understand domains, information architecture, user flows, and user personas. I haven’t found a good solution for this high churn rate other than staying organized and making sure documented research is readily available for any member of your portfolio and organization. Onboarding is something I realize every organization has difficulty with. Documentation plays a key function in how organizations can grow rapidly and be proficient when employees first join.
Alignment with portfolio
To better understand the users of our design system, we conducted interviews with product teams. Throughout all these sincere conversations, I started to notice some reocurring patterns. The following were some observations we made during these interviews that raised concerns about the fundamentals of a core balanced team:
-
Some designers were having trouble getting design system stories prioritized by their product managers.
-
Individuals who had been on a team for a long time became dominant voices during team discussion. Sometimes this even involved interrupting or shooting down other team members' concerns and suggestions.
- There was no clear direction on which components needed to be updated to be compliant, which led to a lack of communication from designers and engineers.
- One team told us they had lost the trust of their users because of the lack of consistent experience across the portfolio of applications.
- Teams were vocal about stories not matching the output of work, as well as stories needing to be smaller in scope.
- During our remote interviews and design critiques focusing on the design system and consistency, most team members would not have their cameras turned on. This indicated tension in the teams and a lack of cohesion, requiring a team health check to inquire about balanced team fundamentals.
- Product managers were asking for clear outcomes and goals from the design system team to better understand how to incorporate these stories within their current backlog.
- There were some differences in design system methodologies between individual contributors and the design system team as a whole. Some developers viewed the design system functioning as just a UI library, while some designers were designing for problems that the design system addressed functionally.
- Teams were battling design and technical debt. Additionally, the design system library wasn’t efficient enough for the rapid pace that teams required.
During our interviews, we learned that the majority of the teams comprehended and valued the intentions of the design system. They agreed that functionality should be streamlined across applications and that it would save time and effort when shipping software. So then why were teams so resistant to accomplishing adoption across the portfolio?
Another operational gap we found was that portfolio leaders had competing priorities that negated the outcomes and goals of the design system team. The portfolio product manager that was meeting with app teams on a weekly basis communicated (unbeknown to the design system team) that they were not to focus on design system stories. There was a company-wide deadline that needed to be met, so from their perspective, that was the priority. This resulted in a deprioritization of this effort and accountability was lost in the abyss. As you can gather, the more individuals we spoke to about achieving adoption, the more opportunities were available to define clear operations for this engagement's goal and achieving alignment through collaboration, knowledge sharing, and upskilling efforts.
We collected, synthesized, and brainstormed various operational solutions to fill in the gaps of accountability. After collecting this data and presenting it to leaders and involved team members, I had some discussions with the design director about some of the insights gathered during our interviews. I proposed to do a round of team health checks to validate some of my assumptions that there might be some underlying core balanced team issues at hand.
Outcomes
Over the course of two weeks, there were a lot of candid and positive conversations. Teams communicated honestly about things they did and didn’t understand. They also openly discussed the ways they could improve and how they could adapt processes that were not working efficiently. After measuring the results into a quantitative format, I met with leaders of the organization.
The leaders and I met for 1 hour while I went through some of the common threads, questions, and often, the bottlenecks that teams encountered. The leaders were aware of some of them, while others admitted they were not tracking these facets. These were the results of my 6-month engagement:
- The design system team and designers responsible for guidance and consistency merged into one team. This allowed shared understanding of the problem set and the ability to consolidate collaborative efforts to achieve adoption. By combining rituals and meetings, additional time was allowed for meaningful work and less waste regarding responsibilities.
- Leadership committed to improving transparent communication with teams and being more collaborative upstream and downstream within the organization.
- Pairing and enablement plans were set by organizational and portfolio leaders to ensure organizational and portfolio outcomes were aligned and not competing against each other.
- We overhauled the Figma library including sticker sheets, as well as a Figma component audit of individual contributors libraries.
- A weekly open forum called Design System Office Hours was established for any questions or concerns regarding component usages and guidance. This created a collaborative, psychologically safe atmosphere for app teams.
- Design system website structural changes were made to include more nuanced guidance for each portfolio with documentation.
- Designers were offered two months of Figma Fridays for upskilling opportunities. This emphasized time allocated for designers to uplevel their skills during the week, saving resources during onboarding.
- A dedicated development team was formed and bi-weekly meetings were set in order to create a portfolio-wide date and time picker.
Overall, moving our focus from design system to team health was about moving up and down organizational hierarchies to improve the design system operations with emphasis on trust, collaboration, and knowledge sharing. At the end of Q1, most teams were well on their way to achieving adoption of the first four to five components of the design system. A roadmap had been agreed upon by the design director and portfolio leaders with product managers and engineering support. That’s what the best organizations do. That’s what Tanzu Labs is and does. During these types of engagements, we have the ability to affect how teams ship software, how leaders collaborate, and ultimately, how users experience the products we create.
I’ve learned that in a certain light, an internal design system says a lot about not only how your product looks and feels, but can give insight into the organization itself—especially, how an organization upholds values and culture to create better software. To endure, design systems require top-down cultural and operational change, metrics, knowledge sharing, and collaboration.
Learn more
Whether it’s modernizing legacy systems, improving operational outcomes and processes, or building new software, Tanzu Labs is here to enable and support your organization. Learn more about Tanzu Labs and how we are transforming organizations across the world, get in touch with us directly, or join us for our virtual office hours.
