We make changes to our user experiences based on heuristics, usability testing, and data, but do we really know if we’re improving the overall experience over time and across projects?
Richard DaltonSenior Manager of User Experience at Vanguard
Experience Strategy: Dealing With a UX Mid-Life Crisis
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
Editor's Notes
We work at an investment management company called Vanguard. Our user experience is very mature and very important to us, especially the online channel, because it handles most of our client interactions. And because we care a lot about it, year after year we have lots of projects trying to improve it. Which sometimes feels a little bit like this – lots of activity purposefully going in different directions, one after another – or even at the same time.
To extend this metaphor for a moment, imagine that folks at Vanguard tried their hand at aircraft design. A team is assigned to improve this bi-plane to carry more cargo …
… they might come up with something like this cargo plane. A little while later, another team discovers that passenger capacity is very important, and they redesign it …
… into this passenger plane. Still later, another team decides that speed is critical …
… and produces this fighter. Lastly, minutes before the deadline, a team of IAs decides that this …
… would be appropriate, and so on.We have this problem with our experience. Each project gets so focused on its own improvements that it doesn’t see the big picture – the fact that the experience has to balance a number of user tasks and business goals. Unfortunately we don’t have a way to facilitate a conversation about the overall objectives and priorities of the experience other than arguing about the design. So when we show our designs to project sponsors they often take it upon themselves to redesign them. “Make it red, make it bigger, move it up the page” they’ll say – they’re really just trying to express the objectives and priorities of their project. As a result the priorities for the experience are constantly changing over time.
This isn’t the only challenge we face however.Tell me, is this a good web page?
How about this one?
How about this iPhone app, is it “good”?
Or this drive-thru experience?Of course, I can’t tell you, because “good” needs to be evaluated in the context of what the experience is trying to achieve and since I didn’t design it, I don’t know for sure what that is.
So how about this one?I should be able to tell you if this one is “good”, right? Well this is also a problem for us. You see, too often we measure things “because we can”, not because they’re true measures of success. “10,000 people hit this page last month” someone will say. Well so what? Is that good? Did we want more? Less? Did those 10,000 people get what they needed from it? Where 100,000 looking for it and only 10,000 found it? Our measures are rarely in the context of objectives and so we never really know if the experience is “good”. Because of that we can’t learn from our mistakes, and we don’t know if we’re improving the experience over time.
So, we have two problems, projects becoming too focused and not seeing the big picture and no real way to judge success. We had thought that our design process was quite robust so this was a bit of a mid-life crisis for us. As we thought more about it we realized that both of these problems shared the same fundamental root cause: the lack of a common language for describing the objectives of the experience. So we’ve spent the last 6 months trying to fill this gap by pulling together the research we’ve gathered over the last few years to create a framework that fosters big picture thinking and allows us to measure success against meaningful objectives. This is much easier to show than to explain, so let’s take a look.
Before we look at the framework itself lets level-set on some basic terminology.
However we know that users aren’t simply robots, blindly performing tasks. They have feelings and emotions about the activities they’re doing.
The framework is constructed from user-driven tasks, business-driven tasks and capabilities.
The framework allows us to create two distinct tools. The first, called a “Capability Strategy Sheet” is useful for practitioners focusing on a single part of the experience. The second view, called an “Experience Strategy Map” is useful for UX managers responsible for the entire experience.
Lets take a look at how we use the framework to create a strategy sheet for a single capability.
We use the framework to identify the tasks that this capability has to satisfy.
Then we prioritize the tasks.
And for each task, describe any emotional considerations, a high-level approach and the success criteria to show if we’re satisfying it well.
We can then use the sheet to inform, analyze and discuss our design solutions.
The other tool that we can create is the Experience Strategy Map. This is a little like one of Indi Young’s mental models in structure with the user tasks arranged along the top and the capabilities mapped against the appropriate tasks. We can also surface the success criteria onto this map, showing how well each capability satisfies a task.
When we show people the framework’s 90 user driven tasks, 45 business driven tasks, and 600 (and counting) capabilities, they’re often overwhelmed by the size and complexity of the idea. And that’s an unfortunate, but understandable reaction, because there’s no doubt that the framework really is a “big” idea. That’s’ the bad news…The good news is that taken one capability at a time, the framework is surprisingly simple and easy to use. Working with our business partners, we’ve found that it takes 2-3 hours to create a basic sheet, i.e., a prioritized list of 10-15 tasks. And we’ve found that once the business understands the language of the framework, they actively engage in discussing tasks and task prioritization.
…And it’s a great thing that our business colleagues seem to enjoy participating in capability discussions – because not only are they critical to identifying tasks and setting priorities, but they’re also critical to getting the framework accepted in the larger organization. We need a small group in the business to have positive experiences using the framework so that they will recommend it to their colleagues working on other projects.
Now let’s talk about some other applications of the framework. Up to now, we’ve talked about using the language of goals and tasks to describe the capabilities that make up our user experience. We also think that the same framework could effect an even broader cultural change. Here’s how that might work. Each year at Vanguard, middle and upper managers meet to discuss and prioritize the projects they want to fund. Those projects are described in 2-3 page documents called project briefs, or charters. And very often, the brief will contain very concrete design directives, like: Add a link on this page… Add content here… Make this more prominent on the site…Add this new section to the site…OK, we recognize that it’s quite natural to describe a project in terms of tangible, physical things. But that also has an unfortunate side-effect: right from the outset of a project, it puts the business squarely into the business of user experience design… and somehow, we keep on hoping that that’s our job. So here’s the opportunity: We want to work with the business to write their project briefs using our framework’s goals and tasks and then help them to identify the capabilities that should be improved or created. How would this be better? We’re hoping that it would allow the business to focus more on defining the problems it’s trying to solve; and it would allow us to focus on finding solutions.
We set out with a couple of fairly tactical problems - to improve the way we set goals for and evaluate our user experience. However, the solution we came up with – this common language – is causing us to behave differently. By facilitating communication across roles and over time it’s enabling people with different perspectives, backgrounds and responsibilities to talk and collaborate – and ultimately work together towards shared goals. Now, will this work for you? Well – we’re not sure, but we do think it could work for organizations like ours. Ones with a mature user experience, where the tasks and capabilities are well known and where continuous, measurable improvement of the user experience is desired. If you try it, even pieces of it, we’d love to know how it works out for you.