by Tanner Christensen, recent speaker at the VMA re:think design conference
This is an adapted version of a talk I gave as part of San Francisco Design Week and the VMA re:think Design Conference.
If I were to ask you who invented the telephone, you’d likely tell me it was a man by the name of Alexander Graham Bell. It’s true Bell was awarded a patent for the original telephone, but he was not the sole inventor. In-fact, Bell was one on a long list of individuals who each came up with the idea of a telephone over the span of 54 years.
During that half century, a dozen or more people independently conceptualize and documented their idea of the telephone. Some even went so far as to invent a working version of the telephone before Bell did.
You’re probably thinking each of the inventors collaborated with one another, borrowing and building on each others ideas, but the reality is that they came up with more or less the same idea in isolation.
These early inventors didn’t have easy access to each other because, of course, the telephone hadn’t yet been invented. Nor did they know whether or not someone had already explored the idea of a telephone before them. They didn’t even know if someone elsewhere in the world was working on the idea at the exact same time as they were. In Bell’s case, his patent was filed the exact same day — just a few hours earlier — than another inventor: Elisha Gray.
In the world of invention, having numerous people independently stumble on the same concept is a common occurrence; so common it’s been given a nickname: multiples.
The telephone, calculus, the theory of evolution, and the crossbow are all examples of multiples. When the Nobel Prize is awarded, it’s often awarded to three separate individuals who each landed on more or less the same discovery in their given field.
In the world of design we also have multiples. Such as when Airbnb and Medium’s new logos came under some scrutiny because they look so identical to a few brands from the 1970s.
The fact is that multiple people often end up creating the same or strikingly similar work independently of one another. The telephone was just one such case.
Yet, if the inventors of the early telephone, or calculus, or the crossbow, weren’t looking to each others work to inspire them, how did they land on the same idea? What were they inspired by?
I want to be clear that what I’m talking about here is practical inspiration. It’s not the feel-good inspiration you get from watching a beautiful sunset or from hearing a remarkable talk.
We can all probably imagine what practical inspiration means however. It usually means that if we’re working on a visual problem, we tend to look to publications or online sites like Dribbble and Behance to see how others have used things like color, space, and hierarchy in their work. Or if we’re working on an interaction design experience we’re likely to pick up our phones and swipe through apps and experiences to see what those are like.
These are very common behaviors in our industry and we tend to talk about them in terms of inspiration.
But this is not how inspiration works. At least not practically.
We say these behaviors are us seeking inspiration when they’re really us looking for existing solutions. And this is a critical difference we must remind ourselves of if we’re to do our best work.
We say we need to be inspired but end up seeking solutions. And with enough diligence, and given enough time, we inevitably do end up finding a solution, or part of a solution we feel we can adapt. We then say that what we’ve found is inspiration, when it’s really somebody else’s solution.
And that’s the problem with this: the solutions we stumble on and say “have inspired us” aren’t solutions to our design problems. The solutions we find through these behaviors are solutions to somebody else’s problem; a problem we don’t have full context into 99% of the time.
It’s rare we’ll find a design solution and know the needs or constraints of it, or the things the designer tested or iterated on. All we see is a finished or semi-finished product, the solution a designer landed on after who knows how many hours of work. Without full context, solutions lack the who, what, where, when, why, and how; which means there’s no way for us to be certain they’re an appropriate or even reasonable fit for our problems.
It all sounds a little silly once you realize this. Yet we do it all the time and call it inspiration. Why?
I believe we do this for many reasons, but there are two primary ones that come to mind: either we’ve failed to explore and truly understand the problem we’re designing for in the first place, or we’ve somehow lost track of where we are in the design process and are unclear about what to do next.
So whenever we face uncertainty like this, we say we simply need to be inspired, then look out into the world to find solutions without fully considering the consequences. It’s a bad habit which has become ingrained in our industry.
At Facebook we see a variation of this often.
Designers outside the company will browse sites like Dribbble and stumble on a trend or experience they think is really amazing, and they’ll think that the thing they’ve stumbled on could be an excellent solution to a problem they’ve personally encountered on Facebook. They’ll work tirelessly on a redesign of the Facebook experience and share it as a suggestion on how to improve the platform, sometimes even including the redesign as part of a job application.
Often when I see these unsolicited redesigns I can’t take them very seriously, because while the design may appear to solve a very simple problem, the designer tends to overlook vital aspects of the problem space.
They overlook things like localization, what happens when a button or headline goes from 7 characters in one language to 30 in another? Or what about translating text from left-to-right to right-to-left? Or how a pattern scales across many different platforms for a billion people all around the world who each use the product differently.
So while the redesigns are usually nice to look at, they don’t get at the heart of the problem that Facebook designers have more insight and understanding of.
And really that’s what we should be talking about when we talk about design inspiration: we should be talking about understanding.
Each of the numerous inventors of the early telephone were able to land on more or less the same idea because they each had a deep understanding of the problem they were attempting to solve. They didn’t need to know what ideas others had landed on, or how someone else was tackling the problem, because some form of the solution was inherent in their understanding of the problem itself.
In the case of the telephone, the inventors were striving to improve the telegraph, which was popular at the time but not ideal because it meant you had to practically learn a new language to use it, like Morse code.
Rather than having to learn a coded language, these early inventors thought, why couldn’t you simply speak into a device which could capture the vibrations of your voice and use that as the signal for the electric circuit?
Each telephone inventor independently ended up at this same conclusion, but it was Bell who perfected it, using a thin piece of calf skin to recreate vibrations which most closely mimicked the human voice.
Bell landed on his concept after many, many months of effort spent tinkering and exploring the problem space. But his idea of the telephone was otherwise identical to that of Elisha Gray’s. Both inventors landed on the same idea simply because they understood the problem and what a realistic solution to it might be.
The fact is good, unique, ideas want to be found. But they can only be found if we take the time to understand where they reside, in the problems themselves.
To do our most impactful work then, we should seek to not be inspired by existing ideas, but to more clearly understand what it is we and the work are trying to do.
As Charles Kettering once famously quipped:
“A problem well-stated is a problem half-solved.”
And of course, as we all know, the first stage of any design process is to build understanding. It’s the first stage because it opens the door to what’s not only possible, but what makes sense.
How do we build a deep understanding of our design problems without looking toward existing solutions? We must focus on empathy, understanding why the problem we’re solving is a problem to begin with.
We must immerse ourselves in the experience of the problem landscape, feeling out the edges to see where solutions may lie. And we can do this through a number of means other than looking to see what others have created.
We can observe those who suffer with the problem the most, engage with them, really listen to what they have to say. We can look to other industries to see what problems there relate to ours. We should also consistently and repeatedly ask questions about the problem area we’re solving. The more questions we can ask, the more area around the problem we can uncover.
If this all sounds like work, that’s because it is. None of this is very easy to do.
It takes time and mental resources to understand even the most seemingly minor problems, or to get outside of our own heads long enough to glimpse a different perspective of it.
I wrote a book to help with just this thing: provoking original thinking and idea exploration. It’s called The Creativity Challenge and it’s filled with 150 ways to explore problems and think differently. Yet, even with 150 straight-forward ways to explore ideas put in front of us, the task of developing an understanding for a problem still is not easy to do.
I believe this is part of what helps separate designers from the rest of the world.
While anyone can pick up a copy of Photoshop or Sketch and throw together an app design relatively easily, it takes real design thinking to make a design work.
And what we find when we put in the time and energy to build an understanding is that ideas and solutions want to be found. Effective ideas will suddenly seem obvious because we’ve dug around to uncover them.
Consider here the common symbols and metaphors we associate with insight: a sudden flash of light, a spark, a light bulb turning on. These are all apt metaphors because they remind us that what we’re seeking isn’t going to be something we can find already existing in the world. What we’re seeking can only be found by stumbling around in the dark.
To be clear: I do think there is some value in seeing what others have done, of looking at the work that exists. We would be foolish to ignore what competitors were doing, or where the industry is going, or what ideas people have landed on.
But existing work is only valuable if it’s used as a reference point for our curiosity. We shouldn’t look to it and say that what we’re doing is looking for inspiration when really what we need is understanding.
Great designers know this. They know that often when they’re feeling the need to seek out existing work it’s not actually to be inspired, it’s a signal that they need to step back and work on understanding the problems they’re attempting to solve. They know that their problems are unique, and so their work should be too.
If there’s only one thing you take away from this, apart from the fact that Steve Jobs wasn’t the inventor of the telephone, I hope it’s this: we can only do our best work by understanding what it is we’re doing, and we cannot build that understanding by merely looking out into what’s already been done.
We must put in the work to build understanding.
We must build empathy, explore creative exercises, write often, tinker and experiment and play, but most importantly: ask an infinite amount of questions.
Because even if you inevitably end up at the same solution as someone else, you’ll at least have a better understanding of how you got there. And there’s power in knowing that. There’s power in understanding the problem so when the next iteration of it pops up, you’ll have a place from which to build the next solution.
As the great Pablo Picasso once put it:
“Inspiration exists, but it has to find you working.”
Put in the work.
Product designer at Facebook. Author. Developer. Here are some of the things he thinks from time-to-time. More at:http://tannerc.com