Over the weekend, I spent some time helping out a friend with a new application they're building. They had just finished a big workflow story, and he wanted to get someone else to take a look and see if there was anything weird about the way the workflow ended up.
I found five bugs. Just plain "whoops it shouldn't do that" bugs. I also found seven places in which I had to ask for help figuring out the right thing to do. In each of those seven cases, the system was doing what the devs had intended it to do; there was no bug there. BUT there was training required.
Asking for an explanation is a smell.
We talk about code smells, and call things like long methods or excessive imports or even comments "smells". This is a usability smell. And just like a code smell, it's an indication that something isn't as apparent as it could be.
Sometimes we don't fix code smells. We know they're present, but we choose not to fix them, either because we don't have time, or because there are more important things to do. Sometimes we don't fix code smells because we're getting a lot of value out of the code as is and that is more important than the smell. The default behavior, though, is that we should fix code smells, and it takes a really good argument to change that.
The same should hold true for usability smells. If an explanation is required for the user to get through something, that's a usability smell. By default, we should fix usability smells. We should live with the smell only if there's a really good argument for NOT fixing the usability smell.
It's easy to get into fixing code smells; we all acknowledge that's just good coding habit. It's time to get into fixing usability smells.