Experience: that most brutal of teachers. But you learn, my God, do you learn. (C. S. Lewis)

I love being wrong. I just adore making mistakes. Especially if I can arrange to do that in front of a large crowd or a bunch of people that I look up to.

Yeah, right. Just like every other specimen of Homo sapiens out there, this is not exactly my favorite thing. There’s nothing in the world that will transform me into a petulant, defensive five-year-old quicker.

Now, this sort of thing will also certainly get my attention. But, heck, getting hit over the head with a hammer would do something very similar. That said, I can be pretty thick at times. So, probably not a bad idea, all things considered. 

And these are also the times when things really do sink in. And that’s not just because of the huge dent on the top of my head either. Now, they might take a while to totally sink in – and a lot of sensitive feelings to get over as well. But it really is pretty effective.

Now, I tend to be really terrible at it, but when experience is pointing something painful out to me, I do try to calm down, shut up, and take it in. Once again, I’m not always successful, and it certainly doesn’t happen instantaneously, but I’ll usually get there eventually.

And for you designers and developers and project team members out there, do know that user researchers get feedback too. Yup, we’re not just dumping on you.  ;^)

You’ll be happy to know that user researchers dump on each other as well – if they’re part of a well-functioning group, that is. We’ll also go directly to our clients and have them dump on us – once again, if we’re managed well. 

And, finally, know that experiential feedback is not just something for newbies. Now, the beginning of your career is ripe for this sort of thing, but do realize that the rest of your career will be far from immune. New tools, new methods, new users, new domains, new teams, new companies, new technology – all provide plenty of opportunities for experiential learning.

Learning is good. Learning can, however, be painful sometimes. Just hang in there though – you’ll learn lots.

Hint:  He was against it (technology, that is)

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.