Resolving Tool UX Debt

Written By Robin-Yann Storm

It all starts with prioritizing correctly. A continual problem I have seen over the years is companies measuring the priority of their tools in a programming and functionality centric way. The priority for a feature is usually a P1 or P0 for blockers. That is for functionality that is critical for the work to be completed. Then comes P2 priority which are nice to haves, then P3’s, P4’s, and P5’s for work that is neat but users can functionally do without. An idea that I have often seen executed is to include a small percentage of those P3-to-P5’s in the work schedule, as if they are critical, so that the tools still get some UX work done on them. Another one I have seen used is to spend a sprint or two only on those lower priority issues.

Even if you do either of those, you are not resolving the underlying problem of improper prioritization, so the bottom issues keep piling up, and the user experience of the toolset suffers more and more over the years. Until a giant rewrite and redesign has to happen, and that takes so much time and effort that it is often pushed out, or causes considerable roadmap juggling. It is then that the debt suddenly needs to be paid in full, instead of it having been paid slowly over time. That one time payment jeopardizes the entire project. The strict prioritization of ‘blockers first’ is a pillar that keeps that debt piling up. This is because it provides a very easy and quick way to end any conversation about prioritization. Which means that in conversations of prioritization, the question that keeps being raised is the usual one:

"Can you argue this is a blocker?”

At face value that question sounds like it makes sense, but just because something is functional does not mean it is ready for users. For tools UX, you have to look at the holistic experience for the user. To take that to the eventual extreme: Users can technically do all their work in a terminal, console, shell, or other command line interface. It is possible for them, so any non-functionality work, even user interface (UI) work, is not a blocker. It is a strange extreme, but technically true.

We may as well ask all programmers to only ever write all code in assembly. It is technically possible if they work hard enough to do that, so is all other work really a blocker? Of course not, as it would not be a great way of working for most programmers. Just as programming languages, APIs, etc, have been invented to make it easier to write, understand, and work with code, just so have graphic user interfaces (GUIs) been invented to make interacting with software better. Even terminal commands had to be improved so that they had a better user experience, back in the day. And by back in the day I mean Don Norman wrote about this in 1981. (Yes, that Don Norman. The author of ‘The Design of Everyday Things.’). He wrote that article about the user experience of Unix command lines 42 years ago as of this year. So the problems I am writing about here today are not new, or surprising. Yet these issues keep happening. You are still dealing with terribly named Git commands, trying to figure out what they do and why, like you’re working in 1981. Billions more transistors aren’t going to help you. A better user experience will.

So, you cannot argue the time spent working on improved user interfaces are blockers, but this does depend on your target audience. You can argue your target audience requires a good user interface, as otherwise they cannot work at all. If you are making tools for a ‘technical’ audience though, that argument is usually very easily overruled by anyone else that is technical. “Our users should be able to do this as-is! They aren’t dumb!” will be thought, or said. This is especially the case if the tools are being built for an in-house audience. It is a bad way of thinking, as that ‘technical’ audience should also not have to deal with tools that have a bad user experience. Not in 1981, and not today.

Sadly it is very easy to fall into the argument of whether something is a blocker or not. If the question is answered at face value, it cuts off the conversation quickly. Decision made, and moved on. It trends towards producing technically functional tools, without a good user experience. Functionality is required, but super powerful functionality on its own is not enough for good tools. You will quickly end up with what Michael Pavlovich has coined as “Rocket Powered Shit Shovelling“. Inane, boring, and confusing work that does produce great results at the end, but underutilizes and frustrates users. Even worse, the cost of such incredibly powerful tools with a bad user experience is unhappy users. Someone who is having a bad and frustrating day is much less likely to be creative, which in turn affects project quality, and continual bad user experiences can increase company churn over time. How costly is it to lose experienced colleagues? To have difficult and long onboarding times? To have unhappy employees? If you are using the in-house tools for 8 or more hours a day, it becomes a death by a thousand cuts.

