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, 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


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. 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?