Thursday, December 2, 2021

Effective error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. (Microsoft)

Honestly, is this still a thing? If memory serves me correctly, my first conference presentation was about this very topic. Forgive me for having a little trouble remembering, though, as that was all the way back in the 1980s.

I guess, though, not everyone in UX these days was around back then. Heck, I would imagine the great majority of them probably hadn’t even been born yet. 

That said, I do see a lotta UXers without much background in UX as well these days – designers with fine arts degrees, content strategists who studied Shakespeare or did the sports beat at the local paper, project managers who have backgrounds in sports marketing … Funny, though – it was much the same when I started.

But I digress …

I’ve always liked to see these ideas in user terms – i.e., the things that a user might actually ask. Is something wrong?  What is it?  How do I fix it?

In addition to that, I think it’s also important to speak the same language as the user. So, no “invalid operators,” “bad requests,” or “system error codes.” (By the way, a lot of these come from the days when developers wrote error messages. Don’t be like them!)

Related to that is to “speak human.” Just think of that poor user, who is obviously already having problems. The last thing they need is a “fix” that doesn’t fix anything, or that talks down to them, or confuses them, or makes light of their situation. No better way to guarantee their going from mildly annoyed to seriously pissed off.

Finally, be specific. Be concrete. Use examples. This extends to both how to fix the problem as well as explaining what went wrong (within reason, for the latter – remember who this is being written for). So, no more “enter a valid number,” “please try again,” or “correct name and resubmit.” Human minds tend to be a lot more concrete that abstract. What exactly constitutes a valid number? I can try again, but is there something I should be doing differently? What exactly was wrong with the name I entered?

Overall, think in the terms that the user might. And that’s really the main idea here. No matter who you are or where you came from, just think like the user. And if you look at it that way, it is true – the basics never really go away.


The more things change …

Tuesday, November 23, 2021

There are downsides to everything; there are unintended consequences to everything. (Steve Jobs)

Unintended consequences are a huge part of the tech world.  Facebook was going to bring the world together, remember? Instead, we got fake news, reality filters, abuse & stalking, depression & alienation, erosion of privacy, and the destruction of local journalism. So much for social media.

How about the sharing economy? Well, for Uber, we’ve got price surging, physical abuse of drivers & passengers, drivers who can barely make ends meet, drivers with criminal records, cabbies being put out of business, and a corporate culture that looked like a cross between Animal House & The Wolf of Wall Street. For Airbnb, we’ve got party houses, destruction of historic neighborhoods, stolen & damaged items, breaking of local laws, exorbitant fees, and illegal subletting. So, so much for that.

Amazon? Twitter? WeWorks? Don’t make me laugh.

I wonder if Jobs had any regrets. I mean other than Foxconn suicides, sweatshops, slave & child labor, overpricing, walled gardens, planned obsolescence & incompatibility, anti-competitive practices, tax dodging, spin, secrecy, environmental issues, digital addiction, Apple maps, scandals (Fortnite, batterygate, John Wiley & Sons, Think Secret), as well as what an awful person Steve Jobs actually was ... 

Honestly, maybe the only unintended consequence he really cared about was getting found out.

Or maybe that reality distortion field really did work - perhaps even on himself.



Monday, October 25, 2021

Trust the data! (anonymous)

Well, yes and no.

Just think about Covid.  There’s plenty of data out there.  Which, actually, might be the main problem.  There’s just too much of it for the average Joe or Jane.  

In that regard, this really becomes more of a question of, “Who am I going to trust to make sense out of it all?”  Indeed, it all kind of boils down to the old question, “What’s your source?”

Now, I’m not going to do my own research on this particular issue. I will do plenty of research, though, on where my data's coming from.  

Even if I trust the source, though, I’m going to be a lot less trustful when that source simply dumps a bunch of data in my lap.  How am I supposed to make sense of it?  Isn’t that their job?  Why would they put the burden on me?  I’m not buying it.

How does all this apply to UXR?  Well, think of your own client.  They’re probably drowning in data.  Your report out for a usability test, or competitive analysis, or 3rd party research, or whatever is not the only data they will be dealing with that week.  They’re probably also got a ton of stuff from analytics, vendors, dashboards, KPIs – you name it.

So, the question is really, "How can my stuff rise to the top of the pile?"  And the answer to that should be, “How can I make it easier for them?”

