Topics
May 15, 2026
May 15, 2026
It’s no secret that a lot of work goes into creating and maintaining a design system, even if you’re not on the system team.
We also know that the real work starts after you’ve shipped work…getting teams to adopt it.
I recently faced this challenge during a project related to audit and compliance that required buy-in across quite a few teams.
The plan was to introduce suite-wide patterns to over 1,000 people within our organization, and adoption was critical.
When it came to our previous design system, adoption wasn’t the best.
We had primarily socialized it through recurring meetings, Slack/Teams shareouts, and a few other touchpoints, but notifications were often overlooked amid the noise. It was difficult to get and keep people’s attention—much less get them to actually adopt a system.
This time though, our team took a new approach and it ended up being a game-changer.
Below, I’ll walk you through…
Any good design project starts with research. In my scenario, it was especially important because I needed to support over 25 teams that had already been working on their own audit trail solutions and now needed a standardized pattern to follow. I also needed to understand what had driven the UX team to invest in this in the first place, and know our platform limitations.
I started by digging into the current state in collaboration with platform subject-matter experts in product and engineering, and I started an internal network as early as I could. I also met with design and product manager colleagues to understand any past work that had been done related to audit trails. In large organizations, rarely is anything truly from scratch.
Additionally, I went through a year’s worth of product development requests from Salesforce to understand client pain points directly.
On top of that, I conducted three roundtable discussions with client-facing teams to understand client pain points more holistically.
It can be difficult to get the budget to talk to actual clients, so talking to internal teams helped accomplish multiple things at once. I got to…
These internal teams included…
These roundtables were so helpful that I now try to conduct them for every future project, even if I have access to clients directly.
If you’ve never done this, you might be surprised how excited client-facing teams are about collaborating directly with product teams. While it can be hard to reach across silos, it’s extremely valuable. They often know the platform inside and out in a way few other stakeholders do.
Building these relationships early has helped me immensely across projects, whether it’s forming connections that lead to client research or understanding the business more holistically.
Once I had a solid foundation, I created some wireframes in FigJam.
I made sure to get early feedback from product and design teams—even with limited time—to see if the pattern would work with their use cases. I found that involving the triad as early as possible pays off in the long run, from getting buy-in on design direction to improving the design as a whole.
Part of this was because I had a unique design challenge: I needed to create something simple enough that any team could use with any data, but specific enough that it still provided value to clients when needing information for audits.
After implementing that initial internal feedback, I conducted usability testing with two clients, three internal HR employees, and two service team members. I highly recommend running designs past internal teams first before showing them to clients, so that the time with clients is as valuable as possible.
Even getting a few designers’ feedback goes a LONG way to ensure clients aren’t just finding the most obvious issues. We had a limited research budget, like most organizations, so I found it even more valuable to get the most out of testing by refining first.
Throughout this process, I also regularly met with our design system team to update them on progress and collect feedback.
By this point, I had quite a few teams invested in the project and excited to stay updated. I found this much more effective than presenting a finalized design later on, even though I know it can feel scary to share in-progress work that will likely change.
After making final changes to my design based on usability testing feedback, I presented an overview of the project across several channels along with the final pattern. This also helped with buy-in because people understood how I arrived at the final design.
I first reviewed the final design with the design system team, who then published the pattern. I kept all the relevant product teams updated as they needed to scope the work for their roadmap. I then shared it in the monthly Product Community of Practice meeting, and the monthly Design Community of Practice meeting.
I encouraged people to leave feedback and ask questions so we could continue refining the pattern. I also worked closely with our asset management team to implement the pattern and made further tweaks based on their experience.
One last important step was putting myself down as the subject matter expert for audit trails in our shared design team documentation (a simple Slack canvas). This made it easy for people—especially new teammates—to know who to reach out to.
The process is always a work in progress, but I regularly reach out to anyone who might be working on audit trails and share my work. Being proactive goes a long way. In siloed organizations, chances are people haven’t seen your hard work!
Ownership over different products changes quickly in a large organization, so it’s critical to involve as many people as early as possible. One meeting with a stakeholder is not enough to establish yourself as a subject matter expert.
Even though the pattern is published in our library, not everyone knows where to look. People still reach out to me about where the pattern lives because they know I worked on it months later. No matter how good your documentation is, it goes a long way to build an internal network of people who recognize the work you’re doing and to remain top of mind for a specific design.
If you’re nervous about involving people early in the process, I found that starting with research was a great way to do it. Everyone likes to feel helpful, and it builds a sense of co-creation that’s hard to achieve if you only share work near the end.
I’d love to hear how other teams are addressing adoption challenges for company-wide patterns and components. What’s worked for you? Let me know!
