Defining the Problem: Q&A with Tom Chi

As I outlined in Defining the Problem, designers are often able to reframe business “problems” to better communicate existing and potential relationships (and outcomes) between the market, customer goals, and product ecosystems. To further illustrate this point, I’ve asked a few seasoned designers that have successfully defined or re-defined business strategies to share their experiences defining problems.

First up is the ever eloquent and ingenious Tom Chi of OK/Cancel and Yahoo!

Q: I've been talking a lot about how design methodologies can be used to define problems, not just solutions. You've been doing this extensively and successfully at Microsoft and now at Yahoo! What drives you to take the time required to define a problem? Why do it at all?

A: Usually when a group of smart people is at an impasse for a long time, it is because the problem is poorly framed, not because their solutions are not good. Unfortunately, it is par for the course in the tech industry to try to bowl headlong into solving things even before we know what the problem is, or the criteria for success.

Defining a problem is also an extremely creative activity. If you are falling back to the same lame problem statements and measures of success, then you aren’t really trying. And there are a ton of reasons to try. The most important is that a well defined-and exciting problem (and its associated constraints) is the catalyst that makes design go. By not drawing a clear and compelling problem, you are cheating your team out of an incredible unifying and driving energy.

Q: Can you describe how you approach the process? What information do you need and where do you find it?

A: Well it’s key to put on as many hats as you can. Usually discipline X will look at the project and proclaim that the solution lies largely in more application of discipline X. No surprises there. The mature approach is to understand that there are many, many dimensions to the problem and solution space. As designers we instantly jump to defining the design problem, or worse yet into designing a solution... But in some cases the day is won by clever work in finance, in partner relationships, in market positioning, in timing, in exposing core technologies, in new modes of behavior, or even in internal organization structure. It is really up to all group members to try to understand the problem from all angles.

Ok, that answer sounded boring and general, so I’ll give you an example: In my spare time I work on trying to jump start the green technology movement, and my thinking over time has changed significantly. Originally, I believed that renewable energy didn’t stand a chance until significant engineering improvements brought it in line with cost per kilowatt-hour of existing non-renewable tech. The more I understood the space, the more that I began to believe that it was a finance and marketing problem and not a technological one. For example, in the hybrid auto-space everyone talks about whether hybrids pay back their premium price over time. This is the wrong question and the wrong problem to solve.

No one asks whether that sunroof pays back the premium over time — it’s just packaged as something attractive and the cost increase is financed away over years. Similarly in portable devices, people pay huge premiums for design and aesthetics, not really caring about the cost of energy in the device. So in many cases in this emerging market, the engineering and pure economic considerations can be trumped by finance, marketing and design.

Now when it comes to the day-to-day grind, my process is pretty simple. I try to sift through as much data as I can — data of all types — usage data, competitors in the market, usability and user research, organizational importance of the project, long term goals and opportunities in the space, etc. Ok, maybe it’s not so simple... But it feels simple because once I have a lot of this data in my head I just take time out. I walk, daydream, watch sandpipers, etc. If you’ve spent enough time with team members of different disciplines their ways of thinking will automatically play through the data as you ‘daydream.’ Then after a couple hours, I come back and just try to map out what I know.

Q: What about the actual deliverables? I know you use diagrams a lot. Can you describe the structure of the diagrams you put together? Is there a consistent set of criteria you use to determine if you are hitting the mark?

A: Usually it is a graph or diagram of some sort. There are a lot of ways to cut the data, but plotting different influences and factors in time (timing is everything in business [and comedy]), usually results in something good. Also I’ll map several dimensions against each in space to see whether there are emergent nodes that should be treated differently. Lastly, I’ll create simplified illustrations to both clarify the learning in my own head and to communicate it to other people. This is actually the place where having design and information architecture/visualization experience helps a whole lot.

Many people are visual learners, but much fewer are effective visual communicators. When these people see a diagram or visualization or competitive timeline that makes sense, the discussion quickly moves to the next level. Sadly, without some visual as a point of discussion, you’ll see these same people in endless meetings pouring through a 24-page document and leaving with less clarity than when they went in. Given this, there is an easy way to tell if you are on the right track. If a discussion that was taking meeting after meeting is suddenly simple after showing and talking through your diagram for 15 minutes, then you are there. If people start referring to aspects of your visualization or using the terminology you used, then you’ve succeeded.

If they don’t — no reason to despair. Get their input, and more importantly, get their viewpoint on what is important and what the problem is in their eyes. Then, go get the data that makes that problem clear. Then iterate on your visuals.

Q: Is there anything about designers or the design process that's particularly well suited for accomplishing what you describe?

A: As I mentioned before, designers are natural visual communicators. If 3 designers were in a room and weren’t allowed to speak, but only draw, they’d get loads more done than 3 of any other sort of person. Given this, we can use our skills to powerfully communicate the data we’ve collected. We can represent dozens of viewpoints, influences, competitive factors and more in a single slide. We can get large collections of people on the same page with clear actionable goals in less time than any manager giving a speech.

We also think about the form and scale that data is best consumed. Oftentimes, we are beset with either far too much data or far too little. They come in the form of gigantic spreadsheets or organizational meetings filled with platitudes but no content. As designers we know how to deliver data at a meaningful human scale, and defining a problem well is one of the best places to do it.

Q: From my experience, defining problems has been a doorway for designers into the world of product and corporate strategy. Have you experienced similar results? What are the usual outcomes of your efforts?

A: This is definitely the case. Every executive can use a strong visual communicator on his or her side. Similarly, every manager needs this as well, as they go though the process of trying to sell their initiatives and get products shipped. This type of work can get you access to many places that designers do not often go, and it’s a great way to be exposed to the types of conversations that shape higher-level business strategy. As I mentioned before, as much as I love design, the solution doesn’t always lie in the design space. In business a lot of other factors are at play, but design thinking, problem defining/solving and visual communication (all skills that designers excel at) can give you a huge leg up in terms of advancing your work and your career.