Users don’t hate change. They hate our design choices. (Jared Spool)

Change does not necessarily always equal good. Something new does not always mean innovation.

Consider the poor transfer user. These are simply folks who have gotten used to doing things a certain way. Then along you come with your improvements. 

But, are they improvements? Or are they just one more thing in the user’s way that day? Do they actually make the user’s job easier? Or are they just one more thing they have to figure out and deal with? Do they add new functionality? Or have you simply added something that no one will ever use, and made the interface that much more busy in doing so? Is it better than before? In your eyes? In the user’s?

Sometimes change comes for all the wrong reasons. Perhaps the higher ups simply want a new look and feel, a refresh.  Or you could simply have been shanghaied into somebody’s pet project. I often accuse my marketing friends of monkey see, monkey do.  Perhaps management is simply flailing away. They know they need to be innovative. But how to do that other than issuing the directive to “go innovate!” might be beyond them.

True innovation comes from seeing what users are having issues with. The brainstorming and ideation (I really don’t like that word) can help you come up with a creative solution, but unless you’re trying to solve a real problem, you may simply be creating new problems.

Even if you have a good idea, though, you still need some kind of change management. As a former instructional designer (who mostly worked on new internal systems for banks), I actually spent as much time on rollout as I did on anything else. I’m always amazed at how little that’s thought of, though, in good, old-fashioned B2C. And I don’t mean just training here, but communications and even selling. 

Other ideas to support what Jared calls “embraceable change” include tours; demos; coachmarks; complete mock systems; allowing the user to switch between the old and new systems whenever they feel like it; making small, incremental changes over time rather than one big one … There are no shortage of ideas. You do, however, have to come in with a mindset that change is not always welcomed with open arms, and that it is up to you to make sure that the changes that you make really do add value, and that you are presenting them in such a way as to maximize their benefit – and minimize their disruption – 
to the user.

More from Jared:

• "You can’t stop people from putting beans up their nose."

The misplaced creativeness of designers never fails to amaze. (Don Norman)

Just solve the problem! Honestly, people! What is wrong with you?

So, that’s what I want to say. What I typically say instead involves some lame hedging about standards, KISS, design patterns, never having tested that particular design before ...

Interestingly, this issue does often come up when a team is tasked with fixing something that came up in usability testing. And, in that context, my response is usually to compliment them on their effort but to point out that we won’t have to time to test their complete redesign of the system with just that one user coming in at 4:00 on Friday afternoon.

In other words, what you’ve come up with may solve the problem, but I can’t guarantee it. In fact, I honestly have no clue if it hasn’t introduced new problems. So, instead, I usually just try to get them to solve the problem, or – in Steve Krug’s great advice – to do the least possible to do so. And that is actually something I can feel pretty good about. 

Maybe it’s a digital creative thing. I know we are all encouraged to be innovative these days. And simply making an easy fix is probably not going to impress the higher ups or look good in your portfolio or make you feel all warm and tingly inside. If it solves the problem, though, why not just do it? You can then save all the creativity and innovation for something that really needs it.

Interestingly, Don’s quote was actually in the context of his famous doors. “Norman doors” are doors that are so poorly designed that they give you no affordance of whether to push or pull them. They were the example par excellence in his ground-breaking book The Psychology of Everyday Things, and have pretty much come to be the poster child for poor design. (“Norman Doors” would also be a great name for a band, by the way.)

Now, there are plenty of examples of “misplaced creativeness” in industrial design (where I guess doors would fall). Lately, though, I’ve been seeing lots and lots of examples of it in software, websites, and apps. And this is as functional a space as that for doors, and coffee pots, and stoves, and bathroom fixtures … and all the other real-world stuff Don liked to talk about. 

So, UX designers:  save the creativity for where it’s really needed. And if that means the print shop or potter’s wheel or woodworking shop that you hit only on the weekends, so be it! 

And then there’s this

God is on our side, but we can help him. (Rolf Molich)

One thing I always liked about doing usability is the knowledge that we are fighting the good fight. In our own small way, we are actually helping to make the world a better place. 

I mean, it’s not like we’re curing cancer here, but we are doing our own little part. If we make some poor user’s life a little bit easier, we are part of the solution – and maybe can even sleep a tiny bit better that night.

It’s not that there aren’t challenges in this space though.

For one thing, the battle isn’t over when you’ve run a test, or created a report, or delivered that report. Resistance is just human nature, whether the result of pride, stubbornness, or just plain laziness. You have to do a little selling, if not some follow-up and then even more selling. Hey, if that great suggestion of yours is actually going to help anybody, it’s gonna have to be implemented, right?

