Skip to main content

Case Study: Lessons Learned from Design System Culture

09-06-23 Katie Jennings

Internal team culture can make or break a project—especially a design system. In this case study, learn about the challenges we faced working with a disconnected culture to jump-start a design system.

We’re always happy to have an opportunity to share what we’ve learned on successful projects. It’s less common, but perhaps even more useful, to give readers some insight into a project that we ultimately decided to step away from. We won’t be sharing specific details of the company or products, for obvious reasons, but because we’ve spent a lot of time focused on the impact of culture on design system teams, we think what we can share will still be of value for you.

Our client was a multi-billion dollar enterprise in the financial services industry with more than 4 million clients across the country. This was an organization ready to lean into becoming a digital-first company. Sparkbox was hired for a design system exploration and build that would be structured and timed to work in parallel with the evolution of one of the dozens of products owned and managed by this organization. Ideal outcome: a system that was already in use by a cornerstone product and ready to be applied to many more. We strongly agree that an applied use case for system design makes sense, and were excited to get started! The reality was not as simple as it sounds, and (as often happens) we believe that culture was the culprit.

Expectations and Priorities

From the outset of the project, we understood that this would be a big transition for the client. We designed a team based on the needs that had been described to us at the outset of the project, and we shared a little bit with the client about how we expected to approach the engagement. As always, that meant collaboration, iteration, and lots of transparency between partners. We understood that the project would mean refactoring a product build into a design system, but we also understood that organizational buy-in and support would be critical for the evolving system.

We absolutely believe that building a system alongside product evolution makes sense. It can be difficult to visualize the application of a system without anything to apply it to, and leveling up a single product can help justify the investment of time and money for design system skeptics. However, the balance between working on a design system and working on a product can be tricky. It’s not uncommon for team members to be charged with the success of one or the other, but not both. Determined in collaboration with the client, our goal would be to maintain the balance—and we designed a team to meet that objective.

Planning Meets Reality

Every project begins with unknowns. No matter how thoroughly we discuss needs before signing contracts, there is more to learn. And we’ll continue learning and iterating for as long as an engagement lasts, whether that be months or years.

With the client in question here, one of the most important things for us to understand through our work together was how the internal teams were interacting. In this case, there was one (extremely busy) person assigned to the design system. The other people we worked with were primarily assigned to other projects. Our main client contact had oversight over the project but did not have the time to devote to really digging into the project. He received reports and updates but was less of an active participant than is often the case.

Despite the significant investment that the client was making in this project, we found that there weren’t clear priorities being set for a unified project and no clear mandate for moving forward. With a siloed team, everyone was working at cross purposes.

Further complicating the situation: this client was focused on speed. There’s absolutely nothing wrong with moving quickly and efficiently, but if there are bumps in the road they can be exacerbated without time to smooth them out.

Note that none of the challenges I’ve outlined above have to do with the skill or dedication of the team that we were working with. These were, and are, experienced professionals who have all the skills they need to complete the tasks at hand. The issues here were purely cultural.

Can This Project Be Saved?

Like any partner, Sparkbox brings its own culture to any engagement, which tends to be focused on collaboration and transparency. We leaned on this toolset as we tried to help the client come to a better resolution and put effective processes into place. Some of the solutions we tried included:

  • More detailed reporting

  • Opening meetings to people from different teams

  • Suggesting/Requesting clarification on big-picture direction

  • Recommending the creation of an internal oversight role.

Moving Forward

In the end, we found that the internal culture was an immovable force. We did make progress, but the influence of our approach and our recommendations couldn’t create the shift necessary for this work to ultimately be successful. After a year of trying, we did something that we’ve rarely (if ever) done before: we let the client know that we needed to step away. We were careful to be respectful and thorough in the handoff of our work into the client’s hands, as we wanted them to be able to fully take advantage of the things that we’d achieved.

What can we (and you) learn from this experience? Culture matters. On a design system project–or any complex undertaking–you’re not just filling roles, you’re building a team. Here are some things that we took away from the project, and which might be useful to you as well.

  • Your team will prioritize the things that you measure and reward. In the case of this client, the measure of success applied to the products using the design system, not the system itself. It’s hard for the system to take root if the culture doesn’t value the benefits it offers.

  • A system is about people, not just technology. Take the time to build relationships among the team, give them leadership and inspiration, keep them informed, show that their input is valued, and help them focus on a common goal.

  • Culture isn’t a one-way proposition. It’s about give and take. Make sure to have a plan in place to gather feedback. Collaborate with members of each part of the team to teach about the system and its benefits.

Ultimately, the success of your system is going to come down to trust. With this client, we didn’t have the time or the authority to tend to the culture and make sure the system was understood and valued by everyone involved. Moving forward we’ve devised ways to model the kind of cultural interactions we know are needed for a design system to be sustainable. Thriving projects, for us and for you, rely on this kind of collaboration and vision. Feel free to explore more of our work on culture and design systems, or give us a call so we can explore the impact of culture on your system.

Related Content

User-Centered Thinking: 7 Things to Consider and a Free Guide

Want the benefits of UX but not sure where to start? Grab our guide to evaluate your needs, earn buy-in, and get hiring tips.

More Details

Want to talk about how we can work together?

Katie can help

A portrait of Vice President of Business Development, Katie Jennings.

Katie Jennings

Vice President of Business Development