Find Someone Else Who Has Solved Your Problem Before

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

This post is part of a series about making better product decisions.

I was recently working with our interaction designer on the design of our job posting creation form. Like many job services, we ask for the location of the job, but the design of this section wasn’t quite right. The options were just too complex. We had a number of use cases to handle:

• Jobs with one location
• Jobs with multiple location
• Jobs that were telecommute only
• Jobs in ore or more locations with telecommute optional.

We wanted location to be required, but this added another layer of complexity when combined with the telecommute options. I was getting frustrated. We couldn’t be the first people facing this problem. And that’s when I said, let’s take a break. Go look at every other job board on the planet and collect what they do. Then let’s meet again.

Find Someone Else Who Has Solved Your Problem Before

This is a really common tactic in the world of design. Why reinvent the wheel when there’s a perfectly good solution out there to be borrowed or mashed up? IDEO starts any design project with an inspiration phase. Check out OpenIDEO for some great examples. Twyla Tharpe talks about scratching, in her book The Creative Habit, her process for pulling inspiration together before she starts a new project.

And just in case you thought I had moved on, it’s also a strategy outlined by the Heath brothers in Decisive. If you remember from previous posts, they talk about needing to widen your view of the problem. We saw this in avoiding “whether or not” decisions and with the idea of multitracking. They also encourage us to find someone else who has solved our problem before. They focus on two sources of inspiration, within our own organizations which they call bright spots and externally at other organizations which they call best practices.

Often times our organizations have already solved the very problem we are tackling. It may not look exactly the same, but usually there is no shortage of analogous solutions to draw from (more on analogies in the  next post). When faced with a tough challenge, the first place to start is within our own organization. Ask, have we solved this type of problem before, what worked, what didn’t. This is particularly useful in product design, as the more consistent you are across your product, the easier it will be for people to learn and use it. So look for and replicate the bright spots in your own product. 

But don’t stop there. Your competitors, your partners, companies in neighboring domains, may also have solved the problem you are tackling. Whether it’s something as simple as a creation form or something more critical to the core of what you do, there’s no harm, and a lot to gain, from looking at what everyone else is doing. About a decade ago, the interaction design community started to formalize this very process by collecting design patters as a way to share best practices. But this practice doesn’t have to be limited to design, it can apply to all elements of building great products.

Putting It Into Action

I’m sure many of you are reading this and nodding your heads. It seems obvious to start with bright spots and best practices. But why then are so many products inconsistent just within themselves? If you look at five different site, why do you see five different ways to solve the same problem? It sounds obvious. But it’s harder than we think.

Just as we need to build the habit of generating ideas, we also need to build the habit of looking for inspiration. Before any project, we need to stop and ask ourselves, has somebody already solved this problem. Then we need to genuinely ask ourselves, is there a good reason why our solution needs to be different. And when we get stuck, we need to remember to revisit the inspiration from which we started.

Circling back to the design challenge of handling our location options, after looking at what everyone else was doing, we were reminded to simplify our use cases. Many of them were just not that common or could be handled with multiple listings. So we simplified the problem and found a suitable solution.

Again, this might sound obvious, good solutions often do, after the fact. And this happens countless times throughout a product designer’s day. The key is to shorten the cycle by drawing from those who have been here before us.

Do you have a similar story? Please share in the comments. 

This post is part of a series about making better product decisions.