Wednesday, December 9, 2015

Fall in love with the problem, not the solution. (???)

I’ve actually seen this one in so many places, and attributed to so many people, that I’m a little leery of ascribing it to any one person. 

But what does it mean? Well, one thing that I see a lot these days is teams that are trying desperately to be innovative. Oftentimes, what this turns into is something along the lines of being innovative just for innovation’s sake. They might, for example, focus solely on some piece of technology (the Apple Watch, say), or some new style (e.g., Flat Design), or some new function (multi-touch gestures?), or some new method (gamification, anyone?). Whether that actually does something for their users, whether that actually solves a real user problem, seems to kind of get lost in the shuffle.

What these designers don’t realize is that, one, users really don’t care. Users typically just want to get their task done. If that involves all sorts of wild and crazy stuff, fine. If it simply involves boring things like tabs and radio buttons, well, they’re fine with that too.

What these designers also don’t realize is that, if they would only focus on the user’s actual problem, they might end up being very innovative indeed. In fact, a typical follow-up to the above quote is “… and the rest will follow.” What designers really need to understand is that all that cool stuff that they often fall in love with is simply a means to an end. 

So, how to identify, and focus on, those user problems? Well, I’ve always been a big fan of ethnographic research (also known as field studies). This method looks at users in their own context (the office, a retail store, their car, the couch at home), doing their own tasks, with their own goals in mind. That way, you can identify what’s working, what’s not working, the pain points, the gaps (and that involves the user’s whole experience, not just their interaction with computers, by the way). Next, all you need to do is sit down and analyze all the data that results (good old-fashioned affinity diagramming is my favorite way to do this). You can then brainstorm – and innovate – ‘til the cows come home.


