Author: Dmitri Khanine

A PM’s Guide to User Experience (UX) – Part 2

Written by Dmitri Khanine on February 3, 2016. Posted in Articles. 5 Comments on A PM’s Guide to User Experience (UX) – Part 2

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)

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.

{module ad 300×100 Large mobile}

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.

A PM’s Guide to User Experience

Written by Dmitri Khanine on December 30, 2015. Posted in Articles. 5 Comments on A PM’s Guide to User Experience

What is User Experience Engineering and Why Should PMs Care?

The term “User Experience” or UX goes back to 1990s, but recently it has become increasingly popular.

With Capital One purchasing the lead design firm, Adaptive Path in late 2014 more and more businesses are turning to fields of Design and Usability. And they do so for good financial reasons. When applied correctly, UX methods reduce an organization’s risks, help manage the scope creep, and improve ROI.

Today’s UX has grown past its original applications in product design and website development. It is now a standalone discipline with a clear set of methods and a wide spectrum of applications – from enterprise applications and industrial equipment to consumer products and mobile apps.

Why Should PMs Care About UX?

Unless you’re developing an internal component of a bigger system that has absolutely no user interaction, the truth is, your team is already using UX tools, and they do so with various degrees of knowledge and confidence, producing various results.

This article will help you get the most of your time spent on this activity and point out some common pitfalls.

You’ll understand the key UX activities, their goals, deliverables, and what kind of outcomes you should expect.

I will also discuss the degree at which each of these activities is affecting your risk breakdown structure, your schedule, their typical durations, and typical manpower requirements.

Key UX phases and activities

Here’s a list of the top 7 key UX activities that are most relevant to Project Managers:

1. Stakeholder Review. This is a series of one-on-one interviews with key stakeholders and project sponsors. Yes, this is something you normally do as part of Project Initiation, only this time you focus on user experience.

2. Usability Review. A set of baseline usability tests of your sites or software. This is done if you’re looking to improve an existing site, product or app.

3.User Interviews and Observation. These are exactly what the name implies – when you interview your users to determine their needs and goals. These can be done in-person or remotely, scheduled or onsite.

Observation, not surprisingly, is when you observe users as they interact with sites or software in their normal daily environment.

4. Persona Development. Personas are fictional characters that represent key categories of users. Thinking from their point of view helps us make better decisions and makes it easy to validate user needs, motivations, and tasks.

5. Task Analysis and User Journey Maps. Task Analysis helps uncover the scope and complexity of a given user’s or group’s needs for an application or site. Journey Maps then help condense this data into a compelling visual summary, making it easy to analyze.

6. Prototyping and Wireframing. The meat and potatoes of UX process, where the findings from all previous steps are fleshed out in a life-like interactive application mock-up. If done right, this and the next activity, Usability Testing, is where the most benefits and risk reduction are taking place.

7. Usability Testing. Another potent risk-reducing activity that helps catch problems early on, without having to spend a lot of time and resources.

These activities fit into four phases, that help you gain knowledge, plan, apply, and quickly test your insights.

Let’s look at each phase in more detail. I will start with Prototyping and Testing phases because this is where most of the projects will realize their biggest and quickest wins.

Prototyping and Wireframing

Think of a working prototype. What comes to mind?

“A minimum set of functions that is sufficient to make the product useful for its target audience,” right?

Wrong.

This is what Lean and Agile methodologies are teaching we should build in each of the project phases, but this is not a prototype.

Even if you’re asking a developer only to build the UI layer and have users inspect it before continuing with middle tier and database – you’re asking for too much. These real life prototypes take too long and cost too much to develop. People get attached to them and will be reluctant to change, even if there’s a good reason. Clients are then stuck with less than optimal implementation, valuable time is spent on costly updates, and many useful features are never discovered because the time is spent on building and updating these heavy ‘prototypes.’

Wireframing offers a great alternative. A wireframe is a quick mock-up that represents the layout and, often, some of the key functionality of the screen. It’s simple enough be produced in minutes instead of days or even hours – yet it’s close enough to the real thing to be lifelike and fully convey the features and the meaning to end users. (See screenshot below)

You could use Visio or specialized tools like Balsamiq or Axure, that we like to use – to quickly create these and string them together.

Now not only could these be updated really quickly, but any changes can also be made on the fly, right during a meeting with a client – so they can instantly see the effect of the changes they’re requesting – and make adjustments right there and then.

And because wireframes are so easy to produce, it is now feasible to prototype 100 percent of application screens and even link them together, so when you click on attachment link in the wireframe above, Edit Attachment wireframe actually comes up, and real lifelike testing becomes possible.

Now this is a real chance to curb potential scope creep and realize screen flow problems, missing functionality and inconsistencies. If you’re missing a feature, you’ll know it immediately, in your week 1, when the budget is still intact, and you still have the time to make adjustments.

Most ‘conventional’ implementations discover missing features and inconsistencies much later in the project, resulting in major rework, schedule slips, and budget overruns. Yet all that was needed to spot these is simply have your business users look at the prototype.

Conclusion

I hope you’re beginning to see the value of employing UX processes and activities in your projects. We looked how using wireframes instead of conventional ‘heavy’ prototyping could reduce project risks and make estimating and planning a whole lot easier. And I can also personally attest to multiple million dollar savings realized when wireframes helped clients uncover major opportunities for improvement.

I’ll be writing some follow-up articles to continue exploring these time-tested processes of using wireframes for finding missing features, confusing and redundant functionality. I will then explore the processes and the tricks of quickly ‘extracting’ the true domain knowledge from your users, the knowledge that they just won’t be able to explain even if they really wanted.