Bridging the gap between problem and solution –

Imagine trying to drive between two points, which is a common problem everyone runs into. You know the starting point well because it’s in your neighborhood, but the end is a little fuzzy because you’re not entirely sure how you’ll get there. You hit the road with a happy path in mind, but then you start to get hit with traffic or construction you’re not use to, and your solution gets challenged.

When we’re confident in our abilities, like driving around town, we tend to sometimes overlook the smaller details of the problem and assume a solution.

This phenomenon applies to product design.

As a young designer, when challenged with a large design problem, it was second nature to start solutioning right away. It took me a few stumbles to take a step back to understand the full problem at hand before making a decision on how to best solve it.

I remember working on an app some time ago. The problem — to create a cloud synced note taking app. I had designed a few apps before so I was confident enough to think I’d had a solution immediately. I had ideas on the workflow, functionality needs, gestures, the fonts, etc. I figured it was a simple 2 screen app so I designed it based on that assumption. As development went on I realized that cloud sync issues and statuses were something I’d need to include in the app. I didn’t account for this edge case, and it changed the core structure of the solution. I had solved for the happy path quite well, but had no solution for edge cases like when sync issues were present and needed to be resolved somehow.

The core of a good solution generally isn’t in how well the happy path works, it’s in how well the edge cases are handled.

Understanding the complete depth of a problem is a difficult challenge in itself. It requires looking at every nook and cranny tediously to uncover possible blockers to the happy path before thinking about the solution. In some cases it may require auditing the technology to understand where certain handoffs occur between systems, like when one website communicates to another there is no guarantee it will be instant. Or it may require profiling your users to form an opinion on what preferences they have, which could change the perspective of your solution.

I’ve found the following exercises help bring clarity to the gap that exists between the problem and the solution.

Author: David Stubbs

Collect by: