Featured in these publications:

Featured in these publications:


"Can you really fix most of these common requirements issues by using an 'Active' approach to Business Analysis?"

According to PMI , 47% of projects that missed the mark are there because of requirements management. Are you seeing any of these signs of r...

Monday, December 21, 2015

Slashing Risks with User Experience Engineering (Part 2)

This article was originally published on ProjectManagement.com:


In Part 1, we introduced the idea of User Experience Engineering (UX) and the core tools and processes we use today to conduct user research. Let me continue by showing the core principle that all user research is based on--and how you can use it to combat scope creep and other requirements-based risks right now.

What's Wrong with Requirements Management?

As I mentioned, last year's PMI study shows that 47% of unsuccessful projects fail due to poor requirements management, so let's see if we can figure out why is this happening. Let me ask you: What are the two key characteristics of great business requirements? Complete and traceable, correct?

We wanted to make sure that all 100 percent of the user requirements are captured and nothing is missed. Then we wanted to make sure that each of the use cases is there to implement a specific user requirement.

Then the biggest risk inherent in requirements management is the scope creep. That's when new requirements are “discovered” after the implementation phase has started, throwing a monkey wrench into your schedule and your budget. Scrum and other agile methods then came to the rescue with splitting the project into a number of small iterations, reducing the impact of these after-the-fact revelations.

But small things still add up to big numbers. So wouldn’t it be nice to figure out why users just keep on coming up with these insights late into the project? Is that because we forgot to ask users the “right” questions? Or because business users are not properly managed and should not be allowed to interfere with our projects by mistake?

Let's look at an example…

10,000 Songs in Your Pocket

Remember what brought Apple back to life in 2001? The iPod. And what made it so successful? The big promise: "10,000 Songs In Your Pocket" (which quickly became 40,000 songs, as the photo below shows).

Picture credit: Engadget

Do you think users have asked Steve Jobs to give them 10,000 songs to go? No, they did not. They wanted a better mp3 player.

Now do you think they asked Apple to put a mini hard drive into an mp3 player to cram more songs in there? Most people didn’t even know what the “hard rive” actually was! It was the designers at Apple that found the mini hard drive that the iPod could use, and designed its friendly user interface. Then they were watching people use it and found that they were able to figure it out immediately without any explanation.

Users did not design the iPhone, either. They can't even tell you where they spend the most of their time during the day. That's the job of a UX practitioner. We watch users engage in their daily activities and document where the time is spent, what activities were easy and where people were struggling.

So we never want to ask users what they want. We want to ask them what they don't want and what problems they are facing. It then becomes the job of the designer to put tougher a solution for them. And then you want to watch them using it and see if it's working as expected.

Sony mp3 players had great battery life and they looked awesome, but it's the iPod that made history. You would've never known it if you asked the users at the time--they loved the Sony one just as much.

The Big Flaw

So that brings us to the big flaw in traditional requirements management. You can be more or less organized, you can do a good job at capturing everything your users are saying and linking these statements to use cases. And if you use Scrum, you can get away with a lot of things. But most of the trouble could be easily avoided if you can only change one thing: Stop asking users what they want. They can't give you the right answer, even if they really, really wanted. And it's not their job to design a solution--it's the designer's job. So that is the main flaw.

Users can easily tell you what they don't want. They can easily explain what makes their lives difficult. But if you ask them what do they do need to make it all better--this is when you run into all sorts of issues. And that's why the scope creep is here--it's when you ask your users to design the solution, something they have never signed up to do.

So instead of asking users what they want, user research focuses on carefully observing people's current behavior and interviewing them about their current situation. When we see the problems people are facing right now, we can use our training and experience as designers to put forward the solutions. We can then bring it full circle by watching people “use” our prototypes and see how successful we were at addressing current concerns.

Coming up next: I hope I was able to explain the big idea that makes the latest UX methodology so successful. As it stands now, I'm planning to start exploring the actual steps involved in prototyping and usability testing first, followed by reviews of the popular tools to use and other UX activities I mentioned in Part 1 of these series. I would love to see your thoughts in the comments section below. If anything is missing or you'd like me to cover something first, please do speak up!

No comments:

Post a Comment