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.
Hey Manshu,
Sounds like a case study from our days in college. Lately I have understood to look at this a little differently . Our implementation is changing equilibrium of process, personnel and system interactions. While system alone might be obsolete with 10 years of legacy in terms of being disconnected from arc of possibility due to 10 years of technological advancement. The process and personnel interaction is going up against a 10 years of heuristic methods , knowledge and comforts. The inertia is huge so your change management should have a clear strategy of scaling against these methods . Mostly every one does divide and rule for this , piece meal rollout , build champion evangelist for your new product, Train the trainer and spread the word.
I am not sure the implementation philosophy was waterfall or did it borrow some things from agile as well. Also did you know this target of 60 forms per minute at centre when you set out to gather requirement. In that case your technical and solution architect should have broken down the solution in sec per form and optimised it.
Mostly this is also reason why we don’t do big bang waterfall model these days. Build , take feedback and develop in sprints kind of steers away from need to make huge architectural adjustment later in the game.
This was over ten years ago, and was done in Waterfall. I don’t know how they could have broken it into a seconds per form and maybe I should have added more detail on this because this seems to be of interest, but the sixty seconds is not just sixty seconds of time on screen, but also pulling the form, the system processing it and running rules etc. So, the screen time that the operator had was probably 45 seconds or so in fact.
I appreciate your comment – specially what you say about the a new system going against 10 years of people interaction. That was also a huge thing at the time, those people could work on the new system with their eyes closed, and there was a somewhat significant learning curve with the new system.