Monday, January 11, 2021

The arguments are so vicious because the stakes are so low. (Henry Kissinger)

For some reason or other, this always seems to raise its ugly head on internal projects. My experience with these is that everyone tends to think they’re an expert, there’s no natural chain of command, the people who tend to volunteer are often suck-ups and preeners … Add in the fact that no one’s going to pay attention to the end results anyway, and you’re all set!

Not too surprisingly, my first experience with this goes all the way back to grad school (the original quote was about academia, by the way). Now, that stuff really did amaze me. In fact, it’s probably why I don’t have a PhD at the end of my name, to be honest.

One of the great attractions about industry was that I didn’t have to worry too much about all that. Either the stakes were pretty high, or people simply weren’t that into fretting and drama, and just wanted to get something decent out the door.

At the same time, I happened to be very lucky in that I always seemed to find myself in situations where I was encouraged to sample the academic side of things. Conferences, papers, speaking engagements, guest lectures, organizational work were all encouraged. It was the best of both worlds. 

I also found that I was most attracted to the academic stuff that was only of the most practical nature. So, UXPA over CHI, the Journal of Usability Studies versus Proceedings of the IEEE, Jakob Nielsen before Don Norman …

Sometimes, though, even industry can turn a bit petty. Luckily, though, it seems to be mostly in those unusual situations, where the normal guardrails are not always in place. And in those situations, it’s always helpful to remind myself that it may not matter all that much, and that I can always save my energy for something that does.




Tuesday, January 5, 2021

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 scar 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)


Friday, December 18, 2020

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, by getting sued or fined. 

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


Monday, December 7, 2020

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. We’re also, though, inevitably going to get some comments about the soup course, or the entrée, or what the heck happened to the dessert? … 

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 dessert? If the entrée was cold, wouldn’t you just go warm it up?

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



Tuesday, October 6, 2020

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


Friday, September 18, 2020

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 keep your eye on the road.

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. It 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 or monitoring analytics, VOC, 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, 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.