Elyse Holladay’s Post

Oooooft I feel this post deep in my bones, especially as someone whose design system role was dissolved 😅 There's a macro effect on design REALLY needing to show its value. For most, they can point to products they've shipped that generated X in revenue, signups etc i.e. stuff that is super measurable. When you look at DS through that same lens i.e. a product that's shipping new features (components, documentation etc) and try to measure it in the same way, you're going to hit a dead end. I know I did. One of the most fulfilling pivots my team made was repositioning the design system as a force multiplier for design and engineering. We did this by making a huge push to establish it as a "community owned" design system. Everyone in the org was now responsible for its upkeep and evolution, and the DS team's job was shepherding and enabling. A pivot to shared ownership then helped us identify some unforeseen challenges like a lack of DS knowledge amongst certain teams, insufficient onboarding, lack of comms etc. Improving DS competency then helped continued engagement. We also identified "champions", locally staffed advocates for the DS that knew it well, championed its use, and guided their teams to do the same.

Design Systems are tough. We’ve found real success by getting as close as possible to the community and their projects. We don’t make something new unless we know we have atleast 3 buyers lined up. That means that the work gets to customers quicker and we can start to interate improve it, IRL. If you make something and it doesn’t get used = a big waste of time and effort. It doesn’t count unless a customer can use it. If you make something and it gets used twice = you’ve probabaly broken even. More than twice and you’re starting to deliver real value, which can be measured. But it has to hit the customer to count.

I’ve found the more I ship solutions that support the use and engagement with the design system and its suite of tools, the more designers, devs, and product owners want to keep their teams in it. I know, it sounds obvious. However, the more I listen and engage with the day to day work it takes to utilize our system, the more buy-in and excitement I get from both IC and leader perspectives. This happens more often in the development lanes in the “invisible” areas of the design system like semantics, offering alternative tools for engaging our tokens within different architectures, and always listening for the things people aren’t seeing as a repeated pattern because it’s not “big enough” to share. The people around me may be growing tired of hearing it, but I always remind my team that we can ship small to win big. Thanks for prompting this question and getting me to get this written down somewhere!

"I think we're focused on the wrong things." Couldn't agree more. In many ways, teams focusing on the Design System over the path to impact is the death knell. Sometimes the distinction can be as subtle as phrasing. "We want you to begin using the design system" vs "we want to understand how we can make your life easier" can go a long way in terms of those early meetings with potential adopters. The most successful teams I see start by focusing on ways of working and identifying valuable programs or projects that they can meaningfully affect before they think at all about what goes in the system. Curious what my experienced friends think about all this...👀 J. Swirsky Alex Wilson, MBA Jon Reidy Mark Reynolds Melissa Butler Lori Blake Jackie Lai James McElroy Jacy Anderson Nick Hahn

Thanks for the tag, Andrew Rohman. At THD, the system is positioned as a tool to connect designers and developers. A by-product of that is consistentcy across the end-to-end customer experience. But the degree to which individual teams are on the same page amongst themselves is the degree to which the system is providing value. Leadership will feel/hear this. They will either hear more or fewer complaints/issues from teams about interdisciplinary collaboration. Ideally, using the tooling of the system makes collaboration easier, which makes people want to use it. The more people that use it, a network effect begins to happen where other teams begin to want to use it to be consistent with the whole. TL;DR: Focusing on how well working teams are collaborating is fundamental to reaching auxiliary goals (ie. speed, consistency)

As someone who participated for the first time in building a design system, the points you mentioned in your post are thing I frustratingly feel were errors my team committed. In the end we tried creating the perfect design system instead of delivering value. Lesson learn for future work.

My experience has been that systems are consistently misunderstood or misrepresented. The wrong types of expectations are set by people that have no real experience of how a system is used or what it’s really for. I think of Design Systems as critical infrastructure delivering value to their consumers every day. It’s just value that ironically Design Orgs are able to see the least…

I happen to be the owner of our DS, and before setting the vision, we started by understanding what would make it fail (based on previous systems in the company). What came out of that was the principle of “designing WITH, instead of AT”. By doing that we ensure that we meet our community’s expectations (and if they’re not realistic, we work with them to agree on expectations that are). This reinforces that the people and communication aspects of DS work are just as important as the technical one.

I believe the biggest misconception around a DS is that it’s often used as a UX solution, where it’s merely a tool to ship products faster and thus allow teams to focus on touch points in the product that matter. Once orgs will understand this, the entire narrative changes. Because it’s in these touch points, the actual value lies. Not in DS metrics such as the amount of usage of a component. 

It has impact but not always in the highly visual or standout way that Project Managers like to showcase. Introducing Consistency (visual, interaction, accessibility), Stability (standard usage, documentation, updates), Developer Experience (speed of implementation, freeing up time from repetition), is incredibly valuable but you don’t always _see it_. So what’s the answer? - Good communication of measurable value imo By building DS Tools.. usually a Chrome plugin that visually highlights DS components in live pages, reports numbers of unique components and instances (nice if you show these as charts) as well as allowing various DS properties to be toggled such as themes (campaign or brand), schemes (accessible modes such as high contrast). A tool like this can be put together in very little time and allows you to visually demo otherwise unoticallble but high impact DS value.