As the Project Manager, a couple of days ago I decided to try to do what I expected our typical user would do with our software. The goal was to take a paper form that contained all the necessary information, and enter the information from that form into our application.
My results were less than satisfactory and in a way that should have been easy to discover by anyone who tried the experiment I tried.
The form had several pieces of information entered as numeric codes. Our application only had the plain text of the matching options for those codes. Without a key, a user would have no way of knowing which plain text option to select. With a key, a user would have to continually cross-reference between the form and the key to select the correct option. At the very least, this solution was error prone. At the most, this solution was unbearably complicated.
Why didn’t the Business Analyst figure this out? The BA took the requirements from our Subject Matter Expert and discussed options, but never actually walked through the process beginning with, “The user receives a form.”
Why didn’t the testers figure this out? The testers were busy verifying the requirements were met. There was no requirement about figuring out what codes on the form went with what plain text options in our application.
Why did I figure this out? I asked myself, What Would my User Do? If my user were like me, he/she would call the help desk and complain. Loudly!
All along the development process, the development team needs to ask that question, WWUD? Assume a user’s level of computer sophistication. Assume they won’t be power users. Assume the worst and develop the best.
You’ll save a lot of time and money, and you’ll have a much happier end-user for your product.