We must all face the choice between what is right and what is easy. (Albus Dumbledore)

This can mean oh-so-many things when it comes to UX, but let me focus on something that has come up on a couple of projects recently. It also seems to fit in well with what I see as a major limitation of the Agile methodology. Let me explain …

At least where I’ve been exposed to it, Agile seems very incremental – lots of little stuff. Now, that’s not a bad approach. It’s a lot easier to eat an elephant if you carve it up and consume it bit by bit.

One thing I’ve noticed in usability-testing these little bits, though, is that the user’s experience is almost always more along the lines of a five-course dinner, rather than the tiny little appetizer that we were addressing (and hoping they would focus on in the test).

You see, it’s really hard to give a user a task that focuses solely on a little, tiny bit of a much bigger process. Usually, you have to test that particular bit in a larger, overall context. Otherwise, the task simply isn’t going to make sense to them.

Say I want to get some feedback on a little widget that’s part of a trade ticket, what you fill out to buy or sell a stock (I do a lot of brokerage work). I can’t just have the user fiddle with that widget. For their interaction with the widget to truly make sense, the task is going to have to be something larger, something that they would really relate to and want to do – something, say, along the lines of buying a particular stock.

Now, that will allow us to really learn how tasty (or not) that particular appetizer was. But a lot of that will depend on the rest of the meal.  What, for example, if the appetizer was served last, or was twice as big as the entree, or simply did not go with anything else?  And don't forget we’re also going to be getting some very valuable comments about the soup course, or the salad, or what the heck happened to that entree? 

So, how do you address those other issues? In Agile theory, these would go into a backlog. (In practice, I’ve also seen them simply ignored, or go in a backlog that itself gets ignored). Boy, that almost seems a little too easy to me.

Why not simply address them here and now? Now, that would be harder. But I also think it’s doing what’s right.

Think about it if you were running a restaurant. Wouldn’t you just bring out the entree? If it entrée was cold, wouldn’t you just go warm it up? I'm not sure any customer would be happy with having it put in a backlog and fixed later, at the restaurant's discretion.

For the user – and for me, as a user researcher – the user experience is pretty holistic. Holistic, though, is probably always going to be a little (okay, a lot) harder. Now, does Agile really reflect that?

People ignore design that ignores people. (Frank Chimero)

 And, to me, that means designing without data. Honestly, why are designers sometimes so enamored of that? 

I just had an example crop up at work. One of the designers there was tasked with the simple task of adding contextual help to some tables of financial transactions. While there, though, he couldn’t help but tweak the table a little.

In particular, he added a caret to a table row to show that the row would open up and show more data. Previously, we had signaled that by simply making the description of the transaction a link.

He had a good argument. His thinking was that the link wasn’t enough, and that users wouldn’t get it. Unfortunately, he used himself as data point number one, imagining that he himself might have trouble. It was then an easy hop, skip, and a jump to speaking for all users.

Luckily, I was there to point out that I’ve tested tables like that 100 times, and nobody had any trouble with it. Someone else pointed out that the caret would be non-standard with the rest of the site, where tables that open up are all caret-free. 

Honestly, though, it really wasn’t that a big deal. It was just a little extra “chart junk,” as Edward Tufte might call it. It’s certainly not going to break the system.

The only reason I brought it up was that we actually did have some data on that. And I certainly wasn't going to pass up an opportunity to remind designers not to design for themselves. 

I’m using it as an example here simply because it was very current and, so, super top of mind. I also think the fact that it had a happy ending made me feel especially good about the whole experience. Believe me, I’ve seen redos that were a lot worse. In fact, it made me feel good that this was so minor, and that it wasn’t a case of just ignoring users outright (which I’ve seen as well).

My guess it was just too darn tempting for my designer in this case. Heck, why not leave the world a better place, right? Turns out the world was just fine as it was. So, no harm, no foul.

Frank is a designer and the author of The Shape of Design

Make all visual distinctions as subtle as possible, but still clear and effective. (Edward Tufte)

 In my experience, unfortunately, I’ve seen designers mostly follow the first part of this, and not the second. Which does makes sense. I mean, what do you think is going to be taught in design school? 

In fact, I’d say it may be the thing that probably distinguishes designers most from non-designers. For the latter, art and design meant basically completing filling the page with many figures and colors, then bringing it home for mom to put on the refrigerator. For designers, though, I believe there comes – at some point – an appreciation of the whole, of white space, of not trying to just fill the hole, of letting things speak for themselves, of having a little go a long way, of taking things away rather than just keep adding them in.

I often wonder, though, how well that really translates from design school to industry. Now, if you happen to get lucky and go work for some place like OXO, or an agency, or some cool boutique shop in Manhattan or LA, you’re probably golden. But what if you end up at a bank, or an insurance company, or retail, or telecom, or government, or the military? 

