2

What is your advice on creating titles for User Experience and usability bugs?

We are using a spreadsheet to report and track software bugs, including UX bugs. We have divided the bugs into the following categories:

  • Functional Bugs
  • Visual Bugs
  • Usability Suggestions

So far, most of the issues related to the flow of the app and interactions thereof have been categorized as Functional. One of the feature suggestions or usability improvement suggestions have been put under the Usability Suggestion, but it is somehow hard to make a clear distinction between categories.

I have read some bug report samples but they are mostly related to back-end and technical issues and little issues related to interaction, UX and usability.

I wanted to ask for your advice and ask if you could provide me with various examples.

3

I'll explain the way I like to frame User Experience and Usability Bugs, hope it is useful.

First of all, I like to group all bugs, undesired system responses or behavior into technical or design debt. Some issues might fall into both, but they are equally debt and should be eliminated promptly because additional rework is very costly. If we only fix an instance of an issue or bug, it is simple, but the debt is not eliminated. For that reason, I take a different approach to documenting debt in general.

Start with outcomes

The goal of reporting any bug is that they will be fixed, once. To ensure this happens, I need to be able to understand not only what is wrong but also why it is wrong and the context where this is happening.

So now let's imagine you have identified a bug:

Users see a warning label on the shopping cart icon while doing the checkout of an item.

An outcome for solving this would be:

Minimize [distractions] by [system warnings] when [doing the checkout of an item]

In this case, the outcome has a direction (minimize) a unit of measure (distractions), an object of control (system warnings) and a context (when doing checkout).

So now I can categorize this into Distractions (design debt) and System Warnings (technical debt).

Keep in mind that what we choose to measure regarding the user experience will depend on the nature of our product or service, but I've found almost anything will fall into intuitive categories once we apply the outcome formula.

UPDATE:

Separating solution from the reported issue

I'd personally find it difficult to include the solution in the title because I believe it's complicated to know what exactly will solve the issue beforehand. I prefer to separate my thought process into being problem-aware and solution-aware.

When reporting the issue I can only be problem-aware, this is the limitation I'm working with, so instead, I will describe the measurement of success. What will success look like when I close this ticket and when will I know that?

To get the problem from an issue description, I like to ask myself why this is a problem and iterate until I get as close as I can to the root cause of the problem.

So for your example:

Clicking on X closes the whole page.

Why is this a problem?

Users don't expect the whole page to close when they click X.

Why is this a problem?

Unexpected response when clicking X is preventing users from completing [goal].

Which will be reported as:

Problem

Unexpected response when [clicking X] is preventing users from completing [goal].

Measure of Success

A week after closing this ticket, we have 0 users abandoning [goal] due to an unexpected response from clicking on X.

  • Thank you! We used to report bugs with solutions inside the title. Sometimes the solution is not necessarily good or efficient. So we tried to separate the [issue] from our suggested [solution] in the title and tried to keep the title to only the issue and its context. for example: Title:Clicking on X closes the whole page. Solution: Ask users if they want to close the window. So while I like the approach you explained I would be happy to hear your thoughts on the matter of separating Solution from the Issue in the title. – Ali Aug 27 '18 at 16:09
  • @ali I have updated my answer to include a bit more about how I go about separating the solution from issue reporting. I hope this is what you meant. Good luck! – ghislaineguerin Aug 29 '18 at 7:57
0

Most UX bugs are gaps between the users knowledge and how the thing actually works.

So if the user can learn how it works and say "ah" ( followed probably by "well that's stupid, why is it designed like this !"

Then it's a usability bug.

The gap is what Don Norman is describing in this well known diagram

enter image description here

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.