When in discussion with the ESPHome ecosystem developer maintainers from the OHF recently, we expressed the need to understand how to define a 'usability bug'.
Many users, often our power users that have access and availability to express, communicate, define a 'bug' (from a technical point of view) and then also potentially fix their own bug, are often describing a 'usability bug' from their own personal use-case perspective (or from a limited user base often made up of other power users). They of course often describe functional/technical bugs too and these are very welcome.
Usability bugs are more difficult since they require broad usability benefit/appeal across as many plausible and possible user types. Assessing this can be difficult as gathering confirmation can only be done if we have clear access to archetypes if these user types or a good enough established understanding of them from desk research or previous research/knowledge on behalf of the individual solving the usability bug.
Rough definition of a usability bug
A usability bug is distinct from a functional or technical bug in so much that it does not describe something that does not execute or function as intended or expected, but describes a desired behaviour, process, experience or interface visual from the perspective of either an individual user that requires agreement and consensus from other types of users (or knowledgable spokes-people for these users).
A usability bug must:
- Describe existing usability, behaviour e.g. 'When I do X, Y happens...' or 'On [interface] I am looking for [something] that does not currently exist and/or is in a place i do not expect/know it will be]'. and what is impacted by the usability bug e.g. 'I cannot do X effectively' or 'There is no possible way to do X'. Screen shots and screen recordings help people see what your describing without having your exact environment.
- Describe the desired behaviour/usability and describes what you wand/need to be able to achieve. Not just 'add a button here' more like 'Being able to do X allows me to perform the essential function faster in complex configurations' etc.
- Leave the usability bug open to other possible solutions or user insight. A usability bug is only a usability bug if it is as broadly applicable across user types as a bug as possible. (otherwise we risk you usability bug 'fix' becoming a usability bug for another type of user.
In order to apply a severity rating to a usability bug we must collect the above information, otherwise we risk assessing usability bugs inaccurately.
This is Eriol's first attempt at defining and putting some 'rails' around a usability bug description/process. This should help us be more accurate but not at the cost of efficiency as we test this out.
This issue 100% needs more usability experts to add their thoughts and definitions. Please add in comments and an aggregated definition can be formed! 🙇 🙏
When in discussion with the ESPHome ecosystem developer maintainers from the OHF recently, we expressed the need to understand how to define a 'usability bug'.
Many users, often our power users that have access and availability to express, communicate, define a 'bug' (from a technical point of view) and then also potentially fix their own bug, are often describing a 'usability bug' from their own personal use-case perspective (or from a limited user base often made up of other power users). They of course often describe functional/technical bugs too and these are very welcome.
Usability bugs are more difficult since they require broad usability benefit/appeal across as many plausible and possible user types. Assessing this can be difficult as gathering confirmation can only be done if we have clear access to archetypes if these user types or a good enough established understanding of them from desk research or previous research/knowledge on behalf of the individual solving the usability bug.
Rough definition of a usability bug
A usability bug is distinct from a functional or technical bug in so much that it does not describe something that does not execute or function as intended or expected, but describes a desired behaviour, process, experience or interface visual from the perspective of either an individual user that requires agreement and consensus from other types of users (or knowledgable spokes-people for these users).
A usability bug must:
In order to apply a severity rating to a usability bug we must collect the above information, otherwise we risk assessing usability bugs inaccurately.
This is Eriol's first attempt at defining and putting some 'rails' around a usability bug description/process. This should help us be more accurate but not at the cost of efficiency as we test this out.
This issue 100% needs more usability experts to add their thoughts and definitions. Please add in comments and an aggregated definition can be formed! 🙇 🙏