One aspect is common to all innovations – they solve problems. (Nir Eyal)

There are a lot of companies out there trying to be innovative. How they go about doing that, though, is what really matters.

Now, you may simply work at a company where everyone is a genius and comes up with at least a dozen brilliant ideas every day. I guess that means places like Apple and Google and FaceBook and Twitter … 

Unfortunately, though, it’s probably not the company you work at. I mean, we all can’t be astronauts when we grow up now, can we? Not that that’s going to stop a lot of us from thinking we work at Google, or that we’re the next Johnny Ive, or that we’re going to come up with the next SnapChat.

So, if we’re not crazy, brilliant geniuses, how do we come up with those great innovations? One thing I do not recommend is sitting around staring out at the window. Another thing I don’t recommend is the group version of this, a brainstorming session.

What I recommend instead is to try to identify what problems your customers or users are having and then try to solve for those. And one way you can do that is to simply ask your customers. Believe me, they’ll have a lot of good ideas.

At the same time, though, they may not be fully aware of all the problems they are having, or that something might be done in a better way, or that something might even be a problem. In addition, they might not be that good at articulating those problems, or prioritizing them, or identifying their root causes. So, customer feedback – though invaluable – will always be a partial solution.

One thing I’ve found particularly valuable for uncovering problems – and, ultimately, for coming up with innovations – is ethnography. Now, all that really means is “field studies” – watching people complete their own tasks in their own environment. These tend to generate a ton of data, data that covers the user’s whole experience.

Further, what these things are particularly good at is identifying the pain points, the gaps, the holes – even when users may not be totally aware of them themselves. And once you’ve identified those, it’s actually not that hard to come up with some pretty creative ideas – ideas that can address those gaps, ideas that not every other company might be doing, ideas that might be actually genuinely innovative.

Believe me, it’s a lot more than clever graphics involving light bulbs

Don’t fear mistakes. There are none. (Miles Davis)

I feel for my UX teams – the IAs, the IDs, the writers, the graphic designers, even the coders. They put their hearts and souls into their designs. It must really be hard to watch someone rip it apart or fail miserably trying to actually use it. And that must be especially difficult when you have to simply sit there and watch, with a thick piece of one-way glass between you and that user.

Something similar happens during any usability test report-out. Reports tend to simply report the findings – and not point fingers – but it still must be hard to hear. 

Now, personally, I do try to do some things in my reports that can help the team feel a little better. Probably the most important is to make sure there are positive results (ones to celebrate) as well as negative ones (ones to fix). 

I also do something similar during actual testing as well. Like most usability engineers (at least I would hope), I try to debrief after every user. These things – at least for the first few users – tend to be a little awkward. One way I’ve found effective to break the ice is to offer a few observations about things that worked well. That usually gets the ball rolling, and the team will naturally move on to the things that didn’t work so well.

A lot, however, depends upon the individual. Some people are just a lot more sensitive than others. I find that sensitivity is especially the case for newer team members and for those who are simply new to usability testing or UX in general. (Very experienced designers can’t wait to get into the lab. Their philosophy is generally, “Bring it on!”)

In fact, I’ve actually noticed that these newer team members often go through something not unlike Elizabeth Kubler-Ross’s Five Stages of Grief. The first step, for example, is usually a combination of Kubler-Ross’s first three – denial, anger, and bargaining. For example, observers might ask, “Where do you get these users from?” Or they might focus on issues with the prototype or with questions and carping about methodology. The best way to handle observers at this stage is to just get them to not over-react (even if this means allowing them to vent a little) and to make sure that they come to some more tests. 

A second stage – after a number of users or even after a number of tests – is often something not unlike depression. When that happens, I try to be supportive. I might, for example, point out what worked well or some easy fixes. Finally, though, the observer reaches acceptance. And at that point, they are probably pretty well sold.

One thing that I like to tell observers wherever they are on their journey is that testing their stuff and incorporating the feedback is a real feather in their cap. I also go on to say that not everyone gets a chance to get their stuff tested, and that their willingness to do so really separates them from the average IA, ID, writer, graphic designer, or even coder.

One of my all-time faves