As Bill Gates once said 'Your most unhappy customers are your greatest source of learning'. Although I agree with this statement and have definitely had opportunities in my career to improve a product based on feedback from an unhappy customer, the idea behind agile development is to create an early feedback loop rather than waiting until the production release to find out if you've missed the mark.
One way that the goal of creating an early feedback loop is achieved within Scrum is through the traditional sprint demo. By demonstrating software that is in development to the product owner or stakeholders on a project, there is an opportunity to gather feedback and make changes prior to release. Sprint demos are an excellent way to make sure that the development team is delivering the right features. However, consider the following scenario: suppose the product owner/primary stakeholder on the project is a bit uncertain about the best way to give the end users what they want. After all, the product owner must serve as the proxy and ultimate decision-maker for what could be a very large user community. Perhaps the user community even consists of users of varying opinions on how the application should work or what features are most important. All the while, the product owner and the development team are under pressure to deliver an intuitive and useful product that will hopefully gain widespread acceptance within the user community.
One great way to get an early read on the design of your application is through User Experience Testing, often referred to as UET. The idea behind UET is to allow a subset of users to have an opportunity to interact with a beta version of the software application while under the observation of the development team. While the term 'observation' may cause you to think of a psychological experiment, the term is not misused here. A typical UET calls for a one-to-one relationship between observers and test subjects.
The idea behind it is that the observer does not guide or influence the test subject in any way. Rather, the observer's job is to simply observe and take notes on how the user interacts with the application. For example, the observer might notice that the test subject hesitated for 30 seconds prior to clicking the 'Submit' button? Was he or she unsure about the workflow? The observer may also notice pain points or areas of frustration. Perhaps, the user will even speak up about aspects of the workflow which are not intuitive.
The best thing about UET is that the only additional resource required beyond what you have already planned to devote to a successful sprint is a small sample group of end users who are willing to give up approximately an hour of their time. Here are some of the other things that you will need to ensure a successful User Experience Test once you have lined up your test subjects:
- A moderator with an introduction that outlines the ground rules for the UET. It is important to make the users/test subjects feel at ease by emphasizing that you are not testing them. Make it clear that you are here to test the design of the application. It is also important to make sure that the user does not withhold feedback for fear of insulting the design or hurting someone's feeling. Explain that it is a work in progress and subject to change.
- A test script or scripts. Not to be confused with a traditional step by step functional test case, the idea here is to outline a broad user task for the subject to accomplish. For example, your test case might say 'use the application to enter all of your monthly expenses and, after reviewing, submit as final'. Notice, you don't say things like 'enter a value in the expense field, click 'Save', click 'Submit'. Again, you don't want to guide the user.
- A large enough room to keep test subjects separated. Just as you don't want the observer to guide the user, you also want to avoid test subjects influencing one another with their comments and experiences. Other options are to use a different room for each test subject or schedule test subjects to come to the UET at different times.
- The observer should also be provided with an observation checklist. The checklist lists important hot points within the workflow which the test subject will encounter. For example, the observer may check off items in the list as the user completes different tasks along with comments related to the action, i.e. 'Clicked Submit Button, Clicked Reset All'.
- Finally, I would also advise providing the user with an exit questionnaire. This is a list of questions for the test subject to answer rating their experience. Some helpful questions might be 'rate your overall experience on a scale from 1-5' or 'list the two things you liked most about the app' or 'list the two things you liked least about the app'.
Before closing, I suppose I should mention one other important thing that you will need. If you are already doing agile software development, this goes without saying, but you should also have a willingness to learn and to make changes based on what you have learned.
