Friday, January 11, 2019

There is no such thing as a “user error.” (Anonymous)

Boy, do some users love to blame themselves. You know the type … “Oh, I’m not very good with computers.” “You know, my husband would be a lot better at this.” “Man, that was dumb of me.” In my informal taxonomy of user types, I call this type the “Charlie Brown.” 

I usually just tell them something along the lines of, “Oh, no, not at all.” If they persist, or if it really seems to be an issue, I do the traditional spiel about “this is not a test of you.”

If that doesn’t seem to be getting through, though, I usually follow that up with:


“This is a test of the system. You can do no wrong here today. If there’s a problem, it’s a problem with the website [or app or whatever], and I want to hear about it.  That way, we can fix it up, and it won’t be a problem for others.”

I might also talk about how they were recruited just for this test and are the perfect person for it, that the system was designed for someone just like them, and that I’ve got 10 other people coming in that week who are exactly like them. I don’t like to do it, but if the user is really struggling with this issue, I might even go so far as to mention that other users had exact the same problem.

Now, on the other hand, there are also some team members who love to blame the users as well. With them, my approach is a little bit different. ;^)  I might start out by cocking my head, frowning, and giving them the eye. If that doesn’t work, I usually point out that this person is a customer. Now, I might also sympathize a little with them by confessing that the user was difficult for me as a facilitator and that they were definitely on one side of the sophistication scale. That said, I also try to firmly get across the fact that this is a real user and needs to be addressed somehow in the design.

And if that doesn’t work, I have no hesitation about reading that observer the riot act. That usually involves reiterating that the “user is not you,” there are many different user types, empathy is a sure sign of a good designer, and – finally – these “idiots” also just so happen to be paying your salary.


Wednesday, December 5, 2018

Design is the art of gradually applying constraints until only one solution remains. (Anonymous)

And that, basically, is the difference between art & graphic design. That said, I do, however, meet a lot of graphic designers who wish they were – or were trained to be – the former rather than the latter. Now, this may be no more harmful than the copywriter who’s working on that novel at home, but it really does seem to be something to watch out for. 

When you’re doing art, there are no constraints. You can put a crucifix in a jar of your own urine, make a Madonna out of elephant dung, or cover a skull in diamonds and post it for a cool £50 million. It’s totally up to you.

That said, your first constraint may be whether you want to eat or not. So, unless you are Andres Serrano, Chris Ofili, or Damien Hirst, you may want to try something a little more salable – something you could hang on a wall, say, or place on a nice pedestal. 

And if you’d like to eat something nice, well, you might go so far as to get a real job, like being a graphic designer for a large corporation, where they may very well ask you to work on their website. Of course, that’s likely going to be a little bit of a comedown from the woodcuts you made back in school.

But don’t give up on it just yet. It can actually be pretty interesting stuff. And, you know, when you were doing woodcuts, you definitely were working with some constraints too – primarily for the medium involved.

In a commercial space, you will have even more constraints. You will need to think about the limitations of the web and of Photoshop, but you’ll also need to think about your audience, and their goals, and your company’s goals, and your team … and all sorts of things. 

Now, you may feel have no free expression left. But here’s another way to think about it … What you’ve got instead is a chance to solve some problems. Yup, all those additional things you have to think about add interesting little wrinkles to your process and what you deliver. In fact, it can be quite a task to juggle all those things at once. But once you’re done and you’re delivered something successful, it can be very gratifying.

One thing you’ll need to look out for, though, is opting for the “elegant,” or “creative,” or “cool” solution. If it genuinely solves the problem and doesn’t get in the user’s way, great! Sometimes, though, what can seem elegant or creative or cool to you can be less than clear to your user. Just make sure you’re actually solving problems, and not inadvertently creating them.


Damien actually got $100 million for it

Wednesday, November 28, 2018

If all you have is a hammer, everything looks like a nail. (Abraham Maslow)

Abraham Maslow? You mean the hierarchy-of-needs guy? He came up with this quote?

Indeed he did. In particular, it was in his book The Psychology of Science, which came out in 1966.

Needless to say, it’s quite an old idea. But Maslow surely made it his own. His quote is a great example of, as Alexander Pope put it,  “what oft was thought, but ne’er so well expressed.” 

Indeed, the sentiment is so basic and well-accepted in psychology that it has its own law – The Law of the Instrument. 

And how, pray, does that fit in with usability? Well, I don’t believe it’s something that usability engineers and user researchers are guilty of.

Instead, it seems to be quite a common behavior from clients. In the old days, for example, they were often much more familiar with focus groups than with usability tests. So, they would ask for a focus group when they wanted feedback on a new system ... and then keep calling it that up to the test, during it, and often after!  Steve Krug’s got a hilarious video on that right here.  

These days, it’s more likely that they’ll want a usability test – even when a card sort, or some ethnography, or whatever is more appropriate. And something I’ve seen a lot recently is that they’ll take some particular form of testing – remote unmoderated, 5-second, one-click, etc. – and ask for that instead. Hey, those are typically cheap and quick, right?

So, the approach I usually use here is to first ask them what problem they’re trying to solve. I then try to help them realize that I’ve got a huge toolbox – with screwdrivers, and hammers, and wrenches, and even the occasional shingle froe. And that if we talk about it a little, I’ll make sure they get the right tool for the job.

In other words, what I try to get across is that I’m a consultant, and not just an order taker. You know, kind of like with your plumber, or electrician, or lawyer, or doctor. In other words … Please Mr. or Ms. Client: bring me a problem, not a tool. 