My guess, in that situation, is that your definition of what’s clear and effective might be different than your company and the people you have to work with, at least at first. So, what you see as their adding clutter might actually not be that bad – and might help the user actually understand what it is they’re looking at (you know, affordances).

Take, for example, how drop-downs are signaled. The classic design is a box with an upside-down, filled-in black triangle, at the end of a boxed-in field. So, how can we make that more subtle? Is there something we can take away here? I think the box’s a pretty good candidate. And you probably don’t need to have that triangle filled in. Could you make it just a simple v though? How light can you make the lines? And how large does whatever it’s going to be have to be anyway?

There are plenty of other examples out there. I could go on and on.

Probably the worst I’ve seen, though, is being so subtle that there’s no actual design element whatsoever! Believe me, I see it everywhere these days – menus, scroll bars, table column controls, and other elements that don’t appear until you put your cursor over them. 

I think even Tufte would have to draw the line there.

Designers are not users. Users are not designers. (Jakob Nielsen)

I’d be curious to know when this one came out. I think I remember a previous incarnation that said the same thing, but about developers.

And all that’s telling me three things. First, I’ve been in this business for way too long.

Second, designers are definitely the ones in charge these days. Now, they are a lot better than developers when it comes to UI, or UX, or just plain “getting” users. Designers do, though, need to realize that they’re not perfect, and there’s still a lot to learn.

Third, it seems like whoever’s in the driver’s seat is going to have some serious trouble with perspective. It is so easy to design for yourself, or to assume certain things about your users, or to just get lost in the details of the project itself and forget about the real, actual users themselves.

Luckily, the solution is the same as it was 30 years ago (yup, that’s how long I’ve been doing this). First, I would recommend a little humility. Yes, it’s great to be in the driver’s seat, but you still do have to watch for those bumps and potholes and other drivers.

Second, I would recommend being fully user-driven. There are two basic ways of ensuring that happens – one before design happens, and one during design. 

