You don't have to please everyone – you just have to please the user. (Brenda Laurel)

 A design team is a team of many masters. More colloquially, pretty much everyone has a dog in the fight.

How it looks, what it says, does it make money, is it legal, will it meet the schedule, how hard will it be to build – these are all things that team members will be looking out for. 

Research is one of the few areas that really sees the project holistically. That said, research does, however, tend to focus on a single person. That person is pretty important though – the user.

Now, it is important to understand where your different team members are coming from. Your company is in business to make money. They also want to make money now rather than later. They’re also very interested in not losing money, especially by getting sued or fined. And whatever everybody else comes up with, somebody's going to actually have to build the darn thing.

When it comes down to it, though, somebody really needs to be there to stand up for the user. And, guess what? That’s you!

No one else is going to do it as well as you. Nobody else is going to spend as much time with these folks. Nobody’s going to get to know them as well. Nobody else is going to care about them as much as you do.

So, don’t worry too much about all the other stuff. They have their advocates, and their place at the table. Your job is to make sure that the user doesn’t get lost in the cracks. It happens! 

What the team doesn’t often realize is that making the user happy can help them reach their own goals. And, conversely, substituting their own goals for user goals can often blow up in their faces. Which reminds me of another great quote:

"If mama ain’t happy, ain’t nobody happy."

Brenda is known mostly as a video game designer, but actually was one of the early pioneers in UX

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.

Users do not care about what is inside the box, as long as the box does what they need done. (Jef Raskin)

Think of your car. If you’re like me, you know that you put the key in the ignition, you start the thing, and you drive somewhere. Oh, sure, there are some other details – turning signals, reverse, headlights, filling the thing up, taking it in to get the oil changed ... But that’s pretty much it.

I can’t remember the last time I opened the hood. Actually, I do!. But it was only because something was wrong. My battery had run out, and I had to get a AAA mechanic to come give it a charge. I opened the hood for him, then peeked inside. Yeah, I could make out a few items – the battery, the air filter (which I never change), maybe the windshield washer fluid, perhaps the radiator cap …

Honestly, though, I’m not a mechanic. I just care that the thing takes me where I want to go. 

Now, here’s the thing. As a user researcher, you may very well work with a bunch of mechanics. This goes without saying when it comes to the developers. I’m always kind of amazed, though, how interested designers, and business owners, and even content types are in technology in general and the inner workings of whatever they happen to be working on in particular.

If you think about it, though, they kind of have to. They really can’t help themselves. If they’re going to produce something, they have to care about the nuts and bolts, they have to get involved in the details.

User researchers, on the other hand, often stand a little apart from that. Our identification is primarily with the user. And the typical user is not the mechanic type, but really just someone who wants to buy a book, transfer some money, stream a video, reserve a plane ticket …

And what that all means when working with your team of “mechanics” is several things. First, there is the advocacy aspect. I find personas really work great here, but simply speaking up and getting teams back on track in general can be really useful. Another important thing to do is to occasionally bring up the idea of mental models – in particular, what they are, that users have them, and that the team’s mental models will tend to be a lot different than the users’. A final idea relates to pushback. I’m always a little amazed when I hear developers say that they can’t do a modal here, or that a table would be too much work there. I often think it’s a knee-jerk reaction, and the team really needs to orient less around what’s difficult for them and more around what’s good for the user.

For, in the end, your user base is going to be a ton more people who really just want to do the online equivalent of getting to work, or going shopping, or picking up the kids from soccer practice. Anything beyond that – or anything that gets in the way of that – may be of interest to a lot fewer users than the team might think.

Jef is mainly known as the guy who created the first Mac

(and, I guess, whatever weird thing that is on his head)

If the standard is lousy, then develop another standard. (Edward Tufte)

Standards are good. Heck, standards are great!

They should not, however, be set in stone. The world changes, people change, technology changes. New data comes in, old theories are disproven, new ones arise. 

That something violated a standard should never be the end of discussion. I’ve run into plenty of instances where a standard might be out of date, or perhaps whoever put the standard together didn’t have all the information, or maybe the standard applies in 90% of the situations but definitely not in this particular one, or even that theory got in the way of actual data.

