May 17, 2023

Talk to your users...

When I first started working on design systems, it took me far too long to realize that users of the design system are not the same as the users of the company’s products. If your design system is a product, it makes sense: you need to talk to the users of your product.

To build the right design system, you need to talk with the people who will be using it and paying for it. What you build is going to depend significantly on the size of your organization, how many teams, what tools they’re using, how many and which platforms you support, and even company’s org structure, culture, and internal politics.

I’ve been reading A Civic Technologist’s Practice Guide by Cyd Harrell and came across a quote about civic work that I think applies nicely to our posture as builders of design systems:

Our job… isn't to be the hero of the stories. We stumble into halfway through; it's to understand and support the people who have already been in place doing the work, who want to use tech to make improvements.

If you see your design systems efforts as creating tools to support the effort of teams in the org who make products for customers, the chances of building something successful are much higher.

💬 Interview your users. Before you begin building, sit down and talk with key stakeholders, designers, and engineers. In a large organization, you may talk with representatives from the design and engineering practice (e.g. team leads).

You’re trying to learn:

• What does their part of the product creation process look like?
• What part of the product creation process do your teams think work well? What does not?
• What do they find themselves doing over and over?
• Is there a common “villain” that nearly everyone agrees upon?
• As you listen to the process of multiple teams, can you identify any overlaps between them?
• How willing is each team to collaborating with a design system team?
• Has anyone started work that could serve as a foundational for design systems work?
• Is there already a “braintrust” of people who understand core design systems principles and are interested in participating?
• Is there a common set problems or a rough sense of structure you can start iterating on?
• Are there products about to launch that could serve as a pilot for some of your design systems work? (More on that in a later email.)

👩‍🎨 Talk with designers. People that decide your brand guidelines. People that build visual prototypes for each of the digital products.

From them, you’re trying to learn:

• What do they consider the most important parts of the user experience?
• Where do they feel the user experience suffers the most across products? (This is a good place to share the findings from your content inventory.)
• What does handoff — the process of communicating design requirements to engineering teams — look like from their perspective?
• What tools do they use to create? Are all teams using the same tool or different tools?
• Do they have existing style libraries, UI kits, published guidelines or anything design-related that’s programmatically connected to code?
• What’s the biggest problem they would love help solving?

👨‍💻 Talk with engineers. People that build the front end of your digital products are key. It may also be helpful to talk with people that build the back end as well, since some design systems solution might depend on some dev-ops support.

From engineers, you’re trying to understand:

• What do they think is the most challenging part about integrating with design?
• What components are you building over and over again?
• What platforms are currently supported? Get as specific as possible, because specific frameworks very often require different solutions. For example, are your mobile developers building the Android app with Jetpack Compose or with React Native? Exporting assets and transforming design tokens look much different between those two platforms.
• What tools are they using to create?
• Do they have existing component libraries? Are these shared across multiple teams?
• Are they using existing frameworks, like Material, Tailwind, Bootstrap, etc.?
• What’s the biggest problem they would love help solving?

💼 Talk with stakeholders. People that control the purse-strings. People that can approve or kill a project and issue mandates.

You’re trying to understand:

• How much do they understand the value of design systems work?
• Does what they’re concerned about line up with what the people building the products are concerned about, or is there a misalignment that needs to be addressed?
• How much resourcing can they get or allocate to support design systems work?
• There’s a lot more to say about talking with stakeholders about the value of design systems. More on that tomorrow…

…

What and how you build will look very different from org to org, but these questions should give you a good starting point for figuring out what’s most valuable to your org.

—
Cheers,

Up Next: How are you going to pay for that?

← Full Archives