Teams moving to agile often struggle to integrate agile with best practices in user-centered design (UCD) and user experience (UX) in general. Fortunately, using a UX Integration Matrix helps integrate UX and agile by including UX information and requirements right in the product backlog.
While both agile and UX methods share some best practices—like iteration and defining requirements based on stories about users—agile and UX methods evolved for different purposes, supporting different values. Agile methods were developed without consideration for UX best practices. Early agile pioneers were working on in-house IT projects (custom software) or enterprise software [1, 2].
The economics are different in selling consumer products than when developing software for enterprises—UX matters more for consumer products. Jeff Bezos cares if users know how to click the button that puts money in his pocket more than Larry Ellison cares about any button in Oracle software. Larry makes money even if people can’t use his software. Oracle sells support contracts and professional services to fix things customers don’t like. Amazon and other online businesses can’t operate like that. They have to get the UX right, or they go out of business fast. User experience factors rarely get the same level of consideration when the end-user is not the same person as the paying customer [3].
Agile teams and UX problems
I’ve encountered two problems common among agile teams when helping them improve the user experience of their products or services:
- UX work is frequently overlooked during the release and sprint planning efforts.
- Teams often fail to measure the UX impact of their iterative efforts.
These two problems become more serious when combined.
When UX work goes undone and the impact is not measured, the team doing the work has no idea what is going on. The feedback loop is broken. Both agile and UX methods emphasize iteration, but productive iteration requires good feedback loops.
You can conduct development iterations (the focus of agile) or design iterations (the focus of UX), but if you fail to measure the impact of the iteration, you won’t see the real benefits of an iterative process. You will have no real idea if your offering is any closer to meeting the needs of the end user. The User Experience Integration Matrix (UXI Matrix) addresses these problems by tying UX to the project backlog.
Integrating UX into the product backlog
You can conduct development iterations (the focus of agile) or design iterations (the focus of UX), but if you fail to measure the impact of the iteration, you won’t see the real benefits of an iterative process. You will have no real idea if your offering is any closer to meeting the needs of the end user.
Scrum (one of the most popular variants of agile) advocates you create a Product Backlog, a collection of stories that describe user needs. The team iteratively refines the requirements, from rough (and often ill defined) to more specific. This is achieved using stories from a user’s perspective, which have conditions of satisfaction associated with them. This concept is adapted from UCD’s scenario based design methods. In my view, this is far better than other traditional approaches to documenting requirements that are often detached from user’s goals.
Various agile gurus [4, 5] discuss how to break down requirements from high-level stories to user needs targeted at specific users. Even if your team follows Jeff Patton’s story mapping method [6], (which I highly recommend) to create structured hierarchical representations, you’ll often find you want to analyze the stories by different factors as you groom your backlog.
I’ve worked with teams who want to analyze stories the following ways:
- Order of dependency or workflow (self-service password reset depends on user registration)
- Criticality (which of these stories must be done so customers pay us next month)
- How much work will they take to complete (show me all the epics)
- What related stories do I have (find requirements with related UI patterns)
- By role or persona (show me all the stories that impact persona X)
- What stories have a high impact on the UX, so we can focus on those?
If the project is small (both in number of team members and number of stories) you might be able to get away with rearranging story cards on the wall. However, in my experience, things inevitably get more complex. You often want to consider multiple factors when reviewing the backlog. A UXI Matrix helps you track and view these multiple factors.
Creating a UX Integration Matrix
The UXI Matrix is a simple, flexible, tool that extends the concept of the product backlog to include UX factors normally not tracked by agile teams. To create a UX Integration Matrix, you add several UX-related data points to your user stories:
| Column Name | Possible Values | Description |
|---|---|---|
| Persona | Persona’s name | Identifies the persona a user story applies to |
| UX complexity | 1 to 5 (or Fibonacci numbers if you’re into that sort of thing) | Estimates design effort separate from implementation effort |
| Story verified | Y/N | Is this story fiction or fact? Is it based on user research or customer input? |
| Design complete | Y/N | Is the design coherent enough for development to be able to code it (or estimate how long it would take to code)? |
| Task completion rates | 0 to 100% | The percentage of users who have been observed to complete the story without any assistance. |
| Staffing | Resource’s name | Who’s owns the design, at whatever level of fidelity is agreed to. |
With these columns added, your product backlog begins to look something like the spreadsheet in figure 1.

