I was asked this question today: how might we convince stakeholders to invest in design? What a beautifully rich question! It inspired me to put down a few thoughts.
To “convince” people to solve problems we want to solve, we’d need to bring them to a shared understanding of the problems. Investing in anything requires us to believe that solving the problem is worth the cost as well as the pain of change and transition. We often try to “convince” people to solve a problem (e.g. invest in design, buy something, etc.) by showing them how more effective/efficient/insert-metric-here a different approach could, conceptually, be. “That looks great,” they say, but they’re not putting their money where their mouths are.
They might say that looks great and still not bite because they haven’t come to the conclusion that their current pain is worth solving. To get to a shared understanding of the problem space, it will come down to research: through observation, through provocation sessions (put something in front of them to get reactions as a way to gather data, like a probe sent to outer space). We need to scale: that’s what gets me excited but not without the confidence of some evidence that there’s a shared understanding of the problem space and a shared belief that the problem is worth solving. For me, it’s less about convincing and more about aligning.
The question of how to convince third parties to invest in design begs another question: what do we mean by “invest in design”? Is it outputs or outcomes we’re looking for? Outputs as in aligning to the same UI paradigm? Or outcomes as in a design process rather than the coded artifacts? These aren’t mutually exclusive, of course. For example, a full-fledged design system can create a UI paradigm across different implementations, but are we trying to solve OUR problems or our CUSTOMERS’ problems? Are their problems at the UI level or the workflow level or something even more fundamental: do they need a PDF export, a way to manage their subscriptions, or a smart AI to help them optimize their spending?
In other words, is the problem a surface or a substrate problem? Surface-level solutions have a visceral appeal that substrate-level solutions don’t. Design has processes and tools to tackle problems from surface to substrate and everything in between. Solving surface-level problems versus substrate-level problems requires different types of investment. Surface-level problems could be solved at the level of output, whether it’s delivered by a vendor or by internal teams. Substrate problems require investment at the organization level: sometimes it needs different ways of working or different team organization, or even different mental models–none of which are straightforward or fast.