Clients need reports that:

  • Are short & sweet
  • Get to the point
  • Are clear & well-organized
  • Are actionable
  • Are convincing
  • Involve at least some data (number of users, quotes, clips)
  • Build trust

Remember, the report is not about you - your methodology, findings that only you find interesting, interminable FYIs, clever but hard-to-interpret diagrams, simple brain dumps (because those are so much more easy to do), fascinating one-offs or rat holes ...  It’s about the system you’re evaluating.  In particular, it’s about how it’s performing & how that can be improved.  And that needs to get to your client.  When it really comes down it, it’s really all about that audience of yours.



Monday, July 12, 2021

A user interface is well designed when the program behaves just as the user thought it would. (Joel Spolsky)

Ah yes, mental models. How I love them. And how helpful they are. They also actually come up a surprising amount. 

I find that they are often to blame when it comes to sneaky, more complex problems – i.e., ones that aren’t obvious from the start, like labeling or inconsistency or text size ... When you really have to wrack your brains over what just made that test bomb so badly, mental models are often the culprit.

Think about it though. When there’s a mismatch between your model and the user’s, it can be a lot like talking with someone at cross purposes or, worse, speaking two wholly different languages. 

I mean, honestly, hand gestures and middle school French are only going to get you so far. For a truly smooth interaction, you and your user really need to speak the same language, be on the same page, sing from the same choir book …

Now, all mental models are are simply ways for people to understand complex systems or ideas. I don’t need to know the details of the internal combustion engine to know how to drive a car, or a degree in library science to check out a book, or machine language to use a word processor. 

All I have to know is enough so I can use the car or library or spreadsheet to accomplish what I set out to do. Too much detail, and I’m overwhelmed. Not enough, and I can’t predict how the system is going to work and what I‘m supposed to do. When my model is just right, though, it’s a super-handy way to make my way around the system and accomplish my goals.

There are three main problems with mental models – in particular, when the system:
  • Totally lacks a model 
  • Has a model, but it’s too complex or inconsistent to figure out
  • Has a model, but it doesn’t match the user’s model

In general, though, they’re great things. Probably the most important part is making sure that we understand that last bit (the user’s mental model) and then build around that. Using a mental model that makes use of what the user knows from the real world can also be very helpful (you know, a metaphor). Perhaps, most importantly, we just need to use them more – and more consciously.


Joel’s a developer with a real eye for UX. He created Trello; was the major factor behind Excel, Visual Basic, StackOverflow; has authored 5 books; and may be most well-known for his blog, Joel on Software.

Monday, June 7, 2021

Would you like to find out about your problems in the lab, or on Twitter? (Susan Campbell)

This actually happened to me once. 

It started out as a nice New Year’s Day. I hadn’t partied too hard the night before, and wasn’t finding it too difficult to wake up.

Just then, though, I got a call from, of all people, my boss. Now, she wasn’t the type to call and wish me a Happy New Years, so I scrunched my eyes, tilted my head, frowned, sighed, and picked up the phone.

What I could make out from her somewhat incoherent call was that something was terribly wrong with the new look and feel for our authenticated site that we had just rolled out on the stroke of midnight. Turns out users did not like it. The issue, which seems to indeed have started on Twitter, had gotten all the way up to the second-in-command. 

To remedy the situation, the higher up wanted to do some emergency usability testing. “Some what?” I enquired. My boss tried to make some sense of it and explain it to me. We talked some more, and eventually agreed to come in to the office to just to make the higher-ups happy. They were going to supply us with some customer names, and involve some others so I could coordinate testing times with them. It was all a bit crazy.

Luckily, none of this could really happen (on New Year’s Day, mind) without a major act of government, so it all eventually petered out.

Now, here’s the kicker … We had actually done some usability testing – actually, lots of usability testing. Turns out they had just ignored all my results. But that’s a topic for another post.

Susan is VP of UXR at HBO Max

Thursday, April 22, 2021

Why would I tell you what you are doing well? (survey respondent)

Why indeed? If I point out something that you’re doing well, what are you going to do about it? Pat yourself on the back?

How about, though, if I tell you what you’re doing poorly? Now, there’s something that you can actually do something about.
 
And that’s what that respondent proceeded to do. And I say “thank you” to them for it.
 
I mean, it’s always nice to know when you’re doing well, right? At the same time, though, this really isn’t middle school any more, is it?
 
