As a product owner, you should be highly aware that usability will cost you money, regardless if you ignore it or not.
But let us start with the classical observation made by Anna, a product owner. She knows her product well and has observed that users cope with bugs that make the system "unpredictable". When she asks the users what they think, they say it is annoying but "take it for granted". Hum.
I have heard other, similar stories about users coping with ridicolously bad user interfaces.
My view is that users will stand on their head if they have to, to get their job done. So they cope with it.
This would fine if it were not for another aspect, they make mistakes due to the low usability. Making mistakes, depending on the system, may kill people (e.g. an X-Ray machine, airplane), or just slow users down.
I find it interesting that users not always complain about, or even mention, how awkward the system is. Instead they blame themselves for not remembering that the Return key is different from the Enter key, to take an example.
So, we can’t trust on getting feedback from the users, despite us doing really bad in the usability department. What shall we do, then?
As a product owner, I am responsible for prioritizing the quality attributes of the product.
As an architect, I am responsible for delivering those qualitites. Well, it is the team that is responsible and their are no architects in Scrum since all they do is sit in ivory towers and philosophise. Not. People have different skills, don’t forget. Oops, a rant.
You have two options, either ignore or score. If you ignore it, in the worst case people get killed or your product fails to get market acceptance. No business, no money. But if the risks were that high you wouldn’t even consider ignoring it, right?
It is worse when your users belong to the same organisation and there is hardly any comptetion that can kill you. Worst case, people see you as mediocre. Not!
Even then there is money to make. So consider the other option: score.
To score, you have to commit. It will take time, money and focus or you might as well skip it.
However, the bottom line is that if you look, there is money to find from usability. There may be a yearn for more functions but at some point, you have enough functions to satisfy most of your users need. They may have to use paper and pen in some less frequent cases, but most of the time they will do fine with what the system got.
Against that yearn for functions, you should weigh the possibilty of making the users life easier with less mistakes and better flow in their work. They like flow, too, you know.
So start from where you can go. If the mistakes were less than ten percent of today, how much would that increase the value of the product?
To score that value, where do you find the changes that take your product?
I am no expert in the field, but I know that if you could measure how many mistakes users do, that can be great. Also, you could video tape the users in daily action. The third option is to observe a user’s actions when asked to perform a task. Especially good when your homing in on a specific problem area.
So, what will it be – ignore or score?
When I started out in our line of industry (general IT), I trained people using standard office applications. What was hardest was when you realized that you couldn’t solve the problem because the system was faulty for their needs.
The only way then was being honest: they were using the wrong application for their needs. And this was of course sad. The problem was mostly prodominent in Microsoft Excel. Not that it’s a bad program but because many users find this being the ultimate program and expect it to solve everything. And all the time.
But this problem is why I love working with software development in the product owner role: you can actually do something about it. You can change the system.
And this is also the case when you come to usability. Per points to the difference between ENTER and RETURN as an example. We all have them. One of my favorites where the system where you sent the order by pressing ESC. The reason was that they felt that the key was so good placed on the key board. But you can image which problems this posted. First for new users and then for users being used to sending information using ESC: how many times do you think they discarded e-mails by mistake.
Working with agile methodologies we have the advantage that we can prioritize small stuff and large stuff. By estimating relativly you can point to stakeholders that you can fix all those small irritations for the same cost as one biggy. And by calculating loss of time due to stupid usability, you can calculate business value.
Take your developers out to see real users: I remember a devloper who watched a user using a functionality and he was embarresed that a simple task was made so diffilcult as a result of stuff he programmed. This of course only applies to developers with a workman’s pride.
Another advice is to give the small stuff a budget in every sprint. This way you can be real agile and lessen the value stream for the easy stuff.
And of course: use the demo for discussions on usability. I use to give the developers the last half day after the demo "free" so they can do what they feel fit. And since the time is time boxed they do stuff which has high visibility and low cost.