An implicit bug is existing functionality in software that is operating as designed or required, but it feels like a bug.
I.e. functionality is operating fine, but it’s operating in such a way that it is causing (unintended) user pain.
(An implicit bug is different to an explicit bug, where the functionality is simply not working as designed or required).
The definition is made grey by opinions on the functionality being subjective. Some users may believe the functionality or specific feature is working for them, while others may dislike it.
The functionality may be:
- Different to how a specific user thinks should be operating, or
- Difficult to understand (placing a cognitive load on the user – i.e. “making a user think”), or
- Creating “noise” on a page, or
- Violating established or learned usage patterns etc.
For example, you want to do Y by clicking here, when you actually need to do Z by swiping there. (You still end up with the same outcome, but how you would like to do it differs)
Generally, most implicit bugs can be solved by a user experience intervention.
Extra – how to communicate implicit bug
Three bits of info
- What did I do to get there (what steps did I take)
- What should happen (my expected behaviour)
- What happened instead
Adding screenshots is generally very helpful
Note on implicit bugs
For a general overview of different types of users intersecting with bugs, please see this article. It segments user issues into two categories. It also unpacks how different tech user personas interact with each issue.
It’s based on hard-won experience 🙂