Indeed, that last point is a particularly important one. For me at least, these issues typically come up, not in some general philosophical discussion, but as the result of actual user research. So, if a test tells me that some standard got in the way of my users and their goals, I think it’s worth pointing out. Now, the reasons for the original standard may indeed still win out, but I definitely think it’s worth bringing up and talking about. And this is especially the case, if it comes up on not just one test, but multiple ones, or – heck! – one right after the other.

Case in point. My company likes to put FAQs on the right rail. In fact, we’ve got a standard for it! 

What I’ve been noticing lately, though, is that users tend to miss them when they’re over there. Those same users also point out that they typically expect to see them at the bottom of the page (and also that they really do value FAQs).

In other words, there already seems to be a standard out there. Perhaps we shouldn’t be reinventing the wheel here, folks. Perhaps we should take a look at that old standard and see if we might want to tweak it a little.

Honestly, what are the point of standards? Now, a lot of designers will point to efficiencies, saving time and effort, not endlessly hashing things over … as well as presenting a nice, clean look to the world. 

For me, though, it’s all about the user. Standards help users take a complex online world and make it a little more predictable. Whether internal (within your site) or external (with all the other sites out there), standards are crucial in making your design adhere to that classic user adage from Steve Krug, “Don’t make me think!” 

Data don’t generate theory – only researchers do that. (Henry Mintzberg)

Data doesn’t speak for itself. In fact, data can be sometimes used like a ventriloquist’s dummy – parroting whatever the ventriloquist wants to say. It takes someone with some real skill to get the data to really talk. And a lot of hard work as well.

Now, data alone will tell you that something did indeed happen. That, though, is kind of like learning that your car won’t go. Well, why won’t it go? What can you do to make it go again?

So, say the completion rate on your account opening process is below 10%. That’s good to know. Doesn’t sound too good either, does it? So, what would actually be your next step here?

Well, one thing would be to dig even further into the data. You might, for example, find out that certain users have less trouble than others. You might also find out that most people drop out on step x. Who knows, there might be even certain times of day when people are more or less successful. Honestly, though, your options will be limited. Web analytics are great for straight-up, high-level numbers. What those actually mean when you get down to it, however, can be another thing altogether.

Another possibility – and a very popular one I might be add – would be conjecture. Heck, that’s all A/B testing is when you really get down it.

A third idea, though, would be to get better data. And that’s why I’m always pressing for qualitative research. Usability tests, ethnography, in-depth interviews, even focus groups can get at some of those thorny why questions. 

In fact, good qualitative data, along with some serious analysis, will start to get at why’s that don’t apply just to the particular project you’re working on, but to multiple projects over time, and in multiple different situations. Throw in a little more explication, maybe a metaphor, and – and hey presto – you’ve got yourself a theory! 

Dang! – my kind of management consultant

“Data” is not the plural of “anecdote.” (Brian Clegg)

As a qualitative researcher, I have to be really careful here. On the one hand, I do not have the data that the web analytics folks and the A/B testing guys and the data scientists have. At the same time, though, I’ve got a lot more than just anecdotes.

First, I do have some numbers. No, they’re not thousands and thousands, or even hundreds and hundreds, but they are more than your own personal data point, or what you heard from a friend or family member or your hair stylist. 

Second, what I have is indeed data. In particular, it is not just opinion. Now, that’s not to say I don’t have respect for your opinion. It might, indeed, be a very well-informed opinion. But it’s still an opinion.

What I can bring to the table is actual behavior, as well as verbalizations of thought processes. And with these coming from real, live users, trying to complete genuine, honest-to-goodness tasks. So, very different from some management types taking a gander at a screen in a conference room and wondering if the “green pops enough” or thinking that “the content doesn’t really speak to me.”

Third, the data that I have tends to be very rich. And that is, indeed, why I feel I don’t necessarily need hundreds and hundreds of data points. 

Now, if what I was trying to get at was more marketing related (How many people would be interested in this product? How much are they willing to pay? Which of these ads are people more likely to click on?), I’d be all about the numbers. What I’m dealing with, though, is whether something’s going to fly or not. 