I always thought he must have been a great guy to have a beer with

Thursday, October 18, 2018

The purpose of life is not in making it go faster. (Gandhi)

There’s something that bothers me about technology these days. And I’m hoping that that’s more than just a reflection of my age.

I think Gandhi’s on to something here. Have humans ever been so busy as they are right now? 

Does that describe you? Are you always in front of a screen – desktop, laptop, or mobile? Do you use multiple screens at the same time? Are you triple-booked for everything? Do you constantly multi-task?

Did you know that you also might not be doing your best work? There is a ton of research out there that says that humans really can’t multi-task. Note that that means not that we’re not good at it. We simply are incapable of it – and we fool ourselves whenever we think we are. 

There is also plenty of research that says that reflection is on the wane, but also that time for reflection makes for better decisions. And also for more creative decisions – the kind that might lead to out-of-the-box solutions and real innovation. 

Making life go faster is certainly all the rage these days – what with Agile, and fail fast, and lean UX, and “move fast and break things” … Now, that might all be good for startups.  But is it good for larger companies, like an Apple?  I actually understand that Apple does not use Agile.  Hmm …

Now, more importantly, do you contribute to all this with your work? Is your company’s goal to make addictive UX? Are you in the business of short-circuiting users’ thought processes and just getting them to click on the call to action? Is that badge really necessary or is it just a shameless ploy to get the user to open up your app? Is your work distracting? Need it be? Why?

Are you part of the solution or part of the problem?  


Gandhi’s idea of technology

Let me end with this quote of his:

I hate not the machines, but this growing passion for machines. I hate the passion for the machines which work upon diminishing manpower. Some talk about machines which could spare manpower when thousands of people are thrown jobless on the streets. Yes, I want the human toil and time to be spared not just for a sect of people but for humanity. I want the wealth to be accumulated not just in few hands, but for all the people in the world. Today machines favor putting a handful of people on top of thousands.

Friday, October 5, 2018

If there is a “trick” to it, the UI is broken. (Doug Anderson)

Unfortunately, there are a lot of tricks out there right now. And I blame mobile.

Honestly, though, mobile really does have to get creative. The lack of space, if nothing else, means that we can’t be super-explicit about each and every function – there just isn’t enough room. So, it only seems logical to rely on a trick or two – gestures, swipes, double-taps, tap-and-holds – if we’re going to cram in all the functionality we want to give the user.

But how do users learner about all that stuff? Well, if it’s not “intuitively obvious,” you might have to rely on some kind of support – coach marks, demos, help … 

You know what I see a lot though? Basically, people seem to learn the most just from other people. And where I’ve seen that the most is with teenagers. They love to show each other the new app or feature they’ve just downloaded or discovered. 

Unfortunately, we are not all teenagers. So, how are the rest of us to learn?

Well, there is definitely some sharing going on within other generations (and lots between) as well. And users are definitely more apt to experiment these days (and without thinking that they’re going to “break” something).

I do worry, though, that we might simply be leaving some of those great features on the table. And, you know, that might be just fine. 

My thought here is twofold. One, we may not need to pack all that functionality in in the first place. Remember, apps are supposed to be a simpler, more streamlined version of desktop functionality. Second, we might want to limit functionality that is hard to discover to things that are more nice-to-haves, and less crucial operations that make or break anything.

All that said, I still think Doug is right. “Tricks” do not make for good UIs or good user experiences.

You put your right foot in,
You put your right foot out ...


Tuesday, September 18, 2018

You don't want to have to acknowledge that the printer is out of paper when you're trying to shut down the nuclear reactor. (Russ Benel)

Ah, yes, prioritization …

As a usability engineer, I typically see prioritization as a matter of ranking the severity of issues that I uncover in tests. I think most of us in the field recognize the need for this, though I am always surprised at those usability engineers who see it as somewhat optional.

From my standpoint, I just assume that the audience for my reports would very much like to know my opinion on which issues were particularly thorny for my users. We could set priorities as a group, but I figure they will come up with their own estimation of impact (if they’re the business) or technical feasibility (if they’re IT) on their own. What we need to do, as a team, is to identify all the variables that are in play. And for that, the team’s going to need your honest opinion – as the expert – for the usability side of things. 

Is this less important in these days of sticky-note reports, continuous collaboration, and 2-week sprints? Possibly. I don’t think Agile and Lean methodologies obviate the need for severity ratings altogether though. I mean, they might be more informal, or developed more as a group effort, but there’s absolutely no reason for them to simply disappear.

Are severity ratings subjective? Well, yes, they could be. There are, however, some fairly agreed-upon standards. The best ones are typically simple (i.e., high, medium, and low) and fairly operational (usually centering around whether the user can complete their task and how many users have that same problem). Whichever you use, though, you do need to be consistent – over time and for all your reports and report authors.

Another objective I’ve heard is that severity/prioritization can be very evaluative. In other words, I know I’ve had some reports where the executive summary had a ton of red on it. I think the objection here was that this will make an audience defensive and possibly even shut down right off the bat.

At the same time, though, a report with an executive summary like that is pretty rare. And when they do come up, I think it’s essential to get my audience’s attention and communicate that, yes, there is a very real problem here.

In particular, I want them to know – very clearly – that one issue (a major mismatch in mental models, say) really is the equivalent of a core meltdown, while another (faulty punctuation in an error message) is not exactly the end of civilization as we know it (and probably more like that dopey printer confirmation modal). 


Tuesday, September 11, 2018

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.