Figure 1: UX Integration Matrix, a simplified example
Advantages to using the UXI Matrix
The UXI Matrix helps teams integrate UX best practices and user-centered design by inserting UX at every level of the agile process.
Groom the backlog
During release and sprint planning you can sort, group, and filter user stories in Excel:
- Group by themes or epics, or anything you want to add via new columns
- A primary persona, a set of personas, or number of personas associated (more = higher)
- Stories you’ve verified via user research or ones you need to verify
- Stories you’ve completed but need to refine based on metrics
- Export stories into a format that can be used in information architecture work
- Explore related UX deliverables like personas, mockups, and research findings via hyperlinks to them
Note the summary rows near the bottom of the example in Figure 1. Those values can help you prioritize new and existing stories based on various UX factors.
Reduce design overhead
Perhaps my experience is unusual, but even when I’ve worked on teams as small as seven people, we still had trouble identifying redundant user stories or personas. My heuristic is that if a story shares several personas with another story in a multi-user system, then that story may be a duplicate. Grouping by themes can also help here.
Another useful heuristic is that if a persona shares a large list of user stories with another persona, it’s likely the personas should be merged. Most of the time personas that do the exact same things with a product can use the same design, unless of course they have very different skills or something, which becomes evident when reviewing the personas or conducting user research (which all good personas are based on in my view).
Facilitate collaboration
The UX Integration Matrix helps teams integrate UX best practices and user-centered design by inserting UX at every level of the agile process.
Another major benefit of the UXI Matrix format is you can share it with remote team members.
Listing assigned staff provides visibility into who’s doing what (see the columns under the heading Staffing). Team members can figure out who’s working on related stories and check on what’s complete, especially if you create a hyperlink to the design or research materials right there in the matrix.
For example, if there’s a Y in the Design Complete column, you can click the hyperlink on Y to review the design mockup. I’ve worked with teams who like to track review states here: work in progress (WIP), draft (D), reviewed ( R ), etc. (instead of just Y or N).
Track user involvement and other UX metrics
The UX Integration Matrix also helps track and share key UX metrics. One key metric to track is team contact with real end users. For example, if you’ve talked to real users to validate a persona, how many did you speak with? Another good metric is, how many users have been involved in testing the design (via usability tests, A/B tests, or otherwise)?
You can also capture objective, quantitative UX metrics like task completion rates, click/conversion rates, and satisfaction rates by persona. It makes it easier to convince the team to revisit previous designs when metrics show users cannot use a proposed design, or are unsatisfied with the current product or service. It can also be useful to track satisfaction by user story (or story specific stats from multivariate testing) in a column right next to the story.
Review UX metrics during sprint retrospectives
Scrum-style reviews and retrospectives are critical to improving both the design and team performance. However, few teams consider UX metrics as part of the retrospective. During these meetings, it’s helpful to have UX metrics next to the stories you are reviewing with the team.
I ask the team to answer these UX-related questions during the retrospective:
- Did we meet our UX goals for the sprint?
- Does our user research show that what we built is useful and usable?
- Are users satisfied with the new functionality (new stories)?
- Are users likely to promote our product or service (overall) to others?
- Do we have product usage metrics (via site analytics) that meet our expectations?
- Is there existing functionality (stories) that need to be refined before we add new stuff?
- What user research should we do to prioritize stories going forward?
- Do we have enough staff with UX skills to meet our objectives?
- Going forward should we:
- Work a sprint ahead to ensure we validate UX assumptions?
- Do a spike to refine a critical part of the UX?
- Refocus UX work on select user stories or personas?
- Improve our feedback mechanisms to capture factors we are missing today?
Figure 2: The UX Integration Matrix inserts key user experience activities and context adjacent to user stories into the product backlog.
Improving your team’s design decisions
Once you start tracking in the UX Integration Matrix it becomes easier to have informed discussions during reviews and retrospectives. I use the UXI Matrix to set UX goals with the team, help prioritize stories in the backlog, track UX work in progress, and to help answer the classic agile problem “what does done mean”; not just for the entire product or service, but for individual stories.
I’d be curious to hear from others who would like to share their experiences with variations of the above or similar methods. On the other hand, if you’re an agile guy that thinks this all is very non-agile, I’ll ask “can you really prove your method creates a better UX without this stuff?”
Start using the UXI Matrix in your next sprint. Download and customize this Excel template to get started:
- UX Integration Matrix template (33kb Microsoft Excel .xls file)
[1] Larman, Craig. Agile and Iterative Development: A Manager’s Guide. Pearson Education, 2004.
[2] Sutherland, Jeff. “Agile Development: Lessons learned from the first scrum”. Cutter Agile Project Management Advisory Service, Executive Update, Vol. 5, No. 20, 2004: http://www.scrumalliance.org/resources/35.
[3] Cagan, Martin. Inspired: How To Create Products Customers Love. SVPG Press, 2010.
[4] Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley Professional, 2004.
[5] Cockburn, Alistair. Agile Software Development. Addison-Wesley Professional, 2001.
[6] Patton, Jeff; “It’s All In How You Slice It”, Better Software, January 2005: http://www.agileproductdesign.com/writing/how_you_slice_it.pdf.
Jon – this is a fascinating and very deep article with lots to think about, and lots of practical ideas to consider. This may be blindingly obvious, but what does the “PO” stand for in “PO Business Impact”?
Thanks,
Chris.
Hi Chris,
Glad you like the article. PO stands for product owner, which is what they call the person in charge of the backlog in Scrum. They should be the person making sure you have a list of stories to start with. The PO should be your closest partner on any Scrum project as a UX person. If not you’ll find things will go poorly.
Sorry about omitting that definition, I worked with the B&A editors in a very agile fashion on this post. There are a few rough edges still, but we thought it was a MVP or “minimum viable post”…at least I hope so 🙂
If you want to learn more about the product owner role or Scrum in general, I recommend Mike Cohn’s book “Succeeding with Agile” or Roman Pichler’s book “Agile Product Management with Scrum.” Roman has a blog at http://www.romanpichler.com/ and that’s a great place to start. I found Mike’s book so good I took his Certified Scrum Product Owner course and it was time well spent.
Great article, Jon. I really appreciate those questions you presented at the end – good reality checks.
I’m currently facing the situation highlighted in this article on a project I just came into. I tried implementing Scrum, but realized that this project should be UX-driven. It’s an interesting challenge because we really lack UX experience on our team, so we’ve gone external and hired a UX Designer. That solves the lack of experience to a degree, but the project, in terms of organization and process from UX to Development, is still in a bit of a flux, so I’m really eager to try this UXI Matrix out.
You mention UX metrics often and I agree that they are very important in order to make informative decisions. I’m really new to UX and I’m wondering where and how would I gather these metrics? Google Analytics or similar metrics systems (i.e., KISSMetrics)? I’m also particularly curious how you track task completion rates. Any help would be great appreciated.
Thanks,
John
John,
I’ll let Jon respond to your comment and answer your questions about metrics, but you mentioned you implemented Scrum and later realized the project should be UX -driven.
This struck me as odd since Scrum only defines how the team meets, communicates, and prioritizes work. It doesn’t gvern whether a project is engineering- (what can we build?), market- (what is everyone else building?), or UX-driven (what do customers want us to build?).
Hi Austin,
A minor miscommunication or failure to communicate on my part. Sorry if that has caused you any confusion or frustration. The team was following an ad-hoc approach to development, but to be perfectly honest, there was no process. I put some process into place (i.e., Scrum). Now, our current challenge is integrating UX into Scrum. I hope that clears things up.
John,
Let me answer the question about metrics first and then I’ll comment on the idea of “UX-driven” projects. They’re actually related related topics.
There are many types of UX metrics that you can collect, and it’s important to focus on the right ones for your situation. These should clearly map to the stories you list in your backlog and your overall business goals. Task completion is sort of the gold standard in design research. Simply put, think of task completion as verifying that the intended user can use what you built to satisfy the story/requirement.
Before selecting a tool, think about what you want to do with it. Web analytics tools like those you mention allow you to track site traffic and provide low cost ways to get metrics like time on site, or % of users that click a link. Other tools like UserZoom make it easy to test task completion rates, which map nicely to functionality described in user story format.
Make sure whatever metrics you track are actionable. It’s one thing to know nobody visits a page, another to know why. Task completion rates can even be measured without any special tools at all just by watching users try to use the site in person. In fact this might be a good place to start. You could write an entire book on this topic, and many have, a good one is Measuring the UX by Tullis & Albert.
This leads to the idea of being “UX-driven.” It’s a common misconception that UX is just about coming up with UI designs, but it’s much more than that. It’s a holistic viewpoint of the design process. The UXI Matrix supports that. Right now, if you tried to use it to track what stories you have UI designs for, how would you know if these designs were any good? Using the UXI Matrix as shown above will help you prioritize UX work (both design and research) and have meaningful discussions about what’s not getting done, and how well you are doing.
Jon –
I appreciate the attention to detail in measuring and validating user stories. Are you seeing agile process as inclusive of the product planning stage? I don’t see that and just to clarify, I wouldn’t expect it either in the iterative design- in- production phase.
What is often confusing and lacking in these discussions and agile formulas is the recognition that the early gathering of user goals and user requirements is fundamentally a different process, where user research and PO’s work hand in hand th ideate and evnision product. That is not a development process. Until you have your general initiative and research done (including such things as personas), you can’t very well chunk out the individual stories for development. I think that is the problem with taking one ideology and trying to make it fit for the whole product lifecyle (which is much wider than the product software development life cyle, for which I think agile can work very well).
Perhaps you are making those assumptions ( that product planning has already occurred). A lot of folks though are bundling it all into one big blob…I’d like to hear your take on this.
I have another take. Adhering to research and process are one way to approach design. Not the only way. The thought that UX-driven means focusing on “what the customer wants” is a rather narrow way to look at UX design. Many times the customer can’t articulate what they want. Additionally, innovation often takes place through the creative process or intuition. And when we talk about analytics data, data can help identify the right questions to ask, but it can’t shed any insight into that which is unobservable – that which is occurring in the emotional parts of the brain. And neither qualitative or quantitative methods can tell you anything about that which does not yet exist. To me, UX is as much about letting the creative process unfold as it is about research and process.
I love the matrix and the brevity of the article. Themes (groups by meaning) are great way to recontextualize the term Epic (groups by effort) which is still apparently being used in the industry. I highly encourage using Themes (what are we doing) rather than Epics (look at all the work).
For anyone that has been doing this for years in enterprise environments, and, are looking for some ways to do the “incremental improvement” thing, I can poitn you towards some more good info.
1.Larry Constantine and Activity Centered Design for Agile. Excellent for closed domains like the US Healthcare system.
2. Jeff Patton and Storymaps. I worked with Jeff on internal project 5 years ago which gave rise to looking at how Indi Youngs mental mapping could be applied to writing flat requirements backlogs that could be modeled any way you like to create meaning (aka Storymaps).
3. Behavior Driven Development. Some tools include rBehave, now part of rSpec. Has value in software projects where a comprehensive UX requirements matrix can drive the actual test criteria. Cool stuff for those mired in massive complexity with hundreds or thousands of programmers,
Jon,
I really enjoyed your article particularly the way your characterizations translate to the sort of quantifiable metrics that Product Owners and Execs like to see and use in decision making. I have several questions:
– I don’t see much about how this plays in the broader project environment. I see why different stakeholders should value it but how do you get past the perception that UX is a strategic asset as well as a delivery asset?
– How has it typically been received by Product Owners or Project Managers? What level of education have you had to provide in order to simply be allowed to drive this method? I can see this being easier to implement as a consultant vs.an internal practitioner.
– How integrated or exclusive is this exercise? It looks like it resides entirely within UX for the things that inform it except for the PO Impact column. Do you have to defend it against Product & Dev bias? I think there are some predictable challenges there.
– How do you accommodate efforts where the empirical constraints like budget or time skew away from a more considered UX effort? (I know you’re not supposed to time-box an Agile effort but it’s not unheard of.)
I’m really intrigued by the opportunities this presents and I’m already trying to identify where we might use this method. It still looks like there are some common and widespread objections to overcome. I’ve had a great deal of experience and contention just trying to get people to agree that User Value is a separate consideration that needs to be factored-in on the same level as Business Value or Technical Risk. You make a great distinction between consumer driven products vs industrial client-server applications. You also note the need to account for UX lead-time when sequencing. I’d like to hear more about how the groundwork was laid in order to clear the way for this method to do its work.
Cheers,
-AP
I agree with Scott’s comment about ‘Themes’ I find that once an epic has been broken down into stories, these are often too discreet to consider within the broader context of the application or interaction design framework.
Building the stories back up (or stringing them together) into persona/user driven themes helps me consider the seamless interaction and UI design.
Chris, let me respond to your questions first:
Most of the agile literature has historically been a bit light on product planning & requirements gathering. That’s what I was alluding to in the start of this article. When I dug into why, I realized that it was because many of the projects agile techniques were first evolved for were either IT projects, or rewrites of existing (enterprise) software.
The nature of those projects are quite different compared to creating new offerings for the mass market. If you read The Lean Startup by Ries, or Inspired by Cagen you’ll see they note the same thing. Hugh Beyer, one of the UX pioneers of ethnographic methods has written more extensively on this topic from a UX perspective.
If you lack a coherent vision of the market and product, your team can waste a huge amount of time coding (and designing) stuff nobody wants. What I recommend is you take a very agile approach to solving this. Create some fictional personas and user stories and validate them in an agile fashion. That’s what the persona and story verified sections of the UXI Matrix are showing.
Eric Ries talks about his experience realizing his startup spent a year building the wrong stuff, only to discover this when they did some basic user research. You can avoid this by doing focused sprint 0’s or spikes of formative research on high risk stories or epics. For less risky stories, just plan to test so you can iterate on the as built UI before claiming the story is done.
So to summarize, create a backlog of stories that you think your key personas would want as shown in the UXI Matrix. Decide the risk of not verifying any story, theme, or epic (or the associated personas). Review this with everyone on the team. Not all stories are the same. Apple didn’t have to verify there were people that wanted to send quick emails from their phones. RIM had proven that was a valid story. Proving users could do this with a touch screen, well that was a bit more of a risk, right?
Jason,
I’m not trying to eliminate the creativity in UX. I just believe that good UX is design through hypothesis testing and refinement. Some agile folks think that you can just ask end-users to write your stories. I’m with you, I think that’s a flawed approach.
As for the measuring the unobservable. Good design researchers can find ways to measure things novice researchers have no idea how to. I know folks who’ve measured attractiveness by studying brain waves.
UX prototyping is all about how to evaluate stuff that doesn’t exist yet. Just as industrial designers build foam core models with weights in them, many UX teams create UI prototypes for the same reason. Prototyping can accelerate the learning process but it requires creative insights.
UX isn’t UX if it doesn’t balance design and research in my view. Alan Cooper once said, “you can’t sand a table into a chair,” but in my experience you can do some quick formative research and determine users need something to sit on, and then you can sand the splinters away before you launch (or not).
Scott,
Thanks. I just find it handy to be able to organize the backlog as needed. Most agile tools make it harder than excel. They definitely aren’t designed for UX needs, but then I’m not surprised by that.
I’m a bit confused. Mike Cohn distinguishes themes as collections of related stories, and epics as large stories. It’s the first I’ve heard that epics are not used anymore. What do you call the big stories that need to be broken up?
Another good reference is Agile Software Requirements by Dean Leffingwell. It’s new and covers UX to a limited degree.
Adam,
RE: “How do you get past the perception that UX is a strategic asset as well as a delivery asset?”
I always try to map UX metrics to the business goals. One might be increased NPS, hence the bottom row in the example. Another approach is to use Dave McClure’s framework and create themes of stories that map to AARRR.
As for partnering with the product owner or scrum master, it depends on their mindset. Ideally this is something you’d do working closely with the PO during backlog grooming. The 3 columns for estimates helps everyone feel heard during sprint planning. Socialize it with your scrum master, make sure to note that it’s a way for you to prioritize your deliverables as a UX person in an agile way, and explain how it might be used during the retrospective, etc.
As for time boxing, I”m not sure I understand. Agile is all about time boxing, that’s what a sprint in scrum is, a time box right? I use the UXI Matrix to carve off the top priority UX work to fit time and budget constraints using the same method that agile uses for development and QA.
Duncan,
Couldn’t agree more. Hope you find this helps make that easier.
Hey Jon,
In todays’ hyper-speed marketplace, in the time it takes to even put together and execute a research plan – not to mention implement and enforce any design “process,” a good designer could have concepted, designed, and built an execution that could then be tested and responded to. I feel that research driving insights is invaluable, but I have yet to see any UX process that results in deliverables that aren’t, at best, out-of-date by the time it comes to execute, or, at worst, completely flawed.
In my experience, a really good small team – say a designer, researcher, developer, and writer/content strategist – can get from point A to point B so quickly that they can then iterate to point C and launch before the “process” has even started. I believe that this is one of the reasons that both Facebook and Google have been successful. I’ve seen personas that spend months in development. If the team is good, they only need a few key points about the audience. Same for business goals.
I’m not into self-flagellation. I’m into doing good work fast, and I have yet to see any process that isn’t counter-productive to that approach. Just my perspective.
The fundamental problem I’m finding with this approach is that Agile is a development process and not a design process. I’ve worked with agile teams for about 5 years and forcing UX into and Agile process framework almost never works well. We as a profession need to think about how to integrate our own process with the process of the developers without trying to adapt their process. To draw an analogy from construction, I haven’t seen an Architect who tries to follow a process that construction engineers have developed.
I don’t see many Developers talking about how they can fit dev work into a UX process. And for good reason, because it wouldn’t work.
The solution is to somewhat de-couple design and development and give design some lead time. That doesn’t necessarily mean giving design months of lead time, for a small or iterative project a week or 2 can be sufficient. The challenge is that a lot of that has to do with organizational change and is out of the designers control.
@Jason – I find that if the design deliverables are outdated by the time it comes to execute, the problem is usually that the PO didn’t schedule any design time in the first place and instead had design and development start at the same time or worse, had the developers work on a product before the designers.
Enrique Allen at 500 Startups does a great presentation about how pretty much every successful .com company had a significant amount of design expertise among their founders including Facebook and Google.
Jason,
Just because a deliverable is out of date for the developers as soon as it’s created, doesn’t mean it’s out of date for your manager’s manager’s manager who will be seeing it in a week.
Deliverables are not only made to support developers. They have all kinds of purposes.
Similarly, conflating a UX process with the deliverables that may or may not fall out of that process is foolish. You don’t knock developers for everything they *could* do. You evaluate what they accomplish.
As for being out of date… What you really mean is that you’ve never been in a situation where there wasn’t a gap between what was built and what was designed. And I agree. Developers rarely build what’s designed. That’s not because deliverables are a waste of time. It’s because your team lacks a shared vision.
@Jason
Sounds like you’ve had some very bad experiences at places with a screwed up UX process that produces deliverables that aren’t used by anyone. Usually, that’s the result of a culture that emphasizes activity over accomplishment. Small teams can execute faster if they have the right skills. I totally agree. However, if your deliverables are flawed, or take too long to develop, I have to question who’s on the team or how it’s run. My point in this article is that if you think you are “doing good work fast” you should keep score–because if you don’t, you might not be doing anything other than keeping busy.
@Daniel
You said: “We as a profession need to think about how to integrate our own process with the process of the developers without trying to adapt their process.”
I totally agree. As Austin notes, I think the mistake most agile advocates make is that they don’t understand that UX is part of more than just the development process. It’s about understanding your target user’s needs and behaviors, creating a shared vision, and using that knowledge to create value so they become customers. In Scrum, you’ll need to work with the PO on the product backlog if you want to do more than just scramble to push pixels representing someone else’s bad idea before it gets built (and never used).
The UXI Matrix just allows you to figure out what deliverables are really adding value (or not) and identify when you need that lead time to make them. I’ve used it to drive that organizational change you describe. It’s a visualization of things and how they are related that reinforces their relationship (and the impacts of changing the deliverables). It’s in the product backlog format because I want to collaborate with the PO and the rest of the team, not create a separate deliverable that others can’t use easily.
The plug for activity-centered design from Scott is appreciated, but ACD is hardly restricted to “closed domains” like healthcare. In fact, Don Norman and I as leading advocates have both argued-for and demonstrated its advantages in consumer-targeted products. The bang-for-buck argument is simply that ACD, paricularly carried out with human activity modeling (hAM) and model-driven inquiry (as a more agile alternative to conventional ethnographic inquiry), is the fastest, cheapest shortcut to rich insight into genuine user needs that can help drive breakthrough designs.
–Larry Constantine, Madeira Interactive Technologies Institute
While I think this is a valid approach, I see it as an expensive workaround to the best solution many teams still refuse to fully adopt: to put UX designers and developers to work together under the same roof and so being able to understand how their work impact each other in a more practical way.
I don’t think this matrix is easy to maintain through the many iterations of an agile approach, but I might be wrong.
Mario,
Scrum and most agile methods assume that the team works together “under the same roof.” This isn’t meant to be a workaround to that, although it certainly can help in situations where that isn’t the case. The UXI Matrix is about providing transparency into UX work, both in terms of the individual tasks and the prioritization of work overall, in a similar fashion to how Scrum tracks development work.
While it may appear to be work to maintain, it really isn’t that hard if you are already tracking stories in a Scrum-style backlog. Some agile advocates say you shouldn’t track stories past the sprints they are worked on. That assumes you have a high degree of test automation in place (again an agile best practice). However, traditional test automation will not capture UX factors. For that reason, it’s best to track key stories & associated UX metrics for every persona long term as that helps teams avoid featuritis.
If you work electronically the cost of tracking older stories is minimal, and often worth the effort.
Great work Jon, very helpful and valuable!
As a comment to Jason, there are a number of ways to measure the emotional impact of a web page or conversion process, I’ve been working on this for years AND my methods don’t add any time to direct user testing techniques. I haven’t figured out a way to do them remotely or solely with analytics (not to discount analytics, they are invaluable but they say little about the emotional elements of persuasive design). I do agree that “user satisfaction surveys” are often flawed and I rarely rely upon them for this work.
Jon I think that your third paragraph nails it. UX was at best an afterthought in the early Agile Days. A search of their literature fails to turn up the word usability.
I’m going to adopt this matrix and will be certain to give credit where it is due.
Todd,
Glad you liked the article. Drop me an email regarding your methods for measuring emotional impact. I’d love to hear more. I get questions about that a lot and I’d love to be able to provide people with better ideas by citing your work.
Jon
Jon,
A user story is traditionally expressed in the format “As a [persona], I want [a feature], so that [I achieve a goal]”
The UXI matrix you present sees a single user story span multiple personas.
I like your writing, very thought provoking, but I can hear the retort of Beck, Schwaber et al now.
What’s wrong with the persona-per-story approach?
‘As a CEO, I want a wireframe, so I can a rough idea what i’m investing in’
and
‘As a customer, I want to shop without logging in, so that I haven’t wasted time if i didn’t end up buying’
Actually, scratch the question in my last comment.
I see what you’re saying now Jon about how the story-per-persona approach doesn’t alone help you if “you want to analyse the stories by different factors as you groom your backlog”.
I also see how the paragraph “Reduce Design Overhead” partially tackles this issue too.
Be careful, that’s my advice.
That traditional 1-1-1 Persona-Want-Reason userstory format is helping you set your priorities and release incrementally.
If you’ve got two stories like “Staff Member can log in” and “Customer can log in” and you merge them, you run the risk of delaying shippable functionality when one part of your merged story is finished but the other not.
Also, another story may be more important than half of your merged one, and you’ll get yourself in a knot.
Some programming teams just can’t design, granted.
They need something to help them pull up their socks.
I think the solution though is to put the designers in with the programmers on an equal footing. Build yourself a cross functional team. Include someone with business acumen too.
“Built-in instabilty. Self Organizing project teams. Overlapping development phases. Multilearning. Subtle Control and Organizational Transfer of learning.” (Nonaka and Takeuchi, as you know)
These were the secrets that helped build better cars and cameras, and they’re the philosophies that will help you build better software too.