For the former, there simply needs to be some research into who you are designing for – what makes them tick, what do they want, what do they need, how do they operate – who are they? Now, you can do this in one of two ways, quantitative or qualitative. Quantitative is the more popular, and involves surveys, VOC, web analytics, and so forth. It gives you the numbers, but the data tends to be a little on the thin side (i.e., it doesn't give you the whole picture). That, however, can be supplemented by qualitative – interviews, ethnography, focus groups – all resulting in something genuinely useful in the design process, like a persona. Qualitative gives you smaller numbers, but much richer data. In the end, qualitative can have as much impact - if not more - than than quantitative.

For the latter, nothing beats good old-fashioned user feedback. These days, that simply means getting it out there in production and then doing A/B testing, monitoring analytics and VOC, fielding surveys, etc. Once again, though, your data may be a little thin. Plus, you can’t get any feedback until the thing’s actually live.

You can use usability testing, though, to get feedback at any point in the design process – pieces of paper, an Invision prototype, HTML, a test system. Further, the feedback will be very rich. The users will tell you which direction to head, what’s working, what’s not, what needs to be explored further, what needs to be tweaked, what needs to be totally redone. And, most importantly, you’ll get the why’s behind it all. And that means you can feel pretty assured that you may have actually solved the problem and made the user experience better.

No matter who’s in charge when it comes to UX, if you want to stay in charge, never get too far away from real, actual users.

The next big thing is the one that makes the last big thing usable. (Blake Ross)

It does work that way sometimes.

So, it’s one thing to be first to market. It’s another thing, though, to make it to market with something that people like, and can use, and that simply works. And, sometimes, it just so happens that the latter displace the former, like the mammals displaced the dinosaurs.

Perhaps you’ve heard of the Newton, or Windows Vista, or Facebook Home. Friendster? Google+? How about Macintosh TV? Microsoft Bob? I actually have a whole book of ‘em (Worst Ideas Ever, Klein and Tomaszewski).

So, was all that technology simply ahead of its time? Perhaps. Or might it have been missing a very important part of the puzzle? More likely.

I have a perfect example from my own discipline. Kind of hard to believe, but there was once a time when video of a usability test involved a camcorder and VHS tapes.

One of the first companies to integrate tapes into a software system was called Yoohoo (names changed to protect the guilty). The company I was working for at the time couldn’t wait to write them a check. I had some serious doubts, but there were a fair amount of techy types in the group, and everyone assumed they would figure it all out.

After a year or so of major struggles, though, the software mostly sat there – a good source for viewing the user from back in the observation room, but that’s about it. Turns out you basically had to hire someone from the company full-time if you actually wanted to be able to use this thing.

After a few years, something else came along – we’ll call it Morpheus – that blew Yoohoo out of the water. It pretty much did everything that Yoohoo did, but with the added benefit that everyone on the team could understand and use it. I was as impatient to write a check for Morpheus (it was a lot cheaper too) as everyone else had been to do so for Yoohoo.

Needless to say, that check did not get written right away. There was a little sunk cost, and bruised egos, and stuff like that to get over first. We did, though, eventually make the move. And everyone pretty much lived happily ever after.

Of a dancing dog, Samuel Johnson once wrote that “It is not done well; but you are surprised to find it done at all.” And that’s what you get with some first-to-market technology. Now, sometimes it works, and sometimes it doesn’t. Just make sure you’re not blinded by that dancing dog.

Not that that’s going to happen here, I would imagine: 

Sorry about that. BTW, Blake is one of the co-founders of Mozilla.

In my opinion, no single design is apt to be optimal for everyone. (Don Norman)

And that’s why we have personas. Now, without them, there are several defaults. Don touches on one of these – trying to be all things to all people. Other possibilities are designing for yourself or designing something so bland and noncommittal that you’re really not designing for anyone at all.

So, how to avoid all that? Right off the bat, you know that you can’t create a persona for every possible user or customer out there. You do have to narrow them down. 

But how many do you need? Personally, I generally let the data speak for itself. Now, I can guarantee that there will definitely be more than one. Chances are, though, that there won’t be more than 5 or 6. And, even then, you can typically divide your personas into primary ones and secondary ones. (Just make sure you focus on those primaries!)

The important thing is that you are designing for someone specific. But, if the personas have been designed properly – with believable stories, and real names, and realistic photos – it will be hard for the team to not do so. It's just the way the human mind works.

Once you have your personas, you now have several ways to do deal with them. You might, for example, come up with multiple designs. Or, you might want to design for one of your primary users, but make sure that other personas can still get to what they need (just don’t throw it in the primary users' faces). You might have levels – like in video games. Finally, you might want to simply make a business decision and focus on your primary personas (probably your main source of revenue anyway) and let the secondary ones go.

That said, I have also seen designs that do cover multiple audiences quite well. I’m thinking, in particular, of long sales pages, where the user simply keeps scrolling until they're sold. For the detailed-oriented type, they’ll be scrolling through the whole thing. For the shoot-from-the-hip type, it’s a few bullet points and a CTA. For the socially-oriented, reviews and testimonials are often what they’re looking for. For the hard-sell, show-me-the-money types, it’s usually showing your low fees, or your high interest rate, or how your price compares to other vendors.

Do note, though, that this is definitely the exception. The rule is exactly what Don says.

A bad website is like a grumpy salesperson. (Jakob Nielsen)

One favorite metaphor I like to use with design teams is that of simple, face-to-face, human interaction. Since I’ve worked in banking most of my career, that typically involves talking about bank branches. You know, where you wait in line for a teller, then go up to the counter, hand material back and forth, talk about the weather, then get a receipt and a lollypop and leave? 

What I like to do in particular is contrast the interaction that the user is having online with what the user might experience in a branch. Would a teller really be that abrupt? Wouldn’t they normally be a little bit more friendly in this particular situation? Would a teller really just stand there looking at you after you did x? Wouldn’t they say something to acknowledge you? Wouldn’t a teller give you a little more information than just that? Wouldn’t they explain some of this a little better? Wouldn’t the two of you have a fairly strong, agreed-upon recognition of what constitutes the beginning and the end of the transaction? Why did you leave the user just kind of standing there?

Now, I’m not saying go all out on anthropomorphization. I’m just pointing out that users already have a mental model in their head (and do tend to anthropomorphize computers anyway), and that keeping that model in mind can definitely help things run a little more smoothly.

Needless to say, these kind of IRL metaphors apply to any kind of online interaction – shopping, asking questions, searching for information, scheduling things … So, if you’re in the business of UX – IA, ID, graphic designer, content – this is going to apply to you too.

One thing I’ve found particularly useful in these situations is something I learned in linguistics, Grice’s maxims. These are basically the linguistic rules for meaningful conversation to happen:

• Quantity – where one tries to be as informative as one possibly can, and gives as much information as is needed, and no more.
• Quality – where one tries to be truthful, and does not give information that is false or that is not supported by evidence.
• Relation – where one tries to be relevant, and says things that are pertinent to the discussion.
• Manner – when one tries to be as clear, as brief, and as orderly as one can in what one says, and where one avoids obscurity and ambiguity.

Follow these in your designs, and you’ll have that human-interaction template down pat!

One final thing … I've only ever seen this quote all by itself. I'm wondering if it was originally combined with another of his famous maxims:

"The web is the ultimate customer-empowering environment. He or she who clicks the mouse gets to decide everything. It is so easy to go elsewhere; all the competitors in the world are but a mouse click away."

In other words, it’s lot easier to go to another site than go to another brick-and-mortar store. The Internet is not your local mall.