Leveraging internal research to gain design system buy-in

Examples of systematically poor design wasn’t enough to convince all stakeholders that we needed a systematic solution. The following is a story about leveraging internal research to build a case for design system investment.

Role: Interview Facilitator, Product Designer

Year: 2022

Collaborators: Than Sidwell, Matt Donovan

Duration: ≈ 1 month

I was excited to join Buildertrend's design system team. I previously worked on designing experiences within our core project management features, and in my time on that team, I noticed a pattern of inconsistency that resulted from a lack of guidelines and guardrails. A design system could remedy that inconsistency. We used examples of this inconsistency to sell the idea of creating a design system to most of our product leaders. However, some technology leaders still needed convincing that a design system was the solution.

Pictured: examples of granular inconsistencies. There are three different components for marking an item complete.

The To-Do's feature uses a check-circle

The Purchase Order feature uses a toggle button

The Lead Activity feature uses a checkbox

Pictured: Examples of higher-level inconsistencies. Layouts are random. Container width is varied. There are no rules when it comes to the amount of primary actions.

Schedule item modal

Bid package modal

Schedule item modal

Change order modal

The general pushback to highlighting examples like the ones above as evidence of a need for a design system was straightforward, "Why do we need a design system to fix that? We just need to be more careful."

By yourself, that's a tricky question to answer and a difficult point to argue. Simply describing the personal experience of designing without guidelines or clearly defined reusable components can be dismissed as anecdotal.

We needed a more comprehensive understanding of the internal design and development experience to make a case for a utility we believed would improve internal processes and trickle down to the end user. We needed user feedback on the existing internal design and development process.

Gathering user feedback

Our team decided to conduct internal workshop interviews with groups of Architects, Developers, Designers, and QA Testers. The questions we planned to ask them were simple.

• What aspects of our design and development workflows work well today?
• What aspects of our design and development workflow are not working well?
• What changes could we adopt in our workflow to solve these issues?

We asked the team to answer each of these questions using sticky notes, and then together, we organized the stickies into themes.

An example of one of the boards we used to facilitate the interview workshops

What did we learn?

What's going well

• With updated agile processes, teams have been more flexible and better at collaborating.

• Mockups in Figma have been helpful as a source of truth and are good at facilitating feedback.

What's not going well

• The design and development libraries don't match, causing confusion.

• Teams don't clearly understand component usage.

• Designers aren't sure of the process to modify or add components.

• Teams modify, misuse, or create duplicate components, causing issues and confusion.

Recommendations

• Bring design and development libraries into sync.

• Put more of an emphasis on documentation and guidelines.

• Designate a single team to take responsibility and ownership of building and maintaining global components.

• Develop and promote a transparent process for modifying and adding global components.

Takeaways

We conducted these information-gathering workshops because we believed they might provide us with the evidence we needed to convince stakeholders that a design system effort was worth investing in. It did, but what we didn't realize going into the workshops were the additional benefits we'd gain through talking to our potential users.

The workshop interviews allowed all parties to speak about their experience designing and developing at Buildertrend and recognize their shared experience and struggles. Additionally, bringing potential users into this conversation provided an opportunity for our team to generate excitement about the prospect of a design system.

We presented our findings and recommendations to leadership, and we were able to align around the need for a design system. Soon after, developers joined our team.

My key takeaway as we embarked on the design system journey ahead? Always remember the power of user feedback and its potential to push an initiative forward. Whether your hypothesis proves true or not, it's hard to argue with the problems facing your users.