RD: I’d like to ask for a favor: please sing happy birthday to my son Alex, who is 10 years old today. [And we did.]
Vanguard’s UX is quite mature and quite large, and the UX of the online channel is very important to us. Because of that, we spend a lot of time trying to improve it. There are lots of projects in flight, each trying to make improvements to the experience.
Flight analogy: Let’s pretend one of our teams was asked to improve this aircraft to carry more cargo. And then another team decides that passenger capacity is really important. And then another one decides speed is really critical – another redesign.
We have a problem very similar to this at Vanguard: each team has its own objective, so they lose sight of the big picture.
We didn’t have a way of facilitating a conversation about these multiple business needs and experience. They’re just trying to express their particular priorities that they’re feeling on that particular day.
“Our experience becomes very schizophrenic… it’s very difficult for them to hit this moving target.”
Images: Is this a good [fill in the blank] experience? “I can’t say. I don’t know what ‘good’ is.”
We measure a lot of stuff at Vanguard, but mostly because we can – not necessarily because they’re an effective measure of whether the page is good or not.
In the rare case when a project comes along and establishes a reasonable metric, when the next project comes along they create a new one.
So we can’t measure our level of success over time.
The root cause: the lack of a common language for describing what our designs are supposed to do and for describing the objectives of the experience.
Terminology:
- Goals: Users have goals, and the business has goals. But these goals are really too high-level to be helpful in designing experiences.
- Tasks: Users do stuff so they can meet their goals. The business also wants users to complete certain tasks.
- Emotions: Users also have feelings about their goals & tasks, and the business wants users to feel certain ways: confident, independent, trusting.
- Capabilities: These capabilities help users complete the tasks they want to complete. And this experience is across channels – we’re not just talking about the web here.
- Projects: These capabilities are created or changed by projects over time.
Framework:
- Made up of about 90 user tasks grouped into 8 high-level categories.
- There are also 45 business-driven tasks divided into 7 categories.
- In the middle are 635 capabilities (and counting)…
Two tools:
- Capability strategy sheet
- Experience strategy map
Let’s follow the Rollover Offer capability. To create this capability sheet, we extract out and identify all of the tasks that this capability has to satisfy. E.g., this capability relates to two main user-driven tasks, which can be re-worded for this particular context/capability. There are also 3 main business-driven tasks (with subtasks).
Q from audience: “What initiates this particular capability?” [Will go into later.]
They then take all the related tasks and prioritize them. And this again is a great discussion. The process of getting the tasks into priority is what really matters, not where exactly they fall in the list – b/c it brings out the rationale behind the prioritization.
Sometimes the tasks get linked together – b/c the users want to do something, and we want them to do the same thing.
We then think about: emotional considerations, the high-level approach, and our success criteria: “how do we know what is a good experience?”
Determining the success criteria is the most difficult piece of the puzzle; they need to be specific enough to be measurable, and clear enough to not lead to subjective interpretations.
They then number the tasks that are represented on the particular (current state) page. “Now we have some rationale to talk to the business” about the design options.
Capability Strategy Sheet:
This lets us do 3 things:
1. Ensure that project teams are aware of everything they need to be aware of when they’re considering re-designing a capability.
2. Help sponsors stay focused on tasks and their priorities rather than [particular] design decisions.
3. Support the controlled evolution of capabilities by providing a stable framework to evaluate success or failure.
Note: These are not “project sheets”; projects come and go, but capabilities are forever.
[Transfers the mike to Rob Weening]
Experience Strategy Map:
- Derived from Indi Young and Adaptive Path’s concept of mental models.
We take the high-level categories and spread them out across the top. Below that are tasks that users want to complete when they are completing that activity.
Below that are rows for the different channels users might touch. Where the channels cross the tasks (columns), we have the capabilities. This map shows that a single capability performs multiple tasks.
Every item has a measure associated with it, using a traffic light metaphor (green, yellow, red tags).
So what you’re seeing is a little conceptual corner of what is a huge map. This huge “dashboard-like thing” allows us to do several things:
1. See which capabilities support which tasks across all the channels. “It’s like a huge map of our UX world.”
2. You can evaluate the consistency of different approaches to supporting specific, related tasks. You can do a “disciplined consistency check.”
3. Check the health of the entire experience. This helps sponsors prioritize which capabilities should be improved.
Say an intersection is red, and you decide that you want to fix that. What if 1 in 10K users visit that capability; would you decide to fix it? This creates a bigger context for prioritizing “where there is smoke in the UX” and decide whether there is really a fire that you need to fix.
How are we going to make this wonderful model work in the context of the larger organization? What are some other potential uses for the framework?
Reaction when they share the framework to others in the business: “You are boiling the ocean, and we don’t have time for this.” The good news: when you take the capabilities one at a time, the framework is actually pretty simple to use. It only takes about 2 or 3 hours to build a capability strategy sheet.
That’s how we’re going to proceed in the short-term: we’re going to select the ones that we think we need to write capability strategy sheets for, and slowly introduce the idea and gain momentum.
We need our business partners to spread the idea through the organization.
Future vision of other applications: We’re thinking maybe this could be used to affect an even larger organizational change, with regard to the yearly budgeting and prioritization process. The projects under consideration are described in 2-3 page “project charters”; more often than not, those documents contain design directions, such as “move this link over here” or “create a whole new silo.”
It’s very natural for the business to want to express their objectives in terms of concrete physical things. The downside of this is that, from the very get-go, the business is in the business of user experience design. “Somehow, we keep on hoping that’s our job.” What we’d like to do is work with a few business partners to develop some project briefs that identify the tasks and capabilities that they want to change, and decide how to adjust them to make them better – i.e., to identify the business problems involved, rather than the specific design solutions.
Another insight: The same goals, tasks & emotions can often describe the current and future state. “You want to know where the user experience is going to go in the next 5 years. This just records the change – it doesn’t direct it.” [Pitch for Jared Spool's talk tomorrow on the importance of having a vision for the user experience.]
Imagine having an experience strategy map for the FUTURE. The core goals, tasks & emotions will remain the same, while the approach might change in the future state.
To close: the journey is as important as the destination. This language we created that this language enabled people on cross-functional teams to come together and collaborate with each other. They came together to talk about this object: the task. “Everybody understood everybody else much more quickly than before.”
Would this work in your organization? It might, if your organization is like ours.
Q & A:
Stacy Surla: How do you reflect the capabilities and change in your framework?
Rob W.: We’re going to talk with a bunch of business people, and we’re going to iterate on the map, and draw in where the change will be.
RD: We have two columns in the map: one of the current state, and one of the possible future state.
Whoa! Thats an awesome summary Michael – better than I could do!