Tuesday, September 10, 2019

I just like to know. (Winnie the Pooh)

Researchers are like that. They really do just want to know.

And that makes them a little bit different from everyone else they work with. They have no axe to grind, no dog in the fight, no skin in the game … whatever cliché you happen to favor.

Honestly, they just want to know if something’s going to work or not. Everyone else seems to have an agenda. The designer is probably just pulling for what they came up with. Their manager, on the other hand, may simply not want anything to come up that might make them look bad. The business probably has some pet idea that they want to make sure gets baked in somehow. Developers might want to make use of some cool widget they just saw somewhere. And the executive vice president … well, who knows what they want or are thinking? (Hopefully, they’ll just go away.)

Now, that’s not to say that a usability engineer might not have some predictions. But, like a true scientist, they will put those aside and, instead, root for real knowledge. I am actually right a surprising amount of the time (hey, 30 years, 4000 users), but the times I’m not are the ones I remember and enjoy the most. 

And that’s because I am adding to the corpus of knowledge. Now, that can mean something at a pretty low level (that page really does need some online help, and my team really needs to know that) but at a pretty high one as well (help really adds a lot to a system, but it needs to be contextual and speak the user’s language - and pretty much everyone in UX needs to know that).

The whole idea, though, is to keep it humble. In fact, I am much more psyched about a test where I was wrong than one where I was right. How often does that happen among the rest of the team? I’ve actually found some experienced designers who are right there with me all of the way. For the rest of them, though, I think they could take some advice from lowly ol' Pooh Bear.

By the way, here’s the full passage:

Pooh was sitting in his house one day, counting his pots of honey, when there came a knock on the door.
“Fourteen," said Pooh. "Come in. Fourteen.  Or was it fifteen? Bother. That's muddled me."
"Hallo, Pooh," said Rabbit.
"Hallo, Rabbit. Fourteen, wasn't it?"
"What was?"
"My pots of honey what I was counting."
"Fourteen, that's right."
"Are you sure?"
"No," said Rabbit. "Does it matter?"
"I  just  like to know," said Pooh humbly, "So as I can say to myself: 'I've got  fourteen  pots  of  honey  left.'  Or fifteen, as the case may be. It's sort of comforting."

Hmm, had no idea Pooh was a quant.
Image result for winnie the pooh technology
Winnie the Pooh meets technology - 
Technology wins

Monday, September 9, 2019

People’s minds are changed through observation, and not through argument. (Will Rogers)

Yup, that Will Rogers. You know, the cowboy humorist? Western actor? Newspaper columnist? Radio personality?  Vaudeville performer?

Kind of like Mark Twain, though, Will Rogers had so much native sense that his downhome sayings can be applied to almost anything – even something as esoteric as usability and UX. To tell you the truth, I’m a little surprised that this quote was actually so direct. Surely, this must have been translated from something with an “ain’t” sprinkled here and a “fixin-to” sprinkled there. Honestly, it sounds more like something Jakob Nielsen might have said.

Be that as it may, it is, quiet honestly, the whole secret of our profession. You know, it seems like everybody’s got an opinion about design – from the designer, to the writer, to the IA, to the developer, to marketing, to the developer, to the VP … But you know whose opinion really matters?  The user’s!

And how do we best get their opinion?  Well, people have come up with quite a number of different ways to do so.  I’ve touched on those in a number of different posts:

What’s really best, though, is good, old-fashioned usability testing.  I don’t think there’s a better way to get rich, unbiased, and convincing data to take things out of the realm of conjecture and guide discussion down real, practical avenues that can lead to solutions that will really mean something for the customer. 

And, guess what?  As a usability engineer, you get to do just that!

Thursday, July 25, 2019

Our product is a slot machine that plays you. (Ramsey Brown)

Oh dear! That’s not good.

And just in case you think you may have misheard that, I’ll have you know that Mr. Brown is the CEO of the aptly – and rather bluntly – named Dopamine Labs. Yup, this outfit aims to “hack user engagement and retention using models from neuroscience,” “change … human behavior with unprecedented ease,” and “rewire user behavior and drive your KPIs.” Charming.