So do not argue ‘blocking’, if it is the only conclusive metric being asked about. Instead, argue the users' well being. How many users are pained by a feature or workflow not being easy to use? How many smart and expensive folks are doing menial tasks? Do we really have seniors and principals having to do boring work that takes ages? Do we have pages and pages of documentation to explain all the terminal commands, eating up our users’ time, instead of having a UI with a clear workflow that shows how it works in the blink of an eye? Where are our users frustrated, and what daily issues are they unaware of due to the constant slog they have to deal with? What do they accept as being totally fine, even though it costs way too much time and energy? Those kinds of questions need to be just as much a part of the prioritization as whether a feature unblocks a workflow.

This is not easy, as you cannot readily measure things such as ‘happiness’. If you give users a survey, they will almost always ask for faster horses, while what they really need is a car. It is on the tool UX designer to find out what the users are really lacking. Not to prescribe that to them, but to find out with them and for them.

Happiness is also relative: Will you be as happy paying $100 a night for a 2 star hotel, as you would be for a 5 star hotel? The value proposition here is different, and the resulting satisfaction will be different too. Furthermore: Users don’t know what they don’t know. How can they tell you what they are lacking, or what workflows are necessary, if none of them have a full overview of the entire holistic view of the toolset and its workflows? You should be getting that information by observing them.

Guesses & Data

There is always some guesswork associated with prioritization. Just as a programmer cannot factually know when a feature would be fully built and completed, a designer cannot factually know how happy or unhappy a user will be. The only way to know for sure is to build it, and to put it in front of a user to see what they do. The guessing is not bad, as just like you can estimate the technical work through previous experience and current observations, you can estimate the user experience issues through previous experience and current observations. Some of those guesses will be correct, some of them will not be. That is why iteration exists. Nobody builds the perfect thing right away, and it is much worse to forever be discussing the ‘what if’ than building it to see if you are right.

Having data that supports those gusses is good, but should not be a requirement. Just as you would trust a programmers’ expertise on their estimation of when they can complete the work, a designers’ expertise needs to be taken seriously as well. Include the user experience in the prioritization metrics, and do not just think about functionality blockers alone. Both are needed.

Getting that data has many forms. There are surveys, emails, questionnaires, user interviews, etc. Often, the best thing to do is the most basic: Go sit behind someone and watch them work. See what they do. What is annoying them? What is boring them? What is frustrating them? Often times users have used the tools for so long that they have forgotten about the weird buttons, warnings, and errors that they immediately dismiss out of habit. So they cannot even tell you about those issues in some survey, or a user interview, as they have no more recollection of them. If you watch them though, you will very quickly understand what they do and do not spend time on. Use that for prioritization discussions. Not as the only metric, but as an additional metric. Have your prioritization calculation set in such a way that if the annoyance, time spent, or churn is so high because of a certain feature, that it is possible for that feature to become a P0 or P1 even if right now a million users are doing that exact workflow already. Even when it is not a blocking issue. Even when it is proven to be possible. Very annoying, but possible.

Two small examples

Your users (or customers, if you’d like) are bound by having to get things done. So they will cope with having issues in their daily workflow. Depending on how busy they are, they also will not submit tickets or feature requests to resolve their problems. This is because their full time job is a full time job. Their most basic objective is to get their own work done, not to help improve the tools they use. Creating tickets or requests can be a huge time sink for users, especially if they have to type out all the detailed reproduction steps by hand. Because of this, users will often simply keep dealing with the issues at hand. Until it becomes too much and they leave entirely, for a new tool that is sometimes better, or sometimes has issues in slightly different areas that simply bother them less.

Annoyances that build up over time can be very small things, like a tool doing a ‘yeet’, as Freya describes here:

You have probably also noticed something like that happening in Photoshop, and other tools & editors. It is still possible to achieve the work when such a ‘yeet’ happens, but it is much more annoying to do so. Especially when it happens often, and is part of a core workflow. It is, however, a technically unblocked core workflow. So for scheduling and priority purposes, if the usual question of ‘Is this a blocker?’ is applied, it will not get fixed.

