Making usability problems real for project stakeholders

Sometimes the old techniques work best.

On a recent project, one of our lead UX analysts ran into a situation where some long-standing usability issues were impacting the success of a soon-to-be-released new feature.

Everyone knew about these UX problems. They were discovered in past Betas and user testing sessions and had also been reported by customers via feature requests and Support calls. But when it came time to decide on what’s in vs. what’s out for a release, they never seemed to make the cut. In fact, the lead UX analyst had just lobbied for some of these very issues to be included in the current release – but no luck!

So now that they were staring her in the face again she knew she needed to do something different to make the problems resonate with the project manager and project stakeholders. She crafted a usability test and invited them to attend. While some of her fellow sprint team members made it to the sessions (always a good thing) the product manager and stakeholders did not.

That’s okay. She had recorded the sessions. And when it came time to present the findings she showed them sample videos from the tests to really accentuate the difficulties that the users were having.

In the first clip, she demonstrated an issue with selecting multiple rows in a list. If you click anywhere outside of the tiny little checkbox icons you lose all your previous selections. (ARGH!) It sounds fairly innocuous in the grand scheme of building a feature – the user can just try again, right? But to the user, this seemed pretty ridiculous. He had to laugh as he tried over and over to make it work and kept missing the mark.

It was clearly a bad UX.

CPL-usability-grab05
Usability test clip 1: User selecting multiple rows – but watch out! Don’t click too far away from that checkbox!

 

CPL-usability-grab04
Usability testing clip 2: Users reaction as he loses his row selections by clicking a pixel or two outside of the checkbox. What is going on!!!???

 

In the second clip she showed a user searching for a custom list he had just created. The user wondered out loud, “Did I forget to click OK?” Apparently he thought he may have forgotten to save the list. He moved his mouse pointer to the area where the list was supposed to be on the left side of the screen. “I would expect to see something here” he said. But he didn’t think to click on the tiny gray chevron. It didn’t look clickable anyways. It looked disabled. But that’s where the list was hidden – behind the collapsed tree node.

Another bad UX.

 

CPL-usability-grab02
Usability testing clip 3: User searching the screen for the new list he just created. (It’s hidden in a collapsed tree node.) Note the frown on his face as he scans the GUI.

 

I was in the room when these clips were shown to stakeholders. To the credit of the lead UX analyst, she wove them perfectly into her overall testing summary. The response was just what she had hoped for: Seeing the users made the problems real for project stakeholders and now they wanted to do something about it.

And that’s the old trick that worked so well to blow the dust off of those “old news” usability issues and make them new again. All it took was getting some fresh evidence and rolling the tape.

Remember this the next time you are trying to get a point across with your stakeholder / product manager audience: Seeing is believing.

‘The Questions’

So I found myself in one of those cycles not too long ago where some big projects were coming to an end. Woo-hoo! We’re ready to ship something! The teams were driving toward the finish line with just a few things to wrap up and there was generally a good vibe around the office. But like most offices, there was a big concern in upper management about productivity. We don’t want to see anybody sitting idle.

Soon the pressure was on to start up a bunch of new projects. But the problem was, we didn’t quite have all the beginning-of-the-project work done and ready to communicate to the teams.

No bother. They can get started anyways! Right?

Some people thought so. But very quickly I had UX team members dropping by my office to lodge their complaints.

Actually, not all of them complained. One went right to work designing the thing he was asked to design.

Good for him right?

No!

The beginning of a project is a CRITICAL time for UX because that’s typically when we encounter the bulk of the assumptions that people make. And it’s our job – our mission in life – to check the assumptions.

You should never go straight into designing something without knowing the basics.

Oh, but that will take too long! We don’t have time to burn on research cycles! That dang UX is going to slow everybody down!

I’ve heard that before. But it doesn’t have to be that way at all. To get started, all you really need to do is answer two questions:

1)       What do we want to get out of this project?

2)       What does the customer want to get out of this project?

We saw such a pattern of teams starting up without addressing these two basic questions (I’m sure nobody else has ever encountered this) that we ended up doing a special UX team session on “The Questions”. One of the team members, Fergal Moynihan, created a PPT deck and hosted a team discussion on the topic to help get everyone focused.

the-questions-PPT-slide

Frankly, we were bad at starting projects at my company for a while. But that was no excuse for UX not to do their job. I told them to think about it as if we were working for an agency (we don’t). There are ‘good clients’ who are totally prepared when you meet with them. They know their goals, they know their customers, they know their competitors, and as you talk with them the vision for the project flows out like poetry.

But then there’s the clients who are totally disorganized. They’re vague on their goals, they disagree on priorities, they have specific solutions in mind before they’ve ever talked about the customer problem, etc. etc.

As a UXer in that situation, you don’t say, “Oh well, I guess I better just start designing something.” No! That’s when you reach into your bag of tricks and start extracting the information you need to make the project great.

Sometimes that data will come from the people right there in the room. Other times, you get contact info for others who can help you out and you follow up with them. But one way or another, you get the information. Because you need it to do your job.

intro-to-ux-01

To bring it all back home, what I talk about ‘The Questions’ I’m talking about the fundamentals of the project. You have to have a basic orientation on what you’re doing, why, and for who, before you can start designing or, God forbid, start building something.

It is VERY important that you don’t skip this step – regardless of the pressure or the situation.

It’s also very important to check assumptions at this stage.

If someone tells you, “I need a button that goes ‘Foo’ when I click it.” You don’t just say OK and then go design the Foo button. (That’s called ‘leading with the solution’, by the way, which is a big red flag telling you to dig deeper.) You ask why. And you probe for meaning. And you don’t stop until you understand the motivation for the Foo button and can agree that that is indeed the right thing to build. That, or … maybe you discover that there’s really something else you should be designing that lies behind that initial thought.

And that’s where UX can add real value.

Boom.