Whether you\u2019re at the receiving end of an incoming product acquisition or joining as a new hire, corralling UX debt starts with discovering what you\u2019re up against. And that means conducting an inventory.<\/p>\n
Let me walk you through the process.<\/p>\n
First, sit down and use the product. You want to do this yourself to highlight anything you find unintuitive or confusing. Keep notes as you go, or ask someone to write down your comments as you use the product\u2014then switch places.<\/p>\n
![\"image03\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/07\/image03-700x166.png\")
<\/p>\n
UX debt spreadsheet used by my team<\/em><\/p>\n Another collaboration option entails using a spreadsheet (like this one<\/a>) in your team\u2019s cloud folder while evaluating the heuristics together. As the creators Susan Rector and Kim Dunwoody suggest, review the system based on criteria in the following categories:<\/p>\n You can create a solid snapshot of UX gaps by involving the whole team. Completing the evaluation will definitely take more than a week. Be sure to block out a manageable timespan to slowly chip away at it (e.g., 1-2 months).<\/p>\n Remember that while this exercise is highly informative, at the end of the day, you\u2019re not the intended user.<\/p>\n Now that you\u2019ve conducted a UX debt inventory, it\u2019s time to validate your findings by observing and talking with actual users and subject matter experts (read more on that in Rian van der Merwe\u2019s free guide Practical Enterprise User Research<\/a>).<\/p>\n This will help you better prioritize the work with product managers for the payback sprints or the backlog.<\/p>\n Once you\u2019ve revealed all the debt, you must prioritize so that it can be addressed in realistic stages.<\/p>\n How big is the issue? Is it keeping users from doing their work? Is it creating a safety or security risk? Is it causing a potential customer to turn around and look to a competitor\u2019s product?<\/p>\n As explained in the free guide Eliminate UX Gaps In Your Product<\/a> I wrote with UXPin<\/a>, these are all relatively severe effects that suggest the issue is a high priority.<\/p>\n But don\u2019t just consider the negatives. How big an improvement will the user see? Will the improvement save hours of time in the course of a month? Will it reduce errors? If so, it may be worthy of high prioritization, even if it isn\u2019t currently considered to be a big problem.<\/p>\n If you have a lot of products, you may consider employing a UX Maturity Model<\/a> as the basis for prioritization.<\/p>\n How long is it going to take to fix?<\/p>\n If all you have to do is tweak the CSS, you might slip it into the next build. On the other hand, if it\u2019s going to require a significant amount of development or will have to be thoroughly regression tested, it may make sense to hold off until it can be resolved with other issues requiring similar treatment.<\/p>\n Who will be tasked with addressing the issue?<\/p>\n If it falls primarily on the UX team, and they currently have a light workload, it may be given a high priority. If it requires the attention of a specific developer who is already assigned to other high-priority work, then it will have to wait.<\/p>\n After prioritizing your debt, the next step is to work with product management to get it into your release schedule.<\/p>\n Agile is so popular these days that it seems like any process that isn\u2019t Agile is labeled \u201cwaterfall.\u201d I find that to be a bit dismissive. There are degrees of being Agile, and you can have an effective, iterative process that doesn\u2019t involve stories, scrums, and sprints.<\/p>\n For our purposes, however, I\u2019ll address all non-Agile processes at once. Then I\u2019ll make suggestions for Agile teams.<\/p>\n Your work is likely planned based on a release cycle. Your organization decides what will go into the next release based on criteria such as how long the development effort will be; how badly a feature is needed by customers; what will sell; what bugs exist and how bad they are; and so forth.<\/p>\n I recommend handling UX debt issues as bugs. The real benefit of this approach is that debt items can be entered and tracked using the same tools and business processes as bugs. This will ensure that they get reviewed and treated equally. A representative from the UX team on the issue review board should prioritize items, ensuring that usability issues get the full weight they deserve.<\/p>\n Ideally, a representative from the UX team will also work closely with product management when releases are scheduled.<\/p>\n When a particular part of the application is being scheduled for work, check it for UX debt. Would it add much effort to address the debt at the same time? Often, there will be savings simply because the code is already being updated by developers. Even if it\u2019s a low-priority item, take advantage of the opportunity to pay down some debt.<\/p>\n A company that employs a healthy Agile process shouldn\u2019t have any problem prioritizing debt with other types of work, assigning it story points, and fitting it into sprints.<\/p>\n Find the rhythm<\/strong><\/p>\n In my own experience, however, Agile has been embraced as a way to get more work done faster, rather than as a method of iterative improvement.<\/p>\n In such situations, you may have a harder time scheduling UX debt because (as management sees it) there\u2019s not enough time to fit in everything they aim to wrap up, so there certainly isn\u2019t time for all those trivial corrections you\u2019re asking for.<\/p>\n Photo credit: Laura Kershaw<\/a>. Design process at Kaplan Test Prep<\/a> for UX Design in Action<\/a>.<\/p>\n If you find yourself in such an environment, your goal should be to find a rhythm for addressing debt.<\/p>\n Propose a certain number of story points per sprint (or every other sprint). Or, perhaps a sprint could be devoted to addressing debt at some regular interval (payback sprint). This should be done at least until the backlog of historic debt\u2014your debt inventory\u2014has been handled. Then it should become easier to keep up with new debt that crops up without that regular schedule.<\/p>\n Try a \u201cCheese Day\u201d<\/strong><\/p>\n For even tighter schedules, consider holding a Cheese Day<\/a> to knock out as much debt as possible. Management is almost always receptive to a one-day workshop every 60 days where you knock many items off the debt list.<\/p>\n The following procedure suggested by Roy Man<\/a> is both realistic and effective:<\/p>\n Photo credit: Joe Natoli<\/a><\/p>\n Most importantly, we address UX debt through collaboration.<\/p>\n UX debt should be understood as the responsibility of the entire organization\u2014not just the UX group. It takes a good working relationship with your entire team to ensure that UX debt is given the attention it deserves.<\/p>\n And of course, the best way to eliminate UX debt is always avoiding it in the first place.<\/p>\n If you found this article useful, get more advice by downloading the free e-book <\/em>Eliminate UX Gaps In Your Products<\/em><\/a>. <\/em><\/p>\n\n
Step 2: Prioritization<\/strong><\/h2>\n
Severity & Impact<\/strong><\/h3>\n
Estimated Time to Address<\/strong><\/h3>\n
Responsible Party<\/strong><\/h3>\n
Step 3: Schedule<\/strong><\/h2>\n
If You Aren\u2019t Agile<\/strong><\/h3>\n
If You Are Agile<\/strong><\/h3>\n
![\"image01\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/07\/image01-400x300.jpg\")
<\/p>\n\n
\n
![\"image00\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/07\/image00-315x300.jpg\")
<\/p>\n\n
Conclusion<\/strong><\/h2>\n
![\"image02\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/07\/image02-573x300.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"