And you don’t need a lot of numbers for that. You simply don’t need a ton of people to tell you that they have no clue what to put in field X, or that that description makes no sense, or that the CTA is impossible to find – when they actually show and tell you that themselves. If you didn’t have those rich verbalizations though, you might never figure out why you’re getting such poor data, or why no seems to get beyond screen X, or why people seem to be signing up for the wrong product.

Sure, you can speculate on why these things are happening and what the numbers might actually mean. Usability testing, though, will get you the real answers, giving you that very important why along with the how much.

Brian Clegg is an English writer specializing in explaining abstruse science to lay folks

Design Thinking is the designer's version of Agile. It’s becoming cult like. (Bill Killam)

Robert Jay Lifton is a psychologist famous for his seminal work on brainwashing and cults. He’s known, in particular, for an eight-point definition of what actually constitutes a cult. One of those points relates to language:

Loading the Language – The group interprets or uses words and phrases in new ways so that often the outside world does not understand.

When I was initially exposed to Agile, this was one of the first things that struck me. Why call a meeting a “meeting,” when you can call it a “ceremony”? Why call a schedule a “schedule,” when you can call it a “timebox”? Why call a chart a “chart,” when you can call it an “information radiator”?

I noticed something similar with Design Thinking – “ideation,” “MVP,” “bodystorming,” “divergence/convergence,” “culture probes,” “How might we?” … 

Now, every new way of thinking really does need some new terms. Sometimes, though, these terms serve other purposes entirely. They can, for example, separate an in-crowd from everyone else. They might also be used to enforce a certain way of thinking (words can and do shape thoughts) or even stop thinking entirely.

Finally, they can also take existing ideas and make them sound fresh. You know, old wine in new bottles.

And Design Thinking is a little different from Agile in that last regard. Agile really does involve some new ideas and thinking – especially when contrasted with waterfall. Design Thinking, on the other hand, sounds a lot like good, old-fashioned user-centered design, at least to me. Yeah, there are a few different emphases – getting the whole team involved, that divergence/convergence thing – but really it should sound pretty familiar to anyone who’s been in the biz more than just overnight.

It’s actually a fairly common practice in business – take somebody else’s ideas, rebrand it, own it, market it, and cash in. If you get people to get so excited about it that it approaches cult status, well, even better!

Bill is president of User-Centered Design, an adjunct professor at George Mason, and has been in the biz for 30+ years

If I had one hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about the solution. (Albert Einstein)

And that’s because coming up with a solution will only take 5 minutes once you fully understand the problem. Believe me, I run into it all the time.

Take usability reports, for example. For these, it’s almost always the case that I’ve actually spent a ton of time with each issue. I’ve listened to hours of tapes, I’ve sifted through tons of notes, I’ve rearranged quotes and behaviors in multiple buckets, I’ve struggled with ways to understand what exactly what was going on, I've struggled to get some persepective from a higher level … The reports do indeed write themselves.

And that’s also why I almost always include suggestions in my reports. I figure if I’ve spent that much time thinking about something, I’ve probably got some good ideas already on how it might be fixed. And seeing that I’ve been doing this for 30+ years, this is probably not the first time I’ve run across that issue either.

I do get pushback sometimes though. Indeed, designers tend to be a bit touchy when you “tell them what to do.” Now, I can definitely understand that. Personally, I hate it when clients come to me with a demand for one method over another without first talking about what they actually want feedback on. 

So, what I typically do is call it a “suggestion” and say that it just occurred naturally as I was writing up the report and that you can take it or leave it. I mean, it’s all supposed to be a collaborative effort anyway, right? Heck, I really don’t care if you claim the solution as your own. All I really want is that the issue is addressed somehow, or even that the team has thought about addressing the issue but have good reasons (business, standards, whatever) for not doing so. 

Interestingly, I also get similar feedback from the occasional user researcher. They typically say something about being above the fray, staying unbiased, focusing on the issues, etc. Personally, I think it’s something of a cop-out.

