The tool and the task.
Generally, I think about a design system in terms of both output and input: folks need to get patterns out of the system, sure; but there need to be processes established to channel contributions into the design system, too. Because in my experience, many organizations focus heavily on the output side of the equation, without talking about the input: how best to support teams that need to add, remove, or change what’s been put into their design system.
For me, starting that rebalancing act involves chatting with clients about their system’s consumers and contributors. But I also spend a fair bit of time interviewing people about the design tools they use. Do designers favor Sketch or Illustrator, or are they spending more time prototyping in Webflow? Are developers comfortable interacting with design assets directly, or do they tend to rely on collaboration tools like Zeplin? Questions like these help me understand how teams work together, and how they might best intersect with a future design system.
But those questions also help me understand what kind of assumptions might be baked into those applications, and how those assumptions affect the design of products built with them. For example, if a design tool only works properly when there’s a persistent network connection, what kind of expectations does that create in the design team? Does the design team start to assume their users will always be connected? Does an image production workflow only produce high-density images? If so, how does that impact any users who might be on low-cost data plans?
The point of this exercise isn’t to find fault with the applications and frameworks in use. It’s an attempt to surface any implicit assumptions and biases baked into the software and, in doing so, to recognize that every tool shapes the task. Our design tools change the design of our products and, at times, they can change us.