Wednesday, 03 February 2016 09:10

A PM's Guide to User Experience (UX) - Part 2

Written by

WHAT IS USER EXPERIENCE ENGINEERING AND WHY SHOULD PMS CARE?

In Part 1 we looked at the key UX capabilities and started to explore the use of wireframing as a quicker and more efficient substitute to conventional 'heavy' prototypes. In this part, we'll take a step back and look at what comes before the prototyping.

I briefly mentioned that UX has been increasingly popular in the recent years due to the great triumphs of design at Apple, Google, and other market leaders. But this has little to do with the biggest value that UX can bring to the frontline trenches of enterprise software delivery, where people like you and I are spending most of our time.

The Big Secret

One of the biggest misunderstandings about the UX is the simple fact that it's not all about the design. Yes, design is a big part of it and the reason for its recent popularity, but the biggest promise and the greatest potential of UX lies in its new approach to business requirements - it's User Research Tools.

As I mentioned, last year's PMI study showed that 47% of IT projects get in trouble due to poor requirements management, so let's see if we can figure out why is this taking place.
Let me ask - what are the two key characteristics of great business requirements?

Complete and traceable, correct?

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

But how do these requirements get captured?

The Download

That's right. A Business Analyst sits with a project sponsor (or key stakeholders as well if we're lucky) and they essentially write down everything being said. It's a 'download' session.
The outcome is then shaped into a Business Requirements Specification and passed on to Development for implementation.

Then the biggest risk in today's project delivery is 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 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 that be nice to figure out why users keep on coming up with these insights late into the project?

Could anything be wrong with “The Download Approach”? Or did we simply forget to ask them the 'right' questions?

Or maybe it's 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:

A Thousand Songs In Your Pocket

Remember what brought Apple back to life in 2001?

The iPod.

And what made it so successful?

The big promise, "A Thousand Songs In Your Pocket" (that quickly became 30,000 songs - as the photo below shows)

stevejobs
Picture credit - Engadget

Do you think users asked Steve Jobs to give them a thousand songs to go? No, they never did. They just wanted a better mp3 player.

People have never asked Henry Ford to build a car either. Everyone wanted a faster horse!

So Henry did not conduct focus groups, and he never put horse and buggy owners in the room asking what would they like to do next. He experimented with gasoline engines!

So do you think music fans 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 drive' actually was! It was the designers at Apple that found the mini-hard drive that iPod could use and designed its user-friendly 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. Most users 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 are easy and where people are 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 the history. You would have never told it if you asked the users at the time - they loved the Sony one just as much.

The Missing Part

So that brings us to the big flaw in traditional requirement management. You can be more or less organized; you can do a good job at capturing everything your stakeholders are saying and linking these statements to use cases. 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.

I'm not saying you should not be talking to your users. You definitely should. I'm actually saying that you should go beyond your key stakeholders. Reach out to ALL of your business users. Ask everyone. You never know where the key insight would come.

The best way to stop the scope creep is to have complete understanding upfront of problems, wants, and expectations before the project is started! It helps you focus on the right problems to solve!

And I have a few tools for you to make it easy and cost-efficient to ask every single user in an enterprise.

Just ask the right questions!

Users can't accurately describe what they want, even if they really, really tried. And it's not their job to design a solution. It's the Designer's job. So that is the main reason “The Download Approach” doesn't work. And that's the biggest flaw in traditional requirements management.

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, UX User Research focuses on carefully observing people's current behavior and interviewing them about the situation they are in right now.

When we see the problems people are facing at the moment, 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 provide some useful pointers to help you make requirements management processes more effective. In Part 3 I'm planning to cover the last group of UX processes, where we use numbers and hard facts to verify our design prototypes.

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.

Read 7069 times
Dmitri Khanine

Dmitri is an Oracle ACE, nationally recognized expert in Oracle technologies, Content Management and Software Usability, published author and frequent speaker at industry events. 

He loves to impress business users with six and seven figure savings with User Centered Design, which feeds his passion for user productivity and dynamic UIs.

Latest from Dmitri Khanine

© ProjectTimes.com 2017

macgregor logo white web