Of course, there’s all sorts of palaver about using it only for good … But it does sound, though, like their honesty may have provided us with something of an honest-to-goodness smoking gun when it comes to the motivation behind tech addiction.

I mean, we’re all familiar with the classic quote, “If you are not paying for it, you're not the customer; you're the product.” Now, that's not exactly something that can be traced back to Jack Dorsey or Mark Zuckerberg, right?

But here, we have a quote that we can trace directly back to a VC-funded Silicon Valley outfit. They’re certainly no Facebook or Twitter or Snapchat ... at least, at this point.

What is he actually talking about? Why, intermittent reward, of course. What’s that? Well, it’s a psychological principle that dates all the way back to B.F. Skinner. It basically states that if you never get a reward, you’ll give up; if you always get the same reward, you’ll eventually get bored; but if you get a reward seemingly randomly, you’ll get hooked. It’s the idea behind slot machines … and email, and Facebook, and all sorts of social media and tech in general.

The dopamine connection? It’s the neurotransmitter that drives all this. Though many people mistakenly identify dopamine with pleasure, it actually drives seeking behavior. 

And this basic human chemical – one that we are largely unaware of, have no control over, but that drives large parts of our behavior – has been hacked by Silicon Valley to make rich people richer, with no real thought to any of the consequences or ethics involved. Charming indeed.

This is either B.F. Skinner or some kind of space alien

Tuesday, July 23, 2019

Just because it isn’t done doesn’t mean it can’t be done. Just because it can be done doesn’t mean it should be done. (Barry Glasford)

I was listening to something on NPR today about the new version of The Lion King, which just came out. In case you’re not au courant with all things Disney, the new one is all CGI, with absolutely no animation, unlike the first one. One of the panelists hated the new version, and used almost this same quote to justify his stance. Even though I haven’t seen either version, he made some excellent points, and I heartily agreed with him. 

Personally, I’m familiar with the quote from my own field, but I can definitely see where it could apply almost anywhere. In fact, a quick Google search led me to links related to the Bible, feminism, travel, self-help, and – OMG! – Disney’s new Lion King.

Interestingly, though, most of those results focused on the first part of the saying. Now, to me, there’s no real insight in that. That’s basically a, “Well, duh, so what?” 

The real wisdom is in the second part. In other words, this is really a matter of balance. So, in addition to being innovative and creative and ground-breaking and all, we also have to be aware of the possibility of conflicting goals (and unintended consequences as well).

I think that’s especially important in the field of UX. So, while designers, developers, and marketeers may have fallen in love with some new “kewl” way of doing things, the team really does need to ask itself whether that’s genuinely helpful, or right for this audience, or for this context – or whether it simply gets in the way (or is even impossible to understand or use). Otherwise, all you’re really doing is showing off.

A perfect example of this just happened recently at work - one of my designers came up with a scrolling marquee. Now, in our field, brokerage, this does make some sense. You’re probably familiar with old ticker-tape-style marquees outside and inside actual brokerage offices. So, this is really just putting something like that online. And there is at least one competitor who does that as well.

At the same time, though, there are also some good arguments against it – it’s distracting, there are accessibility issues, it can remind users of those cheesy marquees on amateur sites that date back to the 90’s …

Well, I wasn’t able to convince anyone to ditch it. But it did prompt this post. And we’ll definitely see who comes out on top after a little usability testing.

Tuesday, June 11, 2019

Writing reports doesn’t change anything. Acting on the findings does. (William Horton)

If there’s one thing that gets under a usability engineer’s skin it’s ignoring their findings. 

Now, I realize that UEs are also realists as well. Yes, we are smart enough to know that legitimate business decisions can trump all. And we are also aware that schedules and deadlines might mean some change will not make it into this release (though we do assume it will be in the next one). Finally, we also realize that some changes are harder than others (though there are, of course, those developers or vendors for whom every change seems difficult and costly). 

And experienced UEs also appreciate that negotiation is an inevitable part of any process. They pick and choose their battles. No use falling on your sword for a missing comma or a particular shade of yellow.

Those kinds of UEs also realize that not everything is worth changing. In fact, I think there’s no surer way of showing your greenness than by expecting that all issues are equal, and that you will get your way with everything that came up in the test just because … it came up in the test. 

