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

We rushed our redesign, solving one problem but creating many others. (Evan Spiegel)

Ah, the wonderful world of unintended consequences. One of my favorite topics.

Now, if you’re not familiar with Evan Spiegel, I’ll just let you know that he’s the CEO and co-founder of Snap Inc., the company that brought us Snapchat. He was also the youngest billionaire in history, at age 25, back in 2015.

What is he talking about? Well, back in the last quarter of 2017, Snap released a new design of their popular app. To make a long story short, it didn’t work. I’m talking losing 3 million users, a dip in brand impression from 30 to 8, and ad views and revenue going down 36%. Ouch!

I won’t go into the gory details of what they actually did, but suffice it to say that it was a perfect example of unintended consequences. I mean, the company certainly didn’t mean to lose all those users and revenue now, did they?

How did it happen? Once again, I won’t go into the details. Heck, I don’t even know them (though I certainly could guess). I looked around, but I’m not sure that’s something the company felt comfortable sharing.

Now, my first question, as a usability engineer, is, of course … DIDN’T ANYBODY DO ANY TESTING?  How did they know this redesign was going to work? Where did their feedback come from? Did they get any feedback?

Now, Spiegel points to rushing things, but I think there’s a lot more to unintended consequences than just that. Hubris, for example. Or denial. Or short-term thinking. Or what have you …

Now, of course, you can put a lot of thought into something before you attempt it. Honestly, though, I don’t think you can still predict everything that might happen. And that’s why I think it’s so important to get something usability-tested. A/B might work, of course, but that means it’s live. Testing lets you get some feedback in a “safe space.”  Might even give you some idea why it wasn't working.

Whatever you do, though, do something! Get some kind of feedback!

For some reason, most pix of Evan also feature his wife

It’s not what you don’t know that hurts you. It’s what you know that ain’t so. (Will Rogers)

Sometimes I prefer my clients to be ignorant. In my experience as usability engineer, user researcher, and even instructional designer and tech writer, I’ve just found it so much easier when my clients are blank slates.

Of course, clients who really know what they’re doing are the best of all. Those, however, are pretty few and far between. It’s much more common to get somebody in the middle. And, to throw in another quote, “A little learning is a dangerous thing” can definitely apply to that middle zone.

I’m always amazed at how many things people “in the middle” just don’t get, or don’t get right. There’s probably a number of reasons why however.

The first may simply have to do with exposure. Clients may have simply heard of an idea only in passing – a mention at a conference from last year, an article they once read, a conversation in the hallway. In those situations, subtleties and true understanding are really hard. Overly broad strokes and misconceptions, on the other hand, are really easy.

Usability engineers always know, though, that “it depends,” and things are never as simple as they appear. A good example here might be the number of clicks rule. A couple of years back, marketeers fell in love with the idea that everything should be a couple of clicks away from the homepage. On the surface of it, this actually made some sense.

Some unintended consequences of that, however, included some particularly dense homepages and menus. Further, results from testing showed that users didn’t really resent (or were even aware of) the number of clicks, and were happy to go their merry way as long as they felt confident where they were going. Ironically, this idea of “information scent” could be stronger with a deeper IA than with a shallower one. 

It may also have a lot to do with where you got started. A perfect example here is personas. If you have some background in marketing, when you here the word “persona,” you automatically translate that into “segments.” It’s not the same! And it can be really hard to adjust gears and understand the difference. 

That actually reminds me a lot of the linguistic concept of false friends. Not to go too far off topic, but that’s when a word you know in English, say, doesn’t mean the same as a word in another language that sounds just like it. For example, don’t say you’re embarazada the next time you slip up with something with your Spanish-speaking friends. It means “pregnant”! 

Will Rogers doing a little man-machine research 

on some early radio communications hardware

Will Rogers also said:

• "People’s minds are changed through observation, and not through argument."

It is not how much information there is, but rather how effectively it is arranged. (Edward Tufte)

I agree with this statement up to a certain point. Of course, in a typical situation this is spot on. If I had a dollar for every time I’ve flagged “grey blocks of text,” I’d be retired now. Honestly, it’s funny how frequently and consistently that comes up.

I never really tried to analyze why, but off the top of my head, I would guess it’s how all writers are trained. And that goes all the way back to grade school. Think about it. What did Miss Thistlebottom at Woodrow Wilson Elementary School want? Big grey blocks of text – each preferably with topic and summary sentences (and none of those beginning with a conjunction or ending in a preposition)!  And something similar continued through middle school, and high school, and college. The whole point was to show that you had understood a particular topic by writing about it at length. You were also trying to impress teacher with just how darn smart you were. Wordiness was something to be encouraged. Long paragraphs and sentences were a good thing.

I’ve actually seen something even for college-level students who were in writing programs. And, here, I don’t mean creative writing, but journalism, and marcomm, and even professional writing. A newspaper article, a marketing brochure, a press release are not, however, all that different from what they were writing back in 6th grade – at least in terms of structure and look, if not in quality.

Everything, though, changes when you go online. We all know that people don’t want to be made to think (thanks, Steve Krug), but it just so happens that they also don’t want to be made to read. Instead, they are much more likely to want to scan and skim. 

Now, I’m not necessarily talking about an online article here (in those situations, readers are apt to “scan and swoop”). What I’m talking about is someone trying to complete a task – sign up for something, shop for something, pay for something, find some bit of information, make a decision, do something other than just read for pleasure.

In those cases, readers will scan and skim. And the smart writer will be sure to support that strategy. And that includes using lots of chunking, plenty of lists, more titles than seem necessary, and some way to emphasize keywords. There’s no better description of that strategy (and why it’s so necessary) than some research that Nielsen Norman started doing way back in 1997.

Returning to Tufte’s maxim … 90% of the time, he’s got it nailed. In some cases, though, there really is just too much stuff. I know. I’ve seen that too.

I’ll bet Tufte never thought in a million years that 

he would be roped into a discussion about writing

A wonderful interface solving the wrong problem will fail. (Jakob Nielsen)

In other words, there is a big difference between usability and utility. 

Say you test a new system, and it performs well. It’s then released … and sinks like a stone. What just happened?

Sounds like something that worked just fine, but didn’t actually solve any user needs. In other words, it’s usable, but useless at the same time.

So, should usability engineers be testing for both conditions? Isn’t our job merely a matter of the former, and not the latter?

Well, if you really want to add some value to what you do, though you can concentrate on usability, you need to keep your antennae out for utility as well. An obvious way to go about that is to ask upfront. 

The SUS questionnaire, with its first statement being “I think that I would like to use this system frequently,” is perfect for that. Just be sure to follow up. Another thing you can do is to just ask straight out in the debrief. A question like, “Is this something you would use?” should work just fine. 

One more thing to consider is to include self-directed tasks. In other words, instead of a super-specific task that asks the user to, say, find what date check 1338 cleared, you could start out by asking them if they use checks. If they say no, you now have some information about the utility of that particular feature. You can also, of course, still ask them to complete the task (“for the sake of this exercise,” I usually say). An additional benefit of this approach is that it keeps users task-oriented, but also gets them to start thinking about the value of what you’re asking them to do. 

Now, is there a way can you stop such problems from happening in the first place? Well, it’s really not part of a usability test, but if you can get involved upfront – doing ethnography, in-depth interviews, focus groups – these are obvious places to address the utility question and to get at users’ true unmet needs.

Heck, why go to all the time, expense, and trouble of solving a problem that doesn’t even exist? Surely, there are more than enough problems out there that do.

More from Jakob:

• "The fact that surprising results happen is exactly why we conduct actual research."

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 exactly 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.

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