Requirements gathering is all about aiming at the right target. It doesn't matter how accurate you are, if you aim at the wrong target, you miss.
Requirements gathering is all about aiming at the right target. It doesn't matter how accurate you are, if you aim at the wrong target, you miss.
More than one reader has pointed out that our recent article "Alternatives To User Requirement Gathering" spent plenty of time illustrating why certain methods were inappropriate for the task of requirement gathering, without actually detailing the correct way to undertake this type of research. In way of compensation, this week we provide some (brief) advice on this absolutely crucial area to successful application or site development.
Requirements gathering is all about aiming at the right target. It doesn't matter how accurate you are, if you aim at the wrong target, you miss. To be usable, an interface must let the people who use the product (users), working in their own physical, social, and cultural environments, accomplish their goals and tasks effectively and efficiently.
Unless you know who is going to use a product, for what purpose, and in what circumstances, you cannot design it effectively or test whether it works well. User and task analysis is designed to identify this information and use it to set design and testing goals and establish measurable success criteria.
The following techniques will be useful for those organisations that wish to undertake some form of requirements gathering. A good programme will combine these techniques in order to provide a well-rounded picture of the needs that must be addressed by an application or site. Of course there are further possibilities, but the three approaches below certainly provide somewhere to start.
As was mentioned in our previous article, interviews can be a dangerous way to evaluate user requirements. However, they do provide an obvious start point and can be an important element of an overall programme if certain approaches are used. Most importantly, focus on discussing how the user works now, in the present, rather than on aspirations and future 'wants'. Interviews should be directed to include discussion of specific incidents, behaviours and tasks that are a part of the job (and sub tasks) that the new application or site will (hopefully) simplify. This information will be useful in pinpointing current difficulties in working practises.
Simply put, contextual enquiry involves the observation of users in their typical work environment. It can also incorporate discussion with users as they perform work tasks, and as such overlaps to some extent with the ethnographic interview detailed above (the two could certainly be both performed during the same site visit). It should be remembered, however, that the primary purpose of observation is not to engage in long discussions - let the user talk by all means but don't fill the air with the sound of your own voice.
Careful observation and recording can be an excellent way to identify common tasks and areas that could be targeted for efficiency gains. Perhaps even more importantly, it can help understand the 'mental model' of the user, as well as the reasons and logic behind the decisions they make when completing tasks.
A good requirements gathering programme should include some form of evaluation of current usability levels, or at least provide baseline information on performance levels. This can either be an aspect of contextual enquiry or be formalised in a user test. This type of evaluation will provide vital information on areas in which users currently have difficulty and help set usability targets for future development.
Competitive analysis can be a further element in an evaluation programme - comparing other methods of performing the tasks in question in terms of effectiveness and efficiency. This comparative study should be as broad as possible. For example, an online ticket booking system should be compared not just with other similar services, but also with more conventional approaches to the task such as ringing a travel agent. It is often the case that the basic user requirement is an improvement over 'offline' methods of performing the same task.
The Benefits of Viewing User TestsThe benefits of user testing have long been established. It is still important however to try and maximise these benefits. One way in which this can be done is by viewing the user test yourself.
The Experience is KeyIt is important to remember that the experience a person has using a product or service is every bit as important as that product or services usability.
The Advantages and Limitations of Focus Groups in the Design ProcessFocus groups are a great way to collect information from several people very quickly and cost effectively. They are mainly used to gauge people’s reactions and feelings to items, however when used appropriately they can also be used as part of user requirements gathering.
Five Rules For Better Bank WebsitesInternet banking is here to stay and the major banks are all busy figuring out how to expand their business online. Online banking is all about convenience and functionality but what about the bank’s public website? It is often a struggle to achieve the right balance between information and product sales, between user functionality and marketing requirements.
Back To Basics: How Poor Usability Effects AccessibilityIn recent user testing with a range of participants including Visually Impaired (VIP) and Blind users we found that the majority of problems were common across all groups. However the effect of poor usability is more severe for users with visual disabilities. Surprisingly all of the issues are very familiar and are easy to fix so we thought we’d revisit some of the basics of accessible web design.