I mean, honestly … You’ve spent hours on this stuff. You’ve probably even seen it before on other tests. Heck, you might even have a design background yourself. Why not throw something out there – to at least get the conversation started and stake out a place at the table? 

Einstein also said:

• "Make everything as simple as possible, but not simpler."
• "If you can’t explain it simply, you don’t understand it well enough."
• "Not everything that counts can be counted, and not everything that can be counted counts."

I like it simple when I’m doing complicated things. (One of my users)

I had always heard this one a little differently – in particular, “Make simple things simple and complex things possible.” I think this user is really on to something though.

This particular user was talking about a complex field – securities trading. I forget what exactly he was trying to do, but there are plenty of crazy trades investors can make out there. Take options, for example. Would you believe you can do strangles, condors, iron butterflies, naked spreads …?  Indeed, you can – I am not making this stuff up!

Now, what I think he was getting at – i.e., what he was trying to tell me, a seasoned user researcher – was that he was trying to combine two bits of cognitive load. First was the particular trade he was trying to do. Second was trying to translate that into something on the particular UI he was staring at. Wow, that’s a lot!

Now, “making simple things simple and complex things possible” would really mean just providing him with the functionality to make that particular trade possible. Is it really okay to just leave it at that though? Isn’t there something else we could do for him?

Now, I do realize that that original quote was really directed at not designing for the exception. But I do like to go one step further in cases like these. And that’s to suggest a wizard.

So, instead of just saying, “Have at it,” what I like to do is engage the user in a bit of conversation. Before I can do that, though, I have to get a real feel of what that conversation’s really all about and all the places where it might lead.

And that’s why I always suggest some pretty heavy-duty task analysis before undertaking anything even remotely like this. What are the actual steps? What are the different options the user has? What is their ultimate goal? Doing that allows you to lay out the conversation in a way so that it all makes sense to the user and actually appears manageable to them. 

And that goes whether you’re really creating a wizard, or are instead doing a chatbot, a dynamic form, or simply laying out a form or set of screens in a logical way …  or, really, doing anything where the user may be struggling with the task already – let alone trying to make sense of your UI. Indeed, don’t think of it as creating x, y, or z, but as reducing cognitive load, maybe even helping fashion a mental model.

In so many words … Don’t just throw it at them, like a maze! Go out of your way to help them make their way through it – like the incredible wizard that you are!

Just in case you thought I was making that stuff up

Designers shooting for usable is like a chef shooting for edible. (Aarron Walter)

In general, I agree with this and totally understand where this guy is going with it. Personally, though, it kind of rubbed me the wrong way the first time I heard it. 

First, it sounded sort of like things should revolve around the designer, and not the user. Maybe it’s just me, but shouldn’t the chef be super-focused on providing an excellent meal for his patrons? Similarly, shouldn’t designers be shooting for an excellent experience for their users?

Yes, there are celebrity chefs out there who seem to reverse the two sides of the equation. I don’t know about you, but the places those guys run are not where I really want to eat every night. First of all, I can’t afford it. Second, I don’t always have the time for a 3-hour, 8-course meal. And, sometimes, I just hate to get dressed up and go out. I mean once in awhile is fine, but not all the time.

Honestly, are all designers really chefs? Aren’t there plenty of roles out there that really call more for cooks? I may simply want to buy a book, or pay a bill, or look something up, or reserve a rental car. A burger and fries would be the gastronomic equivalent for this. Really, I don’t expect Thomas Keller cooking tableside if I have a half hour at my desk between meetings for lunch.

Maybe the quote simply begs the question … What should the designer be shooting for? If it’s not usability, what is it? 

Well, what I often hear is delight, or creativity, or innovation, or passion ... Which is all well and good. 

Most places I’ve worked at, though, are more like greasy spoons, with lines around the corner, and the fryer has just broken down, and we’re down two waitresses … Pretty much not El Bulli. Honestly, though, between the deadlines and the politics and the HIPPOs (highest paid person’s opinion) and the marketeers and all the rest of it, if a designer can provide a usable experience, I say toques off to them! 