There is also a challenge that is fairly new to our work. It used to be that usability and UX were primarily about making a user’s tasks easier to do. These days, though, there seems to be a real emphasis on selling things – get ‘em in the funnel, get ‘em to click the call to action, get ‘em signed up, take their money …

Now, a more streamlined process is what users often want themselves. I’m really surprised, though, how often that’s not the case. Often, they want a little bit more information on something before they sign up. They might click on Apply Now just to see what the process is like. Quite often, they’ll even want to call to get their questions answered. 

Personally, I know I’ve often been the victim of buyer’s remorse on the Internet. I tend to be an impatient, slapdash kind of buyer to begin with. As a result, my garage is now full of stuff that wasn’t quite what I thought it would be. 

There is, however, often an additional result, something which is often not talked about. In addition to the cluttered garage, I’m also often left with a bad taste in my mouth, especially around the brand of the company whose website I was on or whose product I bought. So, congrats, guys. You got the sale. Unfortunately, though, you also lost the customer. Honestly, short-term thinking like that drives me crazy sometimes.

In general, I think it’s great to offer a streamlined process for those who want one. At the same time, though, we also need to provide the details that another set of potential personas need, want, and expect. Just include that information in a link, or on another page, or in some fashion that doesn’t necessarily slow down those first users. Heck, you might even make even more sales that way!

Buy before midnight tonight!  Not sold in stores!

 Also from Rolf:

• "A successful test is a test that uncovers many problems."
• "Help doesn't."
• "Even developers have feelings."

While hard data informs the intellect, it is soft data that builds wisdom. (Henry Mintzberg)

Sometimes I feel like a Freudian analyst in a Big Pharma world. Bear with me on this metaphor …

We are so awash in hard data these days – just like we are awash in psychotropic drugs. Now, while both of them are actually pretty good at treating symptoms, we’re not always sure how they did so or how we got ourselves into a situation where something needed to be fixed in the first place. There’s definitely some why missing in both cases.

As an old-fashioned usability engineer, though, I place great value on the why. If nothing else, I figure that, if we know why something didn’t work, we have a much better chance of not doing that again on the next project. 

And sometimes that why really needs to sink in too. I know, for example, with writers, it usually takes more than a few tests for them to finally realize that people really just don’t want to read their stuff. Once they “get it,” though, they can then incorporate some ways to make their copy more attractive – slimming it down; supporting scanning and skimming by using lists, bolding keywords, chunking, using more headers … 

Would we ever have figured that out, however, just from combing through web analytics? I doubt it. Similarly, it’s nice that an SSRI is helping you sleep and feeling better, but it’s not going to be much good and getting at the issues you have with your mother. 

That last bit brings up a very important point. Most therapists these days try to combine the two methods – prescribe a drug to handle the symptoms, then work on the issues so that the symptoms don’t come back when the drug is eventually taken away.

So it is in UX. Use your data to identify problems (a poor conversion rate, say). Then, use good, old-fashioned usability testing to see where those problems come from (e.g., too many steps). Finally, use data again to see if the solutions you came up with (fewer steps) actually addressed the problem (a better conversion rate).

Henry Mintzberg is a biz school prof at McGill

It is difficult to see the picture when you are inside the frame. (Wendell Castle)

It’s really hard to believe I’m fighting this battle again. 

One of the principles of Design Thinking, though, seems to involve designers testing their own stuff. They are encouraged to do this in full-on guerilla mode – grabbing people in coffee shops and thrusting screen shots in front of them.

Now, I will admit that their heart is at least in the right place. They are getting some feedback. It's also good for the designers to interact with their actual users. And, finally, I’m all for informal methods.

This is not, however, usability testing. First, testing cannot be done just by anyone. There are some real skills involved, skills that need to be seen, learned, practiced, and critiqued. It is very easy to bias your user, to ask the wrong questions, to intervene at the wrong point, to generally muck things up. Heck, I’ve seen my share of “professional” usability engineers who couldn’t get it right.

I’m also a firm believer that it takes a certain kind of personality as well. I’ve mentored a lot of folks over the years who have expressed an interest in becoming a usability engineer. Some people were total naturals. Others (often because they were too extroverted, or impatient, or unfocused) struggled and struggled.

Second, humans are simply not very good at objectivity. There are dozens of proven cognitive biases that show this – the IKEA effect, confirmation bias, the backfire effect, belief persistence, denial … And based on the resistance I sometimes get from mere observers, I can’t imagine that having those folks leading the tests instead of me could possibly do anything other than make things worse. 