The end goal here is to give the user the best experience possible. So, while kudos can help you know what’s working right (as well as give you the warm fuzzies), they’re never enough. What I’m really interested in is finding out the things that aren’t working, that are still getting in the way of that perfect experience, the things we can fix up.
 
If you’re a designer, that’s what you should be most interested in as well. I do find, though, there is often some resistance to the negative, as well as a distinct clamoring for the positive.
 
Now, as a usability engineer / user researcher, I do try to soften the blow. Especially with more junior designers, I’ll bend over backwards to make sure I’m giving plenty of positive feedback, as well as pitching the negative in as acceptable way as possible. Honestly, I just want to make sure the issues get addressed.
 
With more senior designers, however, I do like to cut more to the chase. In fact, I find they appreciate that approach as well. Heck, we both know they do good work, right? We’re also both really committed to delivering the best user experience we can, aren't we? Finally, we’re both also experienced and mature enough that our skin is probably a little bit thicker as well.
 
And, if you are a more junior designer, that’s exactly what you should be shooting for – focusing on the user, looking forward to their feedback, and rolling up those sleeves and getting to work.



Wednesday, March 3, 2021

There is always an aspect of coercion to design. (The 99% Invisible City)

It is so nice to hear this coming from a couple of designers. 

Actually, you might be surprised to learn that Roman Mars and Kurt Kohlstedt (the authors behind the book and the podcast) are not designers. Sure could have fooled me. Boy, do they ever speak the language (and look the part as well).

I think they’re really onto something here though. And it may even be something that real designers sometimes have a hard time seeing.

Designers sure are hot these days. Design Thinking and “design thinking” (the light version that seems to pervade everything nowadays) make it sound like designers could solve all the world’s problems given enough sticky notes and ideation sessions.

What they often forget, though, is their incarnation in a previous life. Yeah, industrial designers came up with some cool stuff, but most graphic designers (where most designers these days come from) can trace their lineage back to creating advertisements. As that quote above goes on, “In the commercial world, design is used to get you to buy things you don’t need.” And with the commercial world moving online, that has come to be even more the case.

It wasn’t always that way though. In the beginning, was the developer. It was something of a golden age for them, and they were pretty much left alone to do their thing. Unfortunately, their thing was not a user-friendly UI – something that became very apparent as soon as the general public started using computers.

And this is where usability types stepped in. They helped make computers easier to use. Pretty soon, pretty much everyone could make their way around a computer.

Usability was, unfortunately, spread a little thin, so a much more common development idea was to match up the business with the developers. And that’s basically all Agile really is – we’ll tell you what to build, and then we’ll leave you alone to build it.

(As you probably know, usability is not a basic part of Agile. If you’re going to get it in there, you’re going to have to bolt it on. Same for UX in general.)

And that’s where design came in. They actually make some real sense as the intermediary between the business and the developers, especially if user experience is something given more than a passing nod. 

They also, though, make a good match when it comes to selling, or persuasion, or coercion if you will. And that’s what the Internet has become these days. How do you grab people’s attention? How do you get them to click that call to action? How do you get them to sign up for that account, purchase that item, or share that personal info as quick as possible? How to get them in the funnel? How to get them to stay there? How do you get them to buy, buy, buy?

Hard to believe, but there was a time when UX was a lot more about the user – helping them find some info, do a task, solve a problem… And I miss that.

Roman at the top, Kurt at the bottom

Friday, February 26, 2021

Web analytics is transforming user behavior from a puzzle to a mystery. (Jeff Sauro)

Aren’t numbers great? Personally, I’m a datahead from way back. Can’t get enough of ‘em. 

And they’re especially suited to my world of the web and user research. Hey, you’ve got real-world interaction; tons of data points; no facilitator or test bias; instant, real-time information …

The one thing that’s missing, though, is the why. Why did 32% of all prospects drop off at that point in the application process? Why are only 48.5% of users ever getting to checkout?  Why do only 2.36639% of site users ever go to page X? What are people doing when they’re spending that average 27.3544 seconds on page Y?

Now, that’s not to say that there won’t be plenty of ideas. It sometimes amazes me how open to conjecture, projection, and confirmation bias some numbers types (business folks, typically) can be in these situations.

I had a perfect example of this phenomenon just the other day. One of our web analytic types had put together an excellent presentation on my group’s online application process. He sliced and diced the data by date, time, user type, device, site behavior, application page … Heck, he might have even have had eye color and Zodiac sign in there somewhere. It was awesome.