I really think that’s only going to happen, though, if the user is first and foremost in the designer’s mind. Believe me, I have seen plenty of instances where the designer thought they were creating molecular gastronomy, but all they were really doing was serving up some foul stew that no user could possibly figure out or even want to engage with.

Sure, shoot for those Michelin stars, designer/chefs! At the same time, though, don’t forget to keep slinging out the hash and keeping those lights on.

Aarron is a VP at InVision, started UX at MailChimp & has written a couple of books

(Not too surprisingly, though, he started out with a BFA and MFA in painting)

If you're not falling, you're not learning. (anonymous figure skating coach)

So, this one came from that well-known source of UX knowledge boredpanda.com. It’s from people responding to a young girl who had failed at baking a cake and therefore decided to give up baking FOREVER (“9-Year-Old Thinks She’ll Never Be A Baker Now Since She Failed Once But The Internet Posts Many Examples Of Their Failures,” if you want to look it up). She got all sorts of wonderful responses, from amateurs and professionals alike. I just so happened to like this particular one the best.

Now, is this just an age thing? You’d think we’d eventually get over it, that maturity would give us a little more perspective ... and resilience. Right?

But, then again, maybe not. I feel like I run into it all the time. Indeed, I’ve been getting a lot of resistance to usability testing over the past few years. So, what gives? Is it just fragile egos, Millennials, digital creatives, Design Thinking, "kids these days"?

I have a theory ... It combines a couple of things, but really focuses on how design seems to have taken over the UX space lately.

So, for example, if you came up as a graphic designer, you may have honestly never really gotten decent, objective feedback before. Sure, your instructors had something to say, as your boss undoubtedly does now. You also probably engaged in crits, and may be doing those now as well. And, in the real world, you’ve always got your client, right?  In fact, making the customer happy may very well be your main goal right now.

But, really, who is that customer? If your immediate answer is the person paying the bills (whether your company or a client), you’re right, but you may also be missing something very important. Yup, UX is a little different in that way.

Now, yes, you definitely need to make the business, your boss, and the client happy. But the main person for UX is actually someone very different – the user of whatever you’re designing. I mean, if they’re not happy, your design will have failed. But, then again, how would you ever know? How is this different than releasing a brochure on the world, or plastering posters up everywhere?

Well, there are a couple of answers to this question. The hard and fast one is clicks, whether straight up or using A/B testing.

There’s also a softer one too. And that method also can tell you something that the hard and fast stuff cannot – why you’re design is failing (or succeeding). With usability testing, your users will tell you - with their actual words, but also with the things they do.

Ideally, a successful UX project will start with approval at the peer, manager, and business/client level. That, then, needs to be followed up with usability testing with actual users. Finally, upon release, don't forget to monitor the heck out of clicks; web analytics; and actual signups, purchases, or whatever bottom-line result your company/client is ultimately interested in. 

It’s kind of like baking a cake. Leaving out any of the steps is going to result in some kind of mess. Following them all is going to result in something tasty for all.

Good advice for here too

You can’t stop people from putting beans up their nose. (Jared Spool)

There’s a long story behind this one, but what it really boils down to is something a consultant that Jared knew once said about how clients might (or might not) implement the findings of usability research. My guess is that, in turn, probably came from someone the consultant knew who was a doctor (and mostly likely a pediatrician). Do you see where I’m going here?

Yup, I think everyone of us has probably stuck something up our nose (or in our ear) as a young child. And, invariably, that would lead to a trip to the doctor, if not the emergency room.

Now, here’s the thing … Whereas doing something like that is par for the course when you’re a kid, it’s not so good when you do that as an adult.

Of course, that’s not something we’ve all haven’t done before either. I guess it’s just human nature. Tell people they’re not supposed to do something, give ‘em great reasons why not … and just watch as they do it anyway, almost as if they couldn’t help themselves.

What does this all have to do with consulting? Well, a ton, actually. In fact, I don’t know what it is, but it happens all the time. Maybe clients want to show they still have some independence. Maybe they were surprised that what the consultant came up with was something other than just accolades. Maybe they just hired the consultant for optics. Maybe they just don’t get this “user thing.”