One of the stories I like to tell in this regard involves a favorite designer of mine who was asked to play the “computer” (i.e., shuffle the papers) in a test of a paper prototype. His body language was comical. At one point, he actually spun around in his chair when the user, who had been struggling mightily with a task, finally got it right. A brilliant designer who has since gone on to a very successful career, I might add. I wouldn’t ask him to test his own stuff though. Heck, it would probably never occur to him to do so anyway. 

Tell you what … Give the usability engineers the tests and we’ll let you guys do some of the upfront research. It’s a lot harder to muck that up, plus it can really help you get to know and build empathy with your user. Just stay away from your designs though. And don’t be afraid to ask us for advice.

I have to give this guy credit, as Wendell Castle was actually a designer himself (and of art furniture, no less)

No one ever listened himself out of a job. (Calvin Coolidge)

Boy, people sure do love to talk. For a usability engineer, though, that’s a great thing. If they didn’t do that, the think-aloud method would have never seen the light of day, and I’d have probably had a career doing something else entirely.

I probably don’t need to tell you all that however. In the lab, listening is our main duty. Not only do we need to listen though. We also need to listen in the right way. 

You’ve probably heard of active listening before. It’s really just a set of behaviors we can use to make sure that listening isn’t just simply a matter of waiting for our turn to speak. It includes things like demonstrating attention, monitoring body language, paraphrasing, asking open-ended questions, probing, and watching for emotional impact. And that’s a great start. 

Some other things we can do include simply shutting up. (I’ve often said the best tests are the ones where I don’t say “boo.”) And when we do intervene, we need to be brief and completely unbiased. Our real job is simply to keep the user talking. Three particularly valuable tricks (which I learned from Judy Ramey, at the University of Washington) include:

• Simple saying “uh-huh”
• Echoing what the user just said (“You like that feature …”)
• Repeating the user’s incomplete verbalization (“You think that …”

What usability engineers sometimes forget, unfortunately, is that they can apply those same skills outside the lab as well. And, when I say that, I’m not just referring to on-site testing or field studies either.

We can definitely use those same skills when we interact with the people we work for and with. An obvious spot to do so would be a stakeholder interview. It can also, though, come in handy in meetings, phone conversations, hallway drive-bys, and in pretty much any interaction we might have.

In fact, at this point in my career, I’ve become so good at it that I have colleagues jokingly accuse me of pulling “jedi mind tricks” on them. And, who knows? Maybe they’re right.

Our 30th president was after all

also known as “Silent Cal”

Creating a good UX is not a design problem, it’s a power struggle. (Alan Cooper)

I like to joke that I work in a sausage factory. Now, the various companies I’ve worked for over the years have produced some mighty tasty sausages. Our customers would be shocked, though, to know what actually goes on behind the scenes in the creation of their particularly delicious software, website, or app. 

It’s really not too surprising if you think about it though. First, there are usually way too many chefs in the kitchen – the client, upper management, the design team, IT, legal, usability … And everyone has their own opinion – if not axe to grind.

Further, there’s typically no set recipe. Oh sure, everyone tries to formalize the process somehow. But what all that usually devolves into at some point is a good, old-fashioned knockdown, drag-out fight. 

And I think that’s just human nature. We all pay lip service to collaboration, but there are always going to be dominant types who fight for their way as they climb up the corporate ladder. Ever been exposed to the DISC personality typology? It’s the only one I know that actually is quite honest about all this –  with D meaning dominant, S submissive, and C compliant (I is for influencers, by the way – sort of dominant types who are also pretty nice). Other folks may simply have fallen in love with their own design, want to get their own two cents in, have poor impulse control, or just possess an overly sized ego. 

I have noticed, though, that some companies are a little better at managing this than others. A lot of them, for example, have solved the problem by simply being very hierarchical. Of course, unless you’re the U.S. Army, this really isn’t the optimal solution. (To tell you the truth, though, I actually prefer this structure to the Darwinian free-for-all.) And I’ve also worked at some companies where people were actually pleasant to each other, weighed the evidence, and tried to make the right decision. Shocking, I know.

Well, one thing a usability engineer always has going for them is the evidence. I find that can have a lot of weight, even in the middle of those knockdown, drag-out fights. And as for those types who aren’t interested in evidence and live in a alternative fact-free universe? Well, those are fights I don’t care to even get involved in.

Though it’s definitely not just Microsoft

(Thanks to Manu Cornet for this)

Cooper also said:

• "Things that behave differently should look different."
• "The fanatic preparation for the possible has the inevitable consequence of obscuring the probable."