At one point, though, he stopped and wondered about something. In particular, he was wondering why so many people would abandon the application at the BYB page. (This is the page, at the beginning of the application, where we tell users how long this will take, what they’ll need, and so on. "BYB" stands for "before you begin.") Not too surprisingly some business types jumped right in with some possibilities – all with different degrees of being half-baked, fully-baked, or not baked at all.

Luckily, I was listening in and could help everyone out. I often test our site’s product pages. Typically, I just have the user check out the product page and see if that product is “right for them.” 

One interesting thing I’ve found over the years, though, is that users in this situation often click on the Apply button (which, of course, takes them to the BYB page). They usually comment that they just wanted to see what the application process was like, or that they were looking for some bit of information that they couldn’t find on the product page.

The analytics guy thought that was really cool. The business types, on the other hand, have never been anywhere near as excited (they’ve heard this from me more than once).

I think at least he and I recognized that this is never an either/or situation. Quantitative and qualitative help inform each other. Results should always be triangulated, however you might do that. You really shouldn’t have one without the other.

Along with Jim Lewis, Jeff is one of the great numbers guys in the field of user research 


Monday, January 11, 2021

The arguments are so vicious because the stakes are so low. (Henry Kissinger)

For some reason or other, this always seems to raise its ugly head on internal projects. My experience with these is that everyone tends to think they’re an expert, there’s no natural chain of command, the people who tend to volunteer are often suck-ups and preeners … Add in the fact that no one’s going to pay attention to the end results anyway, and you’re all set!

Not too surprisingly, my first experience with this goes all the way back to grad school (the original quote was about academia, by the way). Now, that stuff really did amaze me. In fact, it’s probably why I don’t have a PhD at the end of my name, to be honest.

One of the great attractions about industry was that I didn’t have to worry too much about all that. Either the stakes were pretty high, or people simply weren’t that into fretting and drama, and just wanted to get something decent out the door.

At the same time, I happened to be very lucky in that I always seemed to find myself in situations where I was encouraged to sample the academic side of things. Conferences, papers, speaking engagements, guest lectures, organizational work were all encouraged. It was the best of both worlds. 

I also found that I was most attracted to the academic stuff that was only of the most practical nature. So, UXPA over CHI, the Journal of Usability Studies versus Proceedings of the IEEE, Jakob Nielsen before Don Norman …

Sometimes, though, even industry can turn a bit petty. Luckily, though, it seems to be mostly in those unusual situations, where the normal guardrails are not always in place. And in those situations, it’s always helpful to remind myself that it may not matter all that much, and that I can always save my energy for something that does.



Tuesday, January 5, 2021

Experience: that most brutal of teachers. But you learn, my God, do you learn. (C. S. Lewis)

I love being wrong. I just adore making mistakes. Especially if I can arrange to do that in front of a large crowd or a bunch of people that I look up to.

Yeah, right. Just like every other specimen of Homo sapiens out there, this is not exactly my favorite thing. There’s nothing in the world that will transform me into a petulant, defensive five-year-old quicker.

Now, this sort of thing will also certainly get my attention. But, heck, getting hit over the head with a hammer would do something very similar. That said, I can be pretty thick at times. So, probably not a bad idea, all things considered. 

And these are also the times when things really do sink in. And that’s not just because of the huge dent on the top of my head either. Now, they might take a while to totally sink in – and a lot of sensitive feelings to get over as well. But it really is pretty effective.

Now, I tend to be really terrible at it, but when experience is pointing something painful out to me, I do try to calm down, shut up, and take it in. Once again, I’m not always successful, and it certainly doesn’t happen instantaneously, but I’ll usually get there eventually.

And for you designers and developers and project team members out there, do know that user researchers get feedback too. Yup, we’re not just dumping on you.  ;^)

You’ll be happy to know that user researchers dump on each other as well – if they’re part of a well-functioning group, that is. We’ll also go directly to our clients and have them dump on us – once again, if we’re managed well. 

And, finally, know that experiential feedback is not just something for newbies. Now, the beginning of your career is ripe for this sort of thing, but do realize that the rest of your career will be far from immune. New tools, new methods, new users, new domains, new teams, new companies, new technology – all provide plenty of opportunities for experiential learning.

Learning is good. Learning can, however, be painful sometimes. Just hang in there though – you’ll learn lots.

Hint:  He was against it (technology, that is)