"What do you need?"

Understand and observe before trying to solve problems

A powerful question at the core of design. You cannot solve for problems that you don’t understand. And you can’t understand a problem unless you listen and observe those who are impacted by it.

The World Policy Conference in San Diego hosted many innovators in their fields to discuss the role that design and innovation are playing in their work of shaping a better world. There were several sessions that focused on innovation, and I was sure not to miss a session featuring a visionary like Michael Crow discussing the work he’s done over the last 22 years at Arizona State University.

During the panel, President Crow described the unique way that the University thinks about engaging with employers and their approach:

Whether the person you’re solving for is a company, an employee, a student, or a staff member, the insight is the same: You cannot solve a problem you don’t understand (yes, it bears repeating).

You can’t always ask people what they need directly. They might not fully understanding the problem that they are facing or what will help them overcome it.

It takes work to understand someone’s needs, motivations, and experiences, and that investigation must be a deliberate, focused process that takes place before you start deciding how a problem might be solved.

In my experience working with teams in education and elsewhere, we often have a solution in mind well before we start the formal problem solving process, and despite the often best efforts of those trying to facilitate a rigorous process of understanding the problem to be solved, the solution is thrust upon the group by those with a solution looking for a problem.

In fact, the early Understand & Observe phase of the design process should be dedicated to exploring and then clarifying the problem space and bringing definition to what you understand are the needs, motivation, and behaviors of the people you’re centering in your solution. From this foundation you can explore many possibilities in the Create & Iterate phase as you begin to gain clarity of the attributes of a solutions suitability, and Test, & Learn by refining over time.

You can’t solve a problem you don’t understand, and if you try, it’s unlikely you’ll even get close. In fact, even when you think you might understand the problem your solution might not be correct, and you should expect to iterate and refine your “solution” through a similarly disciplined process of testing, learning, and feedback from those who’s problem you are trying to solve.

So if you’re facing a big, ambiguous challenge in your work, consider how you can ground yourself in the experiences of those who’s problem you are centered on and start a conversation. Maybe by asking “what do you need?” or “tell me about the last time you…” Or even better, watch them try to accomplish the task, experience, or interaction you’re trying to improve and take note of the challenges, barriers, and moments of delight and despair.

Everything that someone interacts with is a design, and every design can be improved through the insight offered when someone tries to accomplish their goals and in doing so expresses their expectations of how it should work. Listen to people. Watch them. See how they’re trying to reach their goals, how processes and experiences cause them frustration, overwhelm, uncertainty, and loneliness, among other things— and then consider ways to reduce or remove it to improve their lives.

And if you’re a University leader wondering how you might engage employers in the process that Arizona State did to improve your programs and ensure they’re relevant, reach out.

Between working at a national nonprofit focused on designing education towards the future of work and serving as a campus lead for a coding bootcamp, I’ve run dozens of design sessions between University leaders and employers to do just that.

Ask your local employers “what do you need?” and design solutions that meet it.

Scrolling LinkedIn this week, I encountered the impact of this work, and I think the results speak for themselves: