It’s a common phrase I’ve heard uttered by engineers of all types be they usability, systems, software and so on. “We have got to make sure that users don’t shoot themselves in the foot by <insert inane/benign/obscure user operation here>.
What this phrase is really meant to convey is the well-intended effort to prevent a poor user experience by allowing bad things to happen. Prevention is then implemented through protective measures. And while I fully support this philosophy, in fact I count it as one of my major agendas for any product I manage, it’s the implementation of that philosophy that often runs afoul of the very users it is meant to protect.
Here’s a classic case: User scenario requires data entry into a Web form. Like most forms, folks like the ability to copy-paste data directly into the fields. But what happens if a field requires data to be in a specific format or data type? There is the risk that the end user might enter data and receive errors or worse, receive information or results not knowing that the information is faulty or partial.
So what to do?
Well, there are several obvious paths a developer could take. One would be to provide for data validation or field format masking. Another would be to disable entry of invalid information. And yes, I suppose a third option would be to disable copy-paste altogether. All three would prevent a user from unknowingly entering-in invalid data via a copy-paste action. But the first two are the most appropriate while the latter actually takes away a crucial and expected capability from the Web app.
Now I know this is an extreme (yet true) example of “protecting the user” but there are countless other examples where good intentions actually degrade applications and frustrate users. So how do products groups prevent these unintended consequences?
First, make sure your product manager keeps track of any enhancement or change to the behavior of the application. He or she will provide the critical customer use case information that is needed to make the correct choice.
Second, avoid the easy way out. Typically the easiest way to address an issue is often not the best way to address an issue. Simply stated, it is human nature to select a path of less burden than to take-on the burden on behalf of someone else. But making complex things simple is what software should be all about. So take the guesswork and pain from the customer’s hands and hid it for them; even if it means more work for your team.
Lastly, and maybe it’s just this simple: Don’t take away any functionality of your product. Even if the functionality is really through basic functions of 3rd party components (such as the default behavior of browser-based forms). If you always focus on progressing your app, moving it forward with features, then you should usually be on the good side of your customers and end users.
And isn’t that really where we want to be? On the good side?