Another neat one that I saw recently is Zbrush not having a regular save button.

I had never used Zbrush myself in a professional production setting, so the reactions of praise underneath that tweet really grabbed my attention. There was also the surprise by others that a save button did not exist yet. At the end of the thread George says they submitted a feature request. It was submitted in October 2022, and it was resolved soon after in January 2023. George tweeted about that too, with a little tongue in cheek:

Which is a great turnaround time by Pixologic!

It’s strange to think that apparently Zbrush did not have a direct save button. And that someone made a plugin so that they could save in Zbrush. There were multiple other ways to save, and various things you could save, but in the file menu it only had ‘Save as’. You can definitely argue the ‘fix’ to add a save button was not a ‘blocker’. Users could save! It was possible, albeit not optimal.

This second example shows us that you can just as easily argue ‘If everyone used the software, it must not have been a big deal!’, as you can argue ‘People are forced to use the software they can, or what is licensed in their company, so they cope with whatever is thrown at them and have no time to request features.’. Just because you do not hear about workflow issues, does not mean they do not exist. To find out the underlying issues, it is also important to keep asking ‘Why, why, why, why, why?’. Users have to work and get things done. Users taking time out of their day to tell you exactly what is wrong, with the required reproducible detail, is a rare occurrence. Finding out what is wrong falls on the tool UX designer to figure out.

There are many more examples I could add here, but instead I would like you to think of your own personal workflows. What small issues have you noticed in the tools you use on a daily basis? Which issues do you take for granted, and which ones have you started glossing over? Has someone seen you work with those tools, so they can tell you the strange things you seem to be doing, that you did not know about? What small things do not block your workflow, but do make it very annoying at times?

The underlying issue

What is causing the ‘blocker question’ to be asked though? It is not always malicious. It is usually because there is not enough time to do all the work, and so cuts have to be made into the feature list. Simply discussing what blocks workflow will lead us down a path of more UX debt though. It will lead to functionality that technically functions, but has a terrible user experience. It will pass a technical smoke test, but not a smell test by the user.

That does not mean we can sit still. If there is not enough time to do all the work, we have to do something about that. We cannot just keep pretending that all the work will get completed. At that moment, you may have to make a guessed decision as best as you can. After that, talk to a producer. They can figure out why there isn’t enough time. Did other features take longer, if so, why? Were estimations incorrect, and how incorrect were they? Did developers transfer teams and is there now a limitation on time, and why? Were the user experience benefits not accounted for in the prioritization of these features? Etc, etc. This is not easy to find out, and a producer can have a full time job chasing these things down, especially if these issues are not continually documented. That is a reason why the job of production exists, because it should not be on a designer or programmer to find out such production issues. The designers and programmers do need to be informed about what caused those issues when conclusions are reached though, so that everyone understand why it happened. Because then they will have more experience, and data, for future guesses.

What are the main takeaways here?

  1. Do not engage in the ‘blocker’ discussion if that is the single metric being used to decide high priority. It is the wrong discussion to have, and it often closes the door on other metrics being considered.

  2. Make sure the prioritization metrics include a good user experience. Otherwise all user interfaces could instead be terminal commands, and all code would be in assembly.

  3. Questionnaires are neat. Interviews are nice. Metrics are useful. However, nothing is better than observing users in their natural workflow, and it is the only way to truly make sure your toolset is used in the way you intended.

  4. Find out why there is no time for feature work, but do not do that yourself if you are not a producer. If you start doing this yourself, you will be expected to keep doing that, and you do not have the time for that next to your regular duties as a designer. That is why a producer is a unique full time role for a different person.

Thank you for reading! If you enjoyed this post, you can find my talks here, and my other posts here. You can also subscribe below to get updates when a new post is published.

Robin-Yann Storm
Previous

Video: What is USD?
Next

Unreal vs Unity: A key UX difference