by Ian Hooper
This is a follow-up article to John Schrag’s post on Design Values. The original post described the values we believe contribute to a healthy software design practice. This post looks deeper into the importance of supporting Ease of Use over Ease of Coding.
In my experience at other companies, I have seen that it is common practice to measure productivity in terms of the speed with which a new product or service can be brought to market. In practical terms this means that the faster a developer can complete a functional requirement, the better their efficiency. This provides a strong incentive for all involved in software development to streamline the process as much as possible. Under the constant pressure of tight deadlines, usability is seen as a threat to this "productivity," and as such in situations where the choice between ease of use and ease of coding is uncertain, ease of coding wins out.
However, actual studies have shown again and again how failure to properly consider the user experience can impact the bottom line. For example:
- An insurance company invested $3 million in an application to be used by independent agents to support them in selling this company’s products. However, agents simply refused to use the application, because the interface was "unlearnable and unusable."
- A financial services company had to scrap an application it had developed, when, shortly before implementation, developers doing a User Acceptance test found a fatal flaw in their assumptions about how data would be entered. By this time, it was too late to change the underlying structure, and the application never implemented.
Finding the right balance between efficient programming solutions and a positive user experience is where the challenge lies. There will be many times where these two goals will not come into conflict. When they do, embracing the design value of ease of use over ease of coding can help to resolve the tension between these two worthy principles.
Sometimes it is not immediately apparent which approach will result in the optimal solution for the users. To put it another way, it is not always clear where your efforts as a designer and user advocate will be most valuable. That is where early and iterative design can help identify the areas that will need extra attention or a different programming approach. Try doing some contextual task analysis or running a charrette as a quick way to rapidly spot the areas where the standard coding approach may not be sufficient. After that you can explore solutions by using any of the tools familiar to interaction designers such as card sorting, heuristic evaluation, personas, usability testing, use case scenarios and more.
An example of where we chose ease of use over ease of coding is in a recent product I was working on where we wanted to adopt a particular mode of navigation. The existing navigation scheme was unfamiliar to our target users and initial usability tests showed that this created a barrier to learning. We decided that we could match the navigation style used in Autodesk Revit, a program that our target users would be using. The application was modified to use the middle mouse button to pan the camera when pressed, or orbit the camera when pressed along with the Shift key. We made the new version of our application available to a select few in our target group. Having just implemented Revit-style navigation I was surprised to hear our users say “It’s too bad they don’t just use the same navigation as Revit”!??!
It turns out that our application only registered keystrokes sequentially – it could not detect simultaneous keys. The programmer set the system to orbit when the middle mouse button was pressed following the Shift key. This generally worked, provided you pressed the Shift key first, but if you just hold the mouse button down and toggle between Shift down and Shift up, our system would not recognize the change. This was a common behavior for many Revit users, and so for them, the navigation controls did not appear to be working.
Changing the system to allow for simultaneous keystrokes meant major changes to the application messaging system. The effort was significant, but failure to do this would have meant that our application would not have benefitted from the prior learning they had done on Revit. It may seem funny then that we were pleased with our next test release when nobody commented on the navigation at all. It just worked exactly as they expected.
In the end, we put the effort on the software and not on our users. By choosing ease of use over ease of coding we achieved our goals and created an experience that was natural and pleasing for our customers.