home purpose join itg ITG Publication job bank itg listserv hf/Web conferences library

ARTICLE Web Site User Centered Design: Techniques for Gathering Requirements and Tasks Jeanette Fuccella, jfuccell@us.ibm.com Jack Pizzolato, jackp@us.ibm.com Jack Franks, jfranks@us.ibm.com IBM Corporation Introduction An integral part of an effective user-centered design (UCD) process is the gathering of requirements and the identification of common user tasks. This part of the UCD process is just as important in Web site design and it is in software design. As such, the intent of this article is to provide Web site usability engineers with practical techniques for quickly and effectively identifying user expectations for their sites, both in terms of content and functionality. This article outlines various techniques that can be used for gathering Web site requirements and user tasks. These techniques have been used successfully on various IBM Internet and intranet Web sites and, when compared to competitors' sites, have allowed us to identify areas of opportunity and success. In addition, the sites designed using these techniques have proven more adaptable than other sites and have required less frequent redesigns. A number of methods can be used to gather requirements and identify tasks for Web sites. Because there is no "one size fits all" solution, the specific requirements, schedule, and objectives of a project will usually dictate the appropriate method or methods to use. Additionally, each method has its strengths and weaknesses, and these along with sample materials are provided to help usability engineers evaluate which method is most appropriate for a given situation. Finally, it is important to note that these methods can be combined to create the overall best solution for a project. Identifying Objectives Regardless of the method you choose to gather requirements and task data for your Web site, it is critical that you first identify your objectives in performing the activity. This is important for at least three reasons: It will help you determine which method best fits your needs. It will help you create a more focused agenda and gather more useful data. It will help you settle disputes with other members of the design team about the agenda and questions because you will be able to use the objectives you've set as a guidepost. Sample Web Site: CoffeeNet To allow you to more easily compare methods, the following sample Web site will be used as an example throughout this article: CoffeeNet, a mail-order coffee and accessory company is preparing to create a site on the Internet. The company's communication team has been charged with designing the Web site, and before they get started, they want to talk with target users to better understand what the users' expectations are for the site. The goals of the exercise are to: Identify and prioritize content requirements for the site. Identify and prioritize functional requirements for the site. Understand and categorize user tasks based on importance. Traditional Focus Group Focus group sessions today come in two varieties: traditional and electronic. In traditional focus group sessions, a moderator leads a verbal discussion with a small group of individuals (usually less than 10). Typically, the sponsor of the session observes from behind a one-way mirror in order to avoid biasing the participant responses. However, it may be beneficial to have the sponsor participate in the focus group, particularly in situations where the topic is complex or technical and requires further clarification. Since data capture is difficult during the session (because it is primarily qualitative), these types of sessions are often videotaped and then transcribed. An example moderator's guide is provided in Appendix A for your convenience. However, if you are not experienced with preparing a focus group, you will need to meet with a professional moderator before getting started. The moderator can describe alternatives and make recommendations that suit the purpose of your study, budget, and other key factors. Electronic Focus Group There are several different types of electronic focus groups and electronic focus group software packages. For the purposes of this discussion, we will focus on the method in which both the participants and the facilitator are seated at workstations that are connected through a LAN. A specialized software package is installed on each of the workstations. For example, in our lab, we use Groupsystems for Windows. The purpose of the specialized software is to capture electronic "discussions" among participants and to assist the moderator in further manipulating and analyzing the data. For example, the software allows the moderator to easily capture ratings or rankings for a series of items in a list. While it is possible to conduct the same type of analysis in a traditional focus group, it tends to be too time consuming and cumbersome to be beneficial. Because the focus group discussion is online, there is less verbal discussion than in a traditional focus group (although there still is a fair amount of verbal discussion). However, the lack of verbal discussion in an electronic focus group can actually be an advantage. With limited verbal discussion, no one participant can dominate the discussion, a commonly cited problem with traditional focus groups. Another benefit of using an electronic focus group over a traditional focus group is that the software allows users to be anonymous. As a result, users tend to offer more honest feedback and to be less cautious in proposing new ideas. Also, because users can all "talk" at the same time, you can collect more ideas in less time, making it easier to keep users on track. Finally, because electronic focus group sessions encompass a variety of different activities, participants tend to tolerate longer sessions than in a traditional setting. Because special skills and tools are needed to prepare for and conduct an effective electronic focus group, you should meet with a professional moderator before getting started. Appendix B contains an example agenda for the CoffeeNet electronic focus group. Iterative Surveys Not all Web site development teams have the resources to run either a traditional or an electronic focus group because these methods tend to be costly and require specific skills and equipment. An alternative to performing a focus group is to create a series of surveys that mimic the agenda of an electronic focus group. Because these surveys are iterative and therefore require completion of one survey before the next can be created and distributed, the tradeoff with this approach is that it takes longer--from start to finish--to complete. Like electronic focus groups, however, the results of this process tend to require little interpretation and re-work, resulting in faster overall distribution of data. Benefits are also derived from the ability to distribute the surveys using a Web server. First of all, unless an incentive is offered to participants, there is no cost increase for larger numbers of participants. Secondly, you can include non-U.S. participants without incurring the costs of international travel. Process Like an electronic focus group, the process begins with a high-level question and follows with increasingly more specific questions. The specific questions asked and the number of survey iterations are dependent on the research goals. The CoffeeNet site, for example, identified the following goals: Identify and prioritize content requirements for the site. Identify and prioritize functional requirements for the site. Understand and categorize user tasks based on importance. In our scenario, the CoffeeNet team created an initial survey that directly addressed the goals by asking users two open-ended questions related to the goals. The questions yielded a list of content and functional requirements, and a list of user tasks. The next step is for the team to go through each individual list and do the following: Remove duplicate items. Clarify items as needed (which may require contacting the author). Fix typos, spelling errors, and so forth. Create an updated list of items. The second survey is created using the output from the first survey. In the second survey, the goal is to prioritize the content and functional tasks and user tasks based on importance. Once users complete this survey, the team must calculate the appropriate non-parametric statistics (usually mean and standard deviation) for each individual item. The items within each list are then ordered according to their mean value. The purpose of the third survey is to gather further information about the most important requirements and tasks. This survey helps users elaborate on areas of specific interest to the team (for example, items that rate highly or items that rate low but for one reason or another are required for your site). When the responses are received from this third survey, data collection is complete unless individual follow-up with specific participants is desired by the team. Technical notes Be sure to put appropriate validation formulas on forms so that incorrect or incomplete responses are avoided. It's also helpful to be able to identify each survey participant in case any follow-up is necessary. Exploratory Survey Often, one of the easiest and cheapest methods for gathering requirements and task information is to create a simple survey with open-ended questions and to either advertise the survey appropriately or to link to it from an appropriate location. If you decide to advertise your survey on the Web (using banner advertisements, for example) be sure to choose locations for the advertisements that, to the degree possible, specifically target your user population. The cheapest method of advertising your survey is to create a link to it from a related site. Again, if this is possible, you need to be sure that the users of this site are also members of your target audience. In the case of CoffeeNet, the communications team was able to link to the exploratory survey from a related site owned by a sister company, FlowerNet. The team decided that visitors to the FlowerNet site would be similar to the target audience for CoffeeNet. But, just to be safe, the team also advertised the survey on the newsgroup alt.coffee.beans. Scenario Building Scenario building is another relatively inexpensive and quick method for collecting requirements and task information. The primary advantage of the scenario building method versus the exploratory survey is that it allows users to create a context for their requirements and tasks. This context allows users to be more creative and to identify requirements and tasks that other methods may not surface. Additionally, users can create multiple scenarios, with each scenario often yielding several tasks and/or requirements for the site. As a result, users are able to identify a large number of tasks and requirements in a short period of time (usually 30-60 minutes). One drawback to using the scenario building method is that, while it is possible to have users complete the questionnaire remotely, our research suggests that remote participation reduces the quality of the data. This is primarily because remote users tend to create fewer scenarios than do users in a laboratory setting. Also, remote users seem to have more difficulty understanding the scenario task; so it is critical that they receive detailed verbal instructions (even if it must be over the phone) in addition to the written instructions provided on the questionnaire. Another drawback to this method is that it does not provide any prioritization of requirements and tasks. As a result, we typically follow-up this activity with a simple requirement and task rating questionnaire. Process The process for building a scenario consists of asking users to complete three steps: Identify a reason for visiting the site. Identify the goal(s) to be accomplished by visiting the site. Describe the specific steps one would expect to follow to achieve the goal(s) identified in the previous step. Users are asked to be as detailed as possible in their descriptions, as this detail will directly influence the quality of the data. Users are also asked to provide as many scenarios as they can, but they should not trade detailed descriptions for an increased number of scenarios. As indicated on the scenario building questionnaire, the first step is for the user to identify a reason why they would want to visit the site. Typically, this reason is associated with a problem or desire. For the CoffeeNet site, an obvious reason to visit the site is to purchase coffee. However, users might also give reasons such as "need tips for brewing a good cup of coffee" and "need recipes for coffee cake." Step two in the scenario building method is to ask users to identify the specific goal(s) they want to achieve in visiting the site. In other words, how would the user know whether or not they had solved their problem or fulfilled their need for visiting the site? Again, on the CoffeeNet site, a user would know that they found tips for brewing a good cup of coffee if they were able to actually brew a good cup of coffee (not just that they found a list of tips--which might or might not help them to actually brew a good cup of coffee). In step three, users are asked to describe the specific steps they would expect to complete to achieve their goal. For example, users should describe the links they would click on and the location of those links on a page. For some goals, users will likely describe alternative methods for achieving their goals--methods that are more dynamic and interesting to the user. For example, the CoffeeNet user might suggest a troubleshooting wizard that asks a series of questions to help pinpoint and solve a coffee brewing problem. Our analysis of this data is relatively straightforward and purely qualitative. First, we read through each scenario (there will likely be multiple scenarios per user), and highlight any tasks or requirements contained within the scenarios. To obtain some idea of the priority of each task and requirement, two follow-on surveys (one for tasks, the other for requirements) ask users to rate each task and requirement on a 10-point scale. Next, we read through the Actions in each scenario, highlighting any terms or phrases or other specific user expectations, and specifically noting any trends among the data. This analysis of the data will assist in the high-level design of the Web site and will allow the Web designer to use terminology that is familiar to the user. Appendix G contains an example scenario building survey for CoffeeNet. Other Methods In addition to the relatively formal methods we've outlined in this article, there are a number of very simple, informal methods that can also be used. For example, a quick review of competitors' Web sites will reveal a number of useful ideas for requirements and functionality that could be implemented on your site. Also, if you have an existing site, ongoing requirements gathering can be as simple as adding a link to a short questionnaire about requirements and tasks. Conclusion Regardless of the method you choose to identify the appropriate tasks and requirements for your Web site, it is important that you conduct these activities before implementing any new design or major redesign of a site. This critical first step in the Web site design process will ensure that your final design is user-friendly, flexible and adaptable, and will eliminate expensive and unnecessarily frequent redesigns. Appendices Appendix A: Traditional Focus Group Moderator's Guide Appendix B: Electronic Focus Group Agenda Appendix C: Iterative Survey #1 Appendix D: Iterative Survey #2 Appendix E: Iterative Survey #3 Appendix F: Sample Exploratory Survey Questions Appendix G: Scenario Building Survey © Internet Technical Group Last update: June 1, 1998 URL: http://www.sandia.gov/itg/newsletter/june98/user_requirements.html hosted by Sandia National Labs Disclaimer: Neither Sandia Corporation, the United States Government, nor any agency thereof, nor any of their employees makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by Sandia Corporation, the United States Government, or any agency thereof. The views and opinions expressed herein do not necessarily state or reflect those of Sandia Corporation, the United States Government or any agency thereof.