Early on in my career I worked to build a data entry application that was meant to replace a legacy system. One of the key numbers for that application was 60: That’s how many forms a data entry operator was meant to key in per minute in the system.
The business wasn’t asking for huge improvements; they just wanted it to match their existing system, and would look for efficiency gains elsewhere.
We had every confidence that our application would meet this target, and why not? After all, our application was replacing a system that was over ten years old. When we went into UAT (User Acceptance Testing) everyone was shocked by the fact that their operators could barely squeeze out 40 forms a minute from our system.
At the time – it was the most embarrassing moment of my career – after hundreds of hours, and thousands of dollars we came up with a system that under – performed the legacy one by miles.
We interviewed the users, tweaked the system, and in the end re-engineered the process to exceed their existing production levels. This left quite an impression on me, and for a long time I was of the opinion that in order to gain efficiencies you need to re-engineer processes and do things differently. Simply replicating existing processes, and hoping that better technology leads you to greater productivity gains doesn’t work in the real world.
I still largely believe in this, but over the years I have also seen applications getting rejected by end users because they deem it ‘unusable’, ‘not intuitive enough’ or simply ‘too hard’.
I am sure a lot of you have experienced this, and when this happens it is hard to pin point what to fix. There is usually a laundry list of items that you have to address, and while you are working through the list – some exasperated developer will scream out why you didn’t ask for all this in the first place!
The reality however is that when requirements are defined, and low level implementation and user experience developed – there is always a tendency to sacrifice the best user experience for quicker development, and very often the product owner, or the business stakeholders don’t press for the ideal scenario if what they can get seems good enough.
Image Credit: Tim Lumley
A good example of this that comes to mind is formatting a currency field with decimals, and commas, but formatting the field while the user is inputting the value, and not when you tab out. Here is an example of a site that inserts commas while you are typing and here’s another one which does it when you tab out. Try entering 5 million in both sites, and see how different the user experience is.
In practical terms – when you are defining requirements – it is just unfair to count on the product owner or the business stakeholder to define them to such a level of detail where they define that the currency gets formatted as you are typing it. They probably have much bigger fish to fry at the moment. However, the development team implementing can and should do their best to offer the best experience even if it means extra effort from them.
Practically though, teams are likely to take the slightly easier path if the experience seems good enough, and there is one tiny compromise after another, and in the end the application suffers a death by a thousand cuts – all of which seemed innocuous when inflicted on their own, but the sum was far too overwhelming to survive.