And this isn’t just a consulting thing either. I’ve been on staff most of my career, and still see it all the time. 

There is one benefit to being on staff though. And that means that I get to say something along the lines of, “Remember what happened the last time when you put a bean up your nose?” You know, the good ol' I-told-you-so.

Does that always work? Unfortunately, and I hate to admit this, but, in a word, um, er … no. So, just remember, like Jared says ...

More from Jared:

• "Users don’t hate change. They hate our design choices."

There are two kinds of people in the world, those who believe there are two kinds of people in the world and those who don't. (Robert Benchley)

I’ve been interested in personality theory since I was in high school. My first love was Myers-Briggs. I still think it has its uses, but I also know it has absolutely no cred in the rarified world of research that I currently operate in. So, it’s been pretty much the Big Five ever since.

That said, I’ll pick up and read anything I can get my hands on if it deals however broadly with personality theory. Now, that does involve a fair amount of stuff that is rather pop psych, but I still find bits and pieces of it pretty useful. Heck, I got the quote for this post off my latest book (the Four Tendencies, by Gretchen Ruben, if you’re interested).

What does this have to do with UX research? Well, a lot, actually. It’s basically what’s behind personas. 

The basic idea here is that there are only so many types of users in the world. Now, this doesn’t mean that you divide your user base into INTJs and ESFPs, or see how many are Conscientious or Agreeable.  

Personas typically don’t care who their users are in essence. It’s much more who they are in certain situations – buying a house, investing, planning a vacation, as a medical patient …

The whole idea is that it’s a lot easier to handle a small universe of people by coming up with some kind of typology. And that, in turn, helps you not design something by default – i.e., for everybody, or for no one in particular, or for yourself …

Done properly, personas are perfect for truly reflecting the actual audience and allowing a design or product team to come up with something that actually is of use to someone and can, thus, be genuinely successful in the marketplace. And I think that’s a very reasonable way to go about it.

So, I guess that makes me the second type of person. Note, though, that that really means I’m someplace in the middle. I’m not throwing out personality typing altogether, nor am I being overly reductionist. Hmm, I wonder what kind of personality type that would make me?  I guess "it depends."

Robert Benchley represents another of my early interests – classic humor writing
(and actually wrote about the foibles of technology once – in his piece “The Railroad Problem”)

You’ll never have all the information you need to make a decision. If you did, it would be a foregone conclusion, not a decision. (David Mahoney)

As a usability engineer, I enjoy being popular. I like being in demand. I can’t get enough of it when teams want to engage me. It makes me feel validated. It makes me feel all warm and fuzzy.

At the same time, though, there is a certain role that I’m sometimes put in that I really don’t enjoy quite as much. And that’s when the team I support doesn’t want to do the dirty work of making decisions, but instead punts the ball to me.

Now, typically, I’m actually just fine with that role. The team can’t decide on which version of some widget to use? No problem. I’ll run a comparative test and get you some good feedback.

The team does need to be aware, though, that what I often find in these tests is that there is no clear favorite. In fact, the most common result is that each design has its pluses and minuses. So, it may not be exactly what you were looking for going in, but it’s still pretty darn valuable stuff.

Sometimes, though, I run across a situation where the team really is doing some major waffling. You can typically tell when they, for example, want to test 10 different designs, with the differences between them amounting to things like underlining, or capitalization, or which shade of green to use.

I exaggerate, of course. But I do believe that, when a team does something like that, they may be confusing usability testing with A/B testing or with a marketing survey. So, what I try to get them to do is to sit down, make some decisions, and narrow things down for me just a little bit.

Now, it’s not just a matter of making my life easier. I also try to get across the idea that they’re really not gaining anything from all that either. So, what I do is try to focus them on a handful of designs that really emphasize the things that are genuinely different, allowing us to focus on those, get some great feedback, and make the testing worthwhile for both of us.

Does that always make me popular? Well, no. But it typically is a pretty easy discussion to have, and the team’s almost always totally happy with the results.

Not a usability type, Mahoney was a very successful business exec 

and the author of Confessions of a Street-Smart Manager