(That last bit is especially a problem for UEs who think a report is a simple dump of everything that happened. I’m always amazed at the number of UEs who seem to feel obliged to report one-offs or simple, straight-up observations. Yeah, that’s interesting – especially if you’re a researcher – but may not be that actionable to your audience.)

So, all we ask is that you seriously consider what we heard back from YOUR USERS!  Don’t like our suggested fix? That’s fine. Do address it somehow though. Got a good reason for going with something else? No problem. Do tell me a little more about that though please.

I once did an audit (at a former company) looking at which clients actually acted on issues and suggestions from test reports and which did not. Interestingly, the one client who complained the loudest and dragged their heels the most were the ones who made the most changes. Conversely, the one who seemed the most enthusiastic, spoke our language, and got along with us the best rarely made any.

In other words, the latter seemed to think that simply running a test was what usability testing was all about. Maybe it was an exposure thing. Maybe it was interesting in itself, but not really worth getting all worked up about. Maybe it was just magical thinking. 

The former, though, realized that their job was just beginning after a test was over, and that they were actually going to have to roll up their sleeves and do some hard work. Funny … Looking back, I think I actually preferred working with those guys.

Thursday, May 30, 2019

The most important consistency is consistency with user expectations. (Bill Buxton)

So, internal consistency is definitely important. And consistency to standards is huge as well.

But there is one final consistency to keep in mind. And that is consistency with the user’s mental model and with their own actual experiences. And that consistency just so happens to trump all others.

Let me give you an example. I work a fair amount with mobile teams. And, for some reason or other, those teams include a lot of Apple fan boys and girls. Whatever the issue, everyone always seems to defer to Apple standards – even when those standards are woefully inadequate or just downright wrong. It didn’t matter if 10 out of 10 users had the same problem with something that met standards, the team just wouldn’t budge. 

Another example comes from accessibility. I’ve worked at a couple of companies that took accessibility very seriously. And that means that they didn’t just stop at following all the WCAG guidelines. I found very early on in my career that those guidelines are necessary, but not sufficient. Testing with disabled users typically uncovered issues that, though the team had followed all the guidelines, could still stop them in their tracks. 

In general, I am a huge fan of standards. Users do not want to think (thanks, Steve Krug), and predictability is often their best friend online. 

In some cases, though, there is something else, something important that needs to be addressed but can often be overlooked. And that is the actual users’ experience. Trying to shoehorn these users into something that just doesn’t fit their own experience and way of thinking is going to cause no shortage of blisters, cramps, and sore feet. 

Canadian Bill Buxton is one of the early pioneers of HCI
(and is currently at Microsoft)

Wednesday, April 17, 2019

Easy is hard and hard is easy. (Unknown)

In particular, what’s easy for the developers, or the design team, can often be hard for the user. If you didn’t put some time into knowing who your users are, put plenty of thought and work into your design, and then test it to make sure it actually works, you’ve left the effort mostly on the user’s shoulders. They’re the ones who will have to figure out what you’ve slapped together. 

Conversely, what is easy for the user typically had a ton of work put into it. Systems that truly understand their users’ needs and wants and address them directly and elegantly don’t just happen on their own. You first have to make a concerted effort to find out who your users are, what they want, and how they operate. You then to have translate all that into an experience that will, if not delight them, then at the very least not draw negative attention to itself.

And that’s the interesting thing here. You can put a ton of work into designing something, and then count it a roaring success if the user never even notices it. Users come to your website or use your software to get something done. If they’re able to accomplish their goal without too much fuss, you've won!

(As a usability engineer, I’m always struck by how brief users are when something goes smoothly – “That was nice,” “Pretty easy,” “I like that.” On the other hand, users are never short of words when something doesn’t go right.)

If, however, your UI frustrates them in their goals, you have effectively made them work for it. And people don’t like that. Humans are inherently lazy creatures. Sure, we can accomplish quite a lot if we put our minds to it. Figuring out a poorly-designed system just to buy or sign up for something is not typically where we would care to do that.

Training for a marathon? Sure. Learning a second language? You bet. Spending 30 minutes trying to figure out how to expense that last business trip or register your car? Definitely not.

For some reason, this quote seems to be popular with gamers