Though I really couldn’t find a source for this quote,
a lot out there seems to point to these guys
(I'm not surprised)

Thursday, December 3, 2015

The point of testing is not to prove or disprove something. It’s to inform your judgement. (Steve Krug)

Unfortunately, there are a lot of people out there who want that proof. And the way they typically look for it is through numbers.

So, first, you’ve got your academics. They will be “purists,” and will insist on statistical significance and p-values and stuff like that. Next, you’ve got your marketing types. They’re into stats too. Finally, you’ve got your business folks. Once again, numbers types. 

So, the first thing I have to do is share that I’m actually not going to be giving anyone any real numbers (or at least not the kind of numbers they’ll be expecting). Then, I have to convince them that that’s not necessarily a bad thing. Finally, I have to break it to them that, yes, they will actually have to make some tough decisions (but much less tough than if they had nothing else to go on).

In accomplishing all that, the first thing I talk about is that usability testing necessarily means qualitative data. Now, these folks typically have some familiarity with that – e.g., through focus groups – so I always make sure to reference those. From there, I then go on to talk about trading numbers for richness. In particular, I like to point out that one great thing about a usability test is that you don’t have to guess, or impute, the reasons behind user behavior. Users will tell you exactly why they didn’t click on that button, why they preferred design A to design B, why they abandoned their shopping cart … And that can be pretty valuable stuff in coming up with buttons that they will click on, or designs that they will want to use, and shopping carts that they won’t abandon ...

Another thing that I point out is that usability testing focuses less on user preference, and more on whether something works or not. Note, though, that this does not mean QA. A system can be completely bug-less but still be impossible to use. Misnaming things, putting them in the wrong menus, burying them in footers, and so on can be just as effective in stopping a user in their tracks as a 404 page.

(And, yes, you really do need numbers for preference issues. Think of what goes on into deciding whether a feature should be added to your software. How many people would want it? How many of your main user base? How badly? Usability testing really should come after that decision, and focus on whether users can actually use the feature.)

Finally, though, I simply state that I am not calling the shots here. All I am doing is providing information. Executives may have very good business reasons behind somewhat dicey design decisions. All I want to do is make sure they know all the implications of those decisions. And what I’ve often found is that executives may not even be aware that those design decisions may result in a somewhat dicey user experience, or how dicey that experience may be. But after doing testing, well, they really don't have any excuses now, do they?

Steve’s alter ego 
(I wonder if this guy actually has a name)

Friday, November 20, 2015

Every new feature comes with a cost. (Shlomo Benartzi)

One of my favorite bugaboos is something I like to call “additive design.” This is where your original design – whether for a website, an app, some software, or whatever – starts out nice and clean and simple.  Gradually, however, things get added to it, and added to it, and added to it … until it falls apart.

Now, this can happen after rollout … or before. For the former, this is just a typical evolution over time. There are new features, or new content, or new audiences, and those need to be addressed somehow.  Unless the possibility of additions like these were considered beforehand – i.e., unless you sought to make your design scalable from the get-go – these things will tend to just get tacked on, oftentimes rather willy-nilly.

Something similar can also happen before the product even sees the light of day as well. In this case, though, it’s usually a failure on the design team to prioritize, or to push back, or to keep the big picture in mind.

Now, what really gets me about this sort of thing is the fact that only rarely do people ever even bat an eye when it come to this stuff. In particular, no one ever seems to wonder if, by adding whatever-it-happens-to-be, there would be any particular effect on what’s already out there, or on the user’s overall experience.

And it’s not just the gestalt of the thing. As an example, edge cases often come up in reviews (from legal, risk, compliance, IT, QA …). Now, that’s a topic in itself, but what the typical solution is is often to add some help, or put in an extra radio button, or throw in a link, or add another option to the menu.

And what that can lead to is a screen that was formerly nice and simple and easy to process becoming one that is just a big jumble. I realize the team’s heart is in the right place, but they just don’t realize that all that “help” might come as a cost. Perfect example of unintended consequences.

To be a little concrete here … I once worked on a project team that took a simple date field and turned it into 2 date fields, some instructions, and a help link. And all of that stuff was simply to address what might happen – i.e., edge cases. Sigh …

As usual, Nielsen Norman does a much better job of explaining this than I ever could. Check out their analysis of those new-fangled soda machines right here.


Shlomo's not really a usability guru, but does seem to have developed some appreciation for the field in his book The Smarter Screen

Wednesday, October 14, 2015

Your site is not an island. You need to fit in with the rest of the web. (Keith Instone)

I am a firm believer in standards. My arguments in favor of them are typically two:
  1. Somebody else might have thought about this before
  2. Users might actually have gotten used to doing things a certain way

As a result, one of the things I love to do on any project is a quick competitive eval. I just go out and see what all our competitors are doing. This gives me a good sense of:
  • Whether there are any standards
  • How strong they are
  • Whether it would make any sense to break them

I’m always amazed, though, at how many people simply can’t wait to break standards. They usually cite innovation, and creative disruption, and whatever buzzword happens to be current.

Actually, I’ve come to the realization, over the years, that this may have more to do with personality than anything. If you’re familiar with Myers-Briggs, I’m a (weak) S. S’s tend to be more practical, down-to-earth, and data-driven. The people who I butt heads with tend to be (strong) N’s. They tend to be more abstract, intuitive, and full of ideas. 

I typically handle my N colleagues by getting them to:
  • Focus on higher-level issues, and less on details. For example, radio buttons are a pretty darn good way to tell a user that he needs to make just a single-choice. There’s really no need to reinvent this particular wheel. Developing a wizard to help a user pick the product that’s right for them? Now, there’s something that might actually add some real value.
  • Solve real problems rather than simply coming up with random new ideas. A colleague of mine likes to make the distinction between innovation (the former) and mere invention (the latter). 

By the by, before you can solve real problems, you have to identify them. And I’ve always been a big fan of ethnography when it comes to that.

Keith may be most famous for his work in getting going
the IA Summit, UXnet, and World Usability Day
(oh, and those glasses)

Thursday, October 1, 2015

One swallow does not a summer make. (Aesop)

This one is actually posted in the observation room of my usability lab. It’s a subtle, tasteful reminder that you might want to consider coming to more than just that one usability test, Mr. or Ms. Team Member. 

Yes, I know you’re busy. Yes, I realize that usability tests are a little bit like baseball games – lots of boredom punctuated by rare, brief flurries of excitement that are easy to miss.

You do realize, though, that that one user you saw may not be totally representative of all 10 I will be bringing in this week, right? In other words, if you happen to be at the very first session, there’s really no need to completely redesign the system (or get all defensive or jump off the roof) before the 10:30.

And when it’s time for the report out, do please be a little circumspect when you’re tempted to talk for 10 minutes about the one user who had that one problem that – hate to break this to you – nobody else actually had. The rest of us did see that person, saw a whole bunch of other people as well, and determined that that original user might just be an outlier.

Yup, that’s right. The rest of the team actually attended most of the tests. And, as a matter of fact, I personally happened to attend all of them. In addition, I was paying attention the whole time as well. Finally, I spent probably twice as much time reviewing my notes, looking at the tapes, trying to figure out what it all meant, and putting it all in a form that you could easily digest.

Now, don’t get me wrong. I’m really happy you could make that particular session. And, no, I am not taking attendance. It’s just that the more users you see, the more you’ll understand and the more refined your subsequent judgments will be. No, you don’t have to attend every darn one. Heck, 3 or 4 might be enough to give you a good idea whether what you’re seeing is representative or not. 

(By the way, I actually have not found this to be a real problem for the actual members of the project team. Interaction designers, information architects, writers and even graphic designers are usually there for the duration. It’s often the managerial or business types who are guilty here. And that’s okay. In general, if these types take my report seriously and act on the findings, it’s not totally essential that they see it with their own eyes.)




And, no, Aesop was not blind. I understand 
the sculptor just had trouble “doing eyes.”

Friday, September 11, 2015

It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice. (Steve Krug)

If there’s one thing that marketeers understand about the web it’s that the more clicks it takes a user to get to their stuff the worse shape the world is in. To put that as a formula, I guess it would go something like, “clicks = evil.” 

Okay, I’m joking. Seriously, the adage is usually something along the lines of, “If users have to click more than 3 times to get what they’re after, they’ll abandon your site.”

Unfortunately, it’s really not that simple. Analytics show that users click more than 3 times all the time. And surveys and usability tests typically show no decrease in user satisfaction when they do so. In fact, the issue has been tackled by such leading lights as Jakob Nielsen and Jared Spool, neither of whom have found any real correlation between number of clicks and user satisfaction.

What they did find, though, was something a little more interesting. In particular, when the user’s choices are simple and straightforward, users are happy to drill down and click away. It’s when those choices aren’t so straightforward that problems arise.

Here’s how it works ... A straightforward path doesn’t involve much more than clicking. A less straightforward one, though, forces the user to think about each step. Add it all up, and the straightforward but “longer” path may take less time than the “shorter” but more confusing one. And even if it doesn’t, the user’s subjective impression will often make them think the more straightforward path actually took them less time and effort

Jakob Nielsen ties it to foraging theory and something called “information scent.” Like a fox after some rabbits, we users will stick with something as long as we’re pretty sure there’ll be a payoff in the end. If that particular woods or field or website doesn’t seem too promising, though, we’ll likely abandon it for happier hunting grounds. 

Clear labels give us good information scent, encouraging us to keep clicking. Poor labels – even if the “game” happens to be only a click away – unfortunately do not. 

Actually, Steve’s a lot more friendly
than this pic would make him seem

Tuesday, September 1, 2015

Help doesn't. (Rolf Molich)

Poor help. It just doesn’t get any respect. 

Whenever I run a test and the user seems ready to give up on a particular task, I always ask what they “would do now.” Most of the time, they say they would call. Some would prefer to chat, something that seems to be a lot more popular these days than in the past. And some, of course, simply want to abandon the task altogether, shut down their device, and make themselves a nice, stiff drink.

What people rarely mention is help. And that’s a shame, because they often have a decent chance of finding an answer there.

But people have also been trained to avoid help like the plague. There was a time – and there are still many systems that follow this model – where help was a completely separate system, identified only by a little help link in the upper right-hand corner.

When users clicked on that link, another window typically covered their screen. From there, they would search or browse for their particular question. So, in other words, total task interruption, major mode switching, and lots of time spent basically starting over from scratch. No wonder people shy away from help.

Given all that, how can we get people to use help again? First, don’t call it help. Second, get it out of the right hand corner of the screen. Interestingly, those two ideas are intimately related. Let me explain …

So, if you take help out of the upper right-hand corner, where are you going to put it? Well, one idea is to make it contextual, to put it on the page itself.  Face it, users typically want to get help on something they’re doing right now. They want to know what to put in that field. They want to know what button to choose. So, why not tell them then and there?

And, if you are doing that, why not go ahead and be more specific about what that help is going to be. Instead of putting “help” next to the field, why not just say, “What can I enter here?” or “Is this secure?” or whatever you think the user’s question might actually be.

A variation on this treatment is FAQs. And these are basically just all the questions the user might have on that particular page, but listed all together. Over the last few years, I’ve found FAQs have tested particularly well.

Context-sensitive and specific is definitely the way to go. Not only may they get the user to actually click on them, but they also might actually help the user as well.

Gag!

Friday, August 14, 2015

If we build it, they will complain. (John Morris)

Ah yes, transfer users. If you’ve never heard that phrase before, it’s really just a fancy way of identifying users who are moving from one system to another. Upgrading your iPhone? You’re a transfer user. Reacting to that redesign of Facebook? You’re a transfer user. Trying to adjust to that new software program at work that replaced the one you’d been using for 10 years? You’re a transfer user.

And one thing we know about transfer users is that they will squawk. They could be moving from steam-powered mainframes to gestural AI systems that read your brainwaves, and you can be as sure as the dawn that your users will protest, grumble, whine, bleat, carp, cavil, grouse.

Face it, it’s just human nature. People just don’t like change. Now, there are a whole bunch of fancy psychological ideas to support this concept – status quo bias, loss aversion, the endowment effect – but it’s just the way people are.

Think of the all the old idioms that describe just this situation. You can’t teach an old dog new tricks. Old habits die hard. The leopard can’t change his spots. And my particular favorite, Don’t move my cheese! Believe me, I’ve seen a lot of cheese-moving over the years.

How to get around the problem? Jared Spool is a big proponent of incremental change. I can highly recommend his article The Death of the Major Relaunch

Having worked on many major corporate rollouts over the years, I can also recommend putting together a serious communication plan. Tell your users what’s happening, when’s it going to happen, and why it’s going to be happen. Tell them these things in several different ways. Tell them these things multiple times.

A final idea is simply to wait. Humans are wonderfully adaptable creatures. That evil abomination that had users storming the corporate gates with torches and pitchforks might well have turned into something that they now can’t live without. Just give it time.

And that’s what I generally tell any team I’m on who is ready to jump off the roof after their relaunch generated less than 100% glowing feedback. Take two weeks or a month or so and look at your feedback again. It’ll probably be just fine. If it’s not, though, that’s when you really need to worry.

Wednesday, August 12, 2015

Affordances are the baby to skeuomorphism's bathwater. (Dan Wineman)

So, before I do anything else, let me define a couple of terms. First, there’s the ghastly “skeuomorphism.” According to Google, it’s simply an “element of a graphical user interface that mimics a physical object.” They offer examples from note-taking apps, such as “yellow legal pads, squared paper, ring binders, etc." 

Skeuomorphs were at one time very popular parts of UIs. In fact, they were rather central in helping early users move from a world they were familiar with (e.g., the office) to one they were not.

Obviously, they can be overdone. Mimicking rich Corinthian leather for an online address book is a great example of a skeuomorphic design element that really doesn’t add anything, and that probably just gets in the way and looks a little cheesy as well. 

Other examples, however, include rather valuable elements, such as radio buttons, buttons with beveled edges, and tabs. Yes, these things mimic the physical environment. But they also help the user an awful lot. That beveled edge? It says, “Click me.” The radio buttons? They say, “Click one of me.” Tabs? They say, “click me for information on the topic listed.”

In this regard, these elements act, not just as skeuomorphs, but as “affordances” as well. And what, pray tell, are those? According to Don Norman, who first applied the term to software, affordances are “the perceived and actual properties of the thing that determine just how the thing could possibly be used.” Knobs on doors are made for turning. Light switches are made for flicking on or flicking off. Buttons are for pushing. They don’t need instructions. They’re not going to be misused.

So, where’s the problem? You can get rid of the wood grain and still make your buttons look clickable, can’t you? I mean, seriously, can’t you?

Well, according to the proponents of “flat design” (another term), you cannot. They’ve taken the horrors of faux leather and wood grain and mixed them in with the useful things, like buttons that look like buttons, field that look like fields, and tabs that look like tabs. And, unfortunately, those proponents are people with names like Microsoft, and Google, and Apple. Sigh … Hopefully, the pendulum will swing back again one of these days.

So, which light switch would you prefer to use?


Monday, July 6, 2015

The users of your product are experts in what they do and how they do it. (Whitney Quesenbury)

Google isn’t exactly helping me here, but I recall a story about a bunch of philosophers sitting around debating how many teeth hen have. Of course, all of them had great arguments about what that number might be, but none of them actually went outside and checked a chicken.

I’m struck sometimes how much some of my meetings over the years have resembled that conclave of philosophers. In general, the syllogism goes something like this:
  1. I’m a user
  2. I have teeth
  3. All users have teeth
Honestly, sometimes I feel that usability engineers are the only ones who want to go find a chicken and pry open its mouth. Yup, we tend to be the empiricists in this matter.

Now, a lot of this comes from simply doing usability tests. It’s amazing what you can learn about - not only the particular subject matter of the test, but all sorts of things about your system, your users, and people and technology in general. Do that a hundred times a year over so many years and, yup, you do get to know those chickens pretty well.

An even more effective method, though, is through field studies. Now, you may know these as “ethnographic studies” or “contextual inquiry,” but all they really involve is simply watching people doing their thing in their own environment. I’m definitely not a purist when it comes to these things, so I typically have no problem just making them a glorified interview. However you do it, you’re sure to get a lot out of it. And no matter who runs 'em.

Oh, by the way … Hens? They don’t have any teeth. Believe me – I just looked.

(not Whitney, by the way)

Tuesday, May 19, 2015

Supposing is good, but finding out is better. (Samuel Clemens)

My life is full of conjecture. Now, some of it is often quite intelligent, and very well informed. That said, it is still someone’s opinion.

How can we get things out of the realm of conjecture? Well, one sure way is to rely solely on the numbers. And that’s where web analytics comes in.

One thing that web analytics sometimes misses, though, is the story behind the numbers. Yes, the users do seem to be dropping like flies on page 3 of the signup process. Why there though? What is happening on that page that makes them want to bail? What’s the story behind that?

Interestingly, there are plenty of companies and teams out there who, though they might be totally numbers-based up to this point, have no problem whatsoever abandoning that approach and conjecturing to their hearts’ content as to what those numbers might mean. And that kind of conjecture is typically no more informed or insightful than straight conjecture without any numbers. In other words, if you don’t watch it, there’s a good chance you’ll get pet peeves, “focus groups of one,” HIPPOs (highest paid person’s opinion), and anecdotes – instead of insightful, informed opinion.

Now, there are also groups out there who supplement their analytics with survey data. They might, for example, mine the survey data to find anything that might point to possible problems on that page 3.

And you can get even closer by providing a “give feedback” link on that page or by throwing in an intercept survey. The latter simply asks the user why they’re bailing. If it’s not pitched like pleading, you should get some pretty decent  feedback from it.

Another method, on the other hand, is to do some usability testing. A usability test always gets at the why. Just go ahead and put your users in the same position as those who were giving you your original analytics, ask them to think aloud, and see what you get. I highly recommend it.

Mark Twain doing some early man-machine studies

Thursday, April 9, 2015

Make everything as simple as possible, but not simpler. (Albert Einstein)

So, what happens when you make it “simpler”? It’s a little counter-intuitive, but you can actually make things more complex. Let me explain …

In general, usability engineers worry about the opposite. The systems and sites we test and evaluate are often the product of design by committee, corporate turf wars, and designing for the exception. They’re typically bloated, speak in another language than the user’s, and are clear and obvious only in the mind of some engineer or developer. 

A team that has started to design this complexity out of their solutions is a team that is in on its way to greatness. Sometimes, however, you actually can go too far. 

For some reason, I often find this to be the case with teams that are heavy on the graphic design side. These folks are often concerned with clutter and detail, striving instead for a clean, crisp interface that meets their aesthetic values. And this makes sense. Just ask yourself … Who is the better artist – Henri Matisse or Hieronymous Bosch? Now, whose interface would you prefer to use?

Graphic designers usually pare down their interfaces by reducing detail. Sometimes, though, that detail serves a real purpose. So, what a graphic designer might see as unnecessary frou-frou really might actually be genuinely meaningful to a user. In fact, that frou-frou might actually be a valuable affordance.

Take the Metro, or flat, school of UI design (please!). Before flat design came along, a button on a screen looked like a button on a physical device. It looked like it had three dimensions. It practically begged you to push it. In flat design, though, all that detail is gone. A button is now just a rectangle with some words in it. As such, there’s nothing that really says, “push me.” Heck, it might just as well say, “here is a field with some information in it,” or “type in me,” or “here’s a box with a word in it for some reason.”

In a review meeting, one of the many eCommerce  directors I’ve worked with over the years once said that something “was so simple it was hard.” Though that does sound a little like something that Yogi Berra might have said, I think she may even have had the drop on Einstein when it comes to getting this important idea across.

 

Can you guess who is who?

Thursday, March 12, 2015

A word is worth a thousand pictures. (Bruce Tognazzini)

I’m assuming he was referring to icons in this case. And the thing that icons have going against them – at least when compared to the average picture – is their almost total lack of detail. Compare, for example, the Sistine Chapel ceiling with the hamburger icon (you know, that thing with three lines in the upper right corner of a lot of your apps). Heck, compare a printer icon with the hamburger icon.

I’ve noticed a real turn in the wrong direction relative to icons lately. To me, they seem to be getting more and more streamlined, causing users to have a harder and harder time interpreting them. They kind of remind me of acronyms in that way. Now, acronyms are an elegant, time-tested way to express a lot of meaning in a very small space. Unless, of course, you don’t know what they mean. And, then, acronyms become totally uninterpretable.

Now, I’m sure this move to icons is due primarily to how our screens have gotten smaller and smaller over time. That said, I am starting to wonder if this whole thing hasn’t taken on a life of its own.

In addition to giving us less space to play with, another thing the move to smaller screens has encouraged is a real reliance on graphic design. I attribute this in turn to the incredible success of Apple, who – of course – owes a lot of their success to their graphic design. Indeed, UI design in this day and age has often struck me as the era of the graphic designer.

One thing I’ve noticed about graphic designers over the years is that they really don’t like words. Now, I’m not all that fond of them either. In fact, I constantly remind the writers I work with that people don’t like to read. I sometimes, think, though, that graphic designers would be more than happy if there weren’t any words on their UIs. 

How else to explain what seem to be an almost visceral reaction against labels on their part? As an example … My company very early on adopted the hamburger icon – long before it had that much currency. Unsurprisingly, users struggled with it. My humble suggestion was to add a label. Boy, did that go over well.

So, here’s the thing with words and pictures ... We need both. If you’ve got an organization that favors one over the other, it’s like driving a two-horse cart with only one of the horses doing the work. Tends to make you run in circles. If nothing else, it sure ain’t very efficient.

Tog, with trademark suspenders

Saturday, February 28, 2015

What people say, what people do, and what they say they do are entirely different things. (Margaret Mead)

I think the perfect example of this is when, at the end of a test, I ask the user how things went. Invariably, they’ll say it went “pretty good.” And they’ll say this no matter whether they aced it, flunked every task I gave them, or – as most commonly happens – fell somewhere in the middle.

I’ll typically also have observers who will hone in on that particular part of the test, citing it as evidence that the users “liked it,” the test went well, and nothing really needs to be changed. This usually only happens for brand-new observers however. I’ve invoked this particular quote so often that I’m pretty sure that anyone who’s sat in on more than a few of my tests has already committed it to memory.

I do also explain, though, that what’s going on has a lot to do with social niceties and – to a lesser degree – the limitations of human memory. I then try to focus them on what actually happened, reiterating that usability tests are task-based.

I also make the point that a task-based test is a real reflection of how people actually use websites. So, yes, Mr. Art Director, when the user says that they liked the colors? They’re really just being nice (or are not sure what else to say).

I’ve also used Dr. Mead’s quote when I need to emphasize the limitations of surveys – including self-reporting, self-selection, and retrospection. And, though I run focus groups myself, I also use the quote to make sure that my team realizes what focus groups are – and are not – good for. Finally, I also use it to make a plug for ethnography, a field that owes a lot to Margaret Mead.

Unfortunately, I cannot use that quote when it comes to web analytics. In fact, I once had a senior exec take a shot at usability testing by firing that quote right back at me. After all, web analytics really are what people do.

After fumbling around a good bit, I was able to make the point that this is one time where the “say” part of the equation is pretty darn important. In a usability test, what the user says while he completes his task lets us know what’s going on in his brain – he’s looking for x when we call it y, he’s looking at the top of the page when we put the button at the bottom, he thinks he’s finished but there’s one more step he needs to take. And analytics might not tell you any of that. And that's why this particular quote is still one of the best ones in my armory.


Unfortunately, this book has nothing to do with usability

Monday, January 5, 2015

People don’t want to buy a quarter-inch drill. They want a quarter-inch hole. (Theodore Levitt)

I am surrounded by techies. And it’s not just the developers I’m talking about. It seems like every one is pretty technical these days – graphic designers with their Photoshop, writers with their content management systems, usability engineers with their eye-trackers, elementary school students with their iPads …

So, here’s the thing about real techies … They really want that quarter-inch drill! Yeah, they might make a quarter-inch hole at some point … But hey, look at this cool drill! It’s made of helical-cut steel, and its gears are heat-treated steel as well. Plus, it’s 510 Watts, and it’s no-load speed goes all the way up to 4,000 RPM! And that’s not to mention the keyed chuck it’s got on it too.

So, does it drill a quarter-inch hole? Well, with a twist bit it does. Heck, it’ll drill a three-quarter-inch hole if you’re using a spade bit.

So, do I want to want to drill a three-quarter-inch hole? What’s a twist bit? How am I supposed to know? Where am I?

I actually have no idea what I just said (except for those last few questions). It’s not that my father – who had a woodshop, as did his father before him – didn’t try to make me understand. I just didn’t care. Sure, the racetracks and train sets they both built were particularly awesome and I couldn’t wait to play with them. It’s just that I wanted – in this particular situation at least – to play. I didn’t care about the thing and how it was made. I just wanted to use it.

Even today, though, we are still often forced to care about how something was made. It’s usually not that we’re going to make it ourselves, but that its poor design forces us to think about its construction. It is never as seamless or intuitively obvious as it claims to be. And that’s what gets between us and our goal, because our goal will always be the train set and not the drill (unless, of course, you’re like all the other males in my family).

Really, this is all just about the old Steve Krug saw, “Don’t make me think!” I don’t really want to think about my banking app, or that travel aggregator site, or “Autosense Technology that drives most screws flush on the first try.” I simply want to make that transfer, or book that room, or just make that quarter-inch hole.

Theodore Levitt (Harvard Business School professor,
longtime editor of Harvard Business Review, and well-known author).