How to Conduct Usability Testing in Validation of a Business Analysis Project
Validation testing as part of the implementation phase of your business analysis project is your chance to review your project deliverables to make sure they
Meet the project objectives or requirements and the overall needs of the organization
Are within the project scope
Conform to organizational standards and strategies
When you get to the phases that require you to perform validation testing, you want to start with a usability test. After you complete this, you also want to conduct a user acceptance test, and a post-implementation user assessment.
Usability testing occurs in the design phase. Its purpose is to show you and the project team how well the users can really use the system. You can follow ten usability heuristics to build proper usability into your design. (Heuristics is basically a fancy word for a hands-on learning process in which users educate themselves as they go through the program.)
Consider these items more as rules of thumb than documented guidelines. The following list is based on Jakob Nielsen’s ten usability heuristics:
Make the system status visible. Let users know where they are within the program, keep them informed about what’s going on, and give them feedback in a reasonable amount of time. A good example is the status bar that shows feedback and progress as you’re downloading a program.
How to comply: Make sure the solution continually gives the user feedback.
Speak in the user’s terms. Make sure the system uses the language users are familiar with; avoid system-oriented terms. Think of how Microsoft Office uses terms like file and folder rather than electronic artifact and directory, or how e-shopping sites still tell you to add your product into your shopping cart, just like in the real world.
How to comply: When designing a system, think about how your user would accomplish a task in the real world, and follow that convention.
Make backtracking easy. When users trigger an unwanted system response, help them by providing a clearly marked way to get out. Also give them a chance for a do-over by including redo functions.
How to comply: Follow Microsoft’s convention of including an undo button. Place exits in the upper-right of the screen, which has become a standard convention.
Be consistent. Use the same terms consistently. Don’t make users guess whether different words, situations, or actions mean the same thing. For example, don’t interchange terms such as save and store.
How to comply: Pick one term from interchangeable options and stick with it. Make sure the term is clearly defined in your glossary and help texts.
Prevent errors. Build in processes that stop errors from happening in the first place. Instead of merely informing a user she has misspelled the state she’s shipping goods to, for example, give her a defined list from which to choose. Shipping company UPS even validates (there’s that word again) the address you’ve entered to make sure it’s a valid address.
How to comply: Build in processes that validate information and don’t allow incorrect information to come into the system.
Use recognition rather than recall. Don’t make the user memorize a bunch of stuff; make objects, actions, and options visible. Think of how the Microsoft Office suite of products uses icons that are always displayed and shortcut menus that pop up with help for shortcut keys.
How to comply: Keep the most-used tasks and processes in front of the user instead of having her memorize how to get to them; don’t bury processes multiple mouse-clicks deep. If you see users with lots of navigation sticky notes attached to their monitors, that may be a clue that the solution violates this rule.
Don’t slow down the expert users. After time with the system, a user often becomes an expert user. Give these users ways to accelerate their work by allowing them to tailor frequent actions.
How to comply: Let users program macros in the system to customize their work and perform it faster; give them shortcuts they can access when they become experts.
Display a simple user interface. Show only the information needed at that time. For all the complex things Google does, the main screen is a minimalist design: just one text box and two buttons.
How to comply: Show only the information that’s necessary to accomplish a particular transaction. If it’s more than one page long, think about splitting it up into multiple steps.
Make help functions easily accessible. Users need to know how to access good help when they need it. Make sure errors are expressed in plain language that indicates what triggered the error and how users can correct it.
How to comply: Tell users what they did wrong and how they can self-correct. Suppose someone signs up online for a wine-of-the-month club and chooses a state that doesn’t allow wine shipments. Instead of the error box saying, You’ve made an invalid selection, please try again, it should state, You’ve chosen a state that doesn’t allow incoming shipments of wine. Please choose another state or select a non-alcoholic product.
Using software developer error codes may help the developer when performing unit testing, but they’re of little to no value for the user.
For instance, the error message You’ve triggered an ORA-6439 Error. Contact System Administrator means nothing to an end-user and can even create additional confusion. Telling her instead that You’ve entered your flight dates/times out of order. Please change your dates so you leave before you return not only scores you points because you helped her out but also prevents a call to your company’s customer service department.
In the early stages of your project, define what characteristics your users have, including skill level, previous experience, and education level. During usability testing, select testers who match your demographics to work through the system to see whether it has good usability among your target audience.