L503 User Needs and Behavior in Theory and Practice


Learning Guide
Prepared by
Jean Umiker-Sebeok and Kim Gregson
School of Library and Information Science
Indiana University - Bloomington
Created Fall, 1996; Revised Aug., 1998


 


Methods for Analyzing Users' Needs and Behavior

Defining User Needs: Tasks, Tools, Situations
Types of Situations in Which User Needs Analysis Should be Done
Top-down  vs. Bottom-up Approach to Needs Analysis
Methods of User Needs Analysis
Who Needs to Be Studied
Triangulation
Choosing Your Methods
Timeline for Methods
Bibliography
Appendix I -  Sample Structured Interview Protocol
Appendix II - Sample Focus Group Protocol

Defining User Needs: Tasks, Tools, Situations

The goal of user needs analysis is to determine what your client wants to accomplish, where, with whom, why, and in what ways. You can see from this week's readings that there are many ways to study users' information assets. Each method has its advantages and disadvantages. Each method makes it easier to understand some things and blinds you to others. This week's readings should give you some of the background you need to decide which methods to use for your project. Notice, as you read, that, within each method, there is room for experimentation. A focus group method can employ techniques such as card sorts or questionnaires which add systematicity.

You will find many opportunities to use these methods in your professional life. Brainstorming is a first step in many organizations which need to come up with a lot of ideas quickly when offered a new opportunity. For example, a public library may hear about a grant offering and they could brainstorm about a new program they want to offer that they could propose to win the grant. Many organizations invite their customers to join focus groups to talk about services or products. The political parties even had focus groups to talk about candidates and platforms of both parties. Companies are setting up strategic intelligence departments to scan many sources of information for news that might affect profits. Software designers spend time away from their own offices, studying how real users work in their homes or offices (ethnographic studies); the goal is to improve the software by better understanding the work environment and doing a more complete task analysis. The more you practice using these methods in classes, where you can get feedback on your technique and results, the more at ease you will be when you need to use them in a more stressful work setting.
 

Types of Situations in Which User Needs Analysis Should be Done

Hale (1986) describes three types of situations in which you will need to perform an information audit.

Top-down  vs. Bottom-up Approach to Needs Analysis

Analysis of user needs can be done top-down or bottom-up.  In the top-down approach, you start with the users' decision-making and work down to information required for problem-solving.  For example, to determine students' information needs, first identify their goals (e.g., registering for classes or planning their career), then identify the specific tasks, settings, and tools needed to reach these goals.

The top-down approach is particularly useful in those situations where you are designing a new system or customizing an existing system, but can also be used when customizing or fine-tuning a system.  This is the approach described in the class devoted to the participatory design process.

In the bottom-up approach, you start with the information used, asking users how useful it is for the decisions they have to make.  For example, SLIS administrators could study how students interact with different kinds of information (e.g., the SLIS Web site, printed materials, information from alumni or current students) and build up a picture or model of the goals students are pursuing with these materials (e.g., deciding to enroll at SLIS or choosing which courses to take).
The bottom-up approach is particularly useful in those situations where you are fine-tuning a new system, but can also be used when customizing or fine-tuning a system.

Methods of User Needs Analysis

Hale places methods along a continuum from intuitive to scientific. In general, as you move along this continuum of methods, you gain the following advantages:
 On the other hand, you also accrue the following disadvantages: Intuitive methods are characterized as follows:
Examples:  use of researcher's intuitions about situations s/he observes
Impressionistic methods are characterized as follows:
  • involve more rigorous testing than intuitive methods, but are still not theory-based like scientific methods
  • the bias of the analyst can influence results
  • data collection is done more systematically
  • some thought is given to purpose of the study when collecting information
  • are qualitative
  • often collect information which does not directly apply to the current problem
  • results must be explained and summarized
  •  Examples: brainstorming, focus groups (= structured brainstorming), scanning
     Systematic methods are characterized as follows:  Scientific methods are characterized as follows: Whether you work from top to bottom or in the opposite direction, you need to understand users' lives at many levels, and understand how the levels are related to one another. It is important that you develop a clear and detailed picture of the things your users want to do, how they want to do it, and the role your system can play in facilitating this process. When you look at users from this point of view, you will find overlaps between what we traditionally categorize as separate domains -- e.g., work vs. play. Finding out when the next bus comes may be a move that fits within a larger task of "getting to work on time", which fits within a scenario "Working toward success in my career", but it may also belong to a "getting to the food stamps office" or "getting to the doctor's office" task within other scenarios. It is your job to see how all these pieces fit into the puzzle of your users' lives, and then to find a way to make your system make these users' lives easier.


     

    Who Needs to Be Studied

    User needs analysis needs to be done with all system stakeholders. Stakeholders are those people who, for one reason or another, rely on the information provided by an information system.  Stakeholders may include people both inside and outside of the organization. For example, students and faculty are obvious stakeholders for SLIS' information system, but so are alumni, librarians who may be looking for an "expert" to help with a problem, employers who may be looking for places to recruit good job applicants, faculty at competing institutions who need to keep track of what their competitors are doing, etc.

    Stakeholders may include people at all levels of the organization. For example, a public library's information system should serve the needs of patrons, staff, members of the Board of Directors, donors, volunteers, etc.  Because of time limitations, you will not have time to study ALL stakeholders relevant to your client's tasks. It will probably not be possible for you to study the needs of those outside the organization, for example. However, you should aim at studying as many of the members of the group as possible. For example, a site being developed for a social service organization should involve staff at all levels of the organization. Do not rely on the opinions of only the managers, for example, or only of staff. Involve a cross-section of the user group in your study.

    Needs analysis should involve real users, not people who just happen to be handy. Only real users can give you the understanding of their needs that you require for system development.  Remember that you are only going to be able to talk with a relatively small number of people. It is therefore important that you choose people who will give you results that you can generalize to the whole group (McGrath, p. 155). This means that you don't want to pick subjects who are idiosyncratic in many ways from the user group. You will also want to be as systematic as possible in your use of methods.


    Triangulation

    Triangulation is the use of different research methods and the comparison of the results obtained using them to draw conclusions. Triangulation is especially important when using less scientific methods. The VanHouse article provides an example of an information professional using triangulation in the planning of a digital library.
    You are being asked to use four different methods because every method has both strengths and weaknesses and the use of several will enable you to compare your results and draw your conclusions with greater confidence. If the facts you obtain with different methods agree, you can be more certain that you have obtained reliable results. Conflicting facts should make you question whether your hypotheses are correct and seek additional information before drawing conclusions which will form the basis of the web site you will design. You may decide that there is something different about subgroups in your population with which you now have to deal.

    Choosing Your Methods

    The primary consideration for your selection of methods should be the need to obtain reliable data.  However, you will also have to take into account the situation of your client and the resources you have at your disposal.

    You will need to make decisions about when to use which methods, and for what purposes. Here is some information that will help you make these decisions:

    Scanning

  • reading through materials about your client, produced for the client, produced by the client -- email, websites, annual reports, press clippings, government studies, statements by competition
  • scan for impressions -- what is the general nature of the group, of their needs?
  • tour facilities used by the group
  • emphasis is not on taking notes but on gathering impressions
  • information gathered by scanning can be used as the basis for questions in interviews or focus groups, for items in surveys
  • inexpensive to do in many situations
  • not replicable or generalizable
  • can be done over time
  • can be used by corporate intelligence units to keep track of customers wants,  competitor activities,  government regulation, and potential products
  • Ethnography
      Focus Groups


    Structured Interviews

    Surveys -- While surveys can be reliable sources of data, unless you have considerable experience in conducting them, it is recommended that you not use this method in this course.


    Timeline for Methods

    Your precise timeline for the use of methods will have to suit the situation in which you are conducting your research.  Consult the Project Timeline page for the sequence of steps and deadlines.  Guidelines and sample documents for methods are given in Appendices B-? of the Syllabus to help you in selecting and using the methods.


    Bibliography

    Erickson, Thomas  (1996)  Design as storytelling.Interactions 3(4) (August).   http://www.pliant.org/personal/Tom_Erickson/Storytelling.html 

    Hale, Martha L. (1986) Administrators and information: A review of methodologies used for diagnosing information use. Advances in Librarianship 14: 75-99. (New York: Academic Press.)

    Hughes, John et al. (1995) The role of ethnography in interactive systems design. Interactions April: 57-65.

    Kuhlthau, Carol C. (1993) Methodology for studying the constructive process of information seeking, ch. 6 in Seeking Meaning. A Process Approach to Library and Information Services, pp. 79-107. Norwood, NJ: Ablex.

    McGrath, Joseph E. (1994) "Methodology Matters: Doing Research in the Behavioral and Social Sciences" in Baecker, Ronald et. al. (1995) Human Computer Interaction: Toward the Year 2000. San Francisco: Stanley Kaufmann Publishers, Inc., p. 152-169.

    Van House, Nancy A. (1995) User needs assessment and evaluation for the UC Berkeley Electronic  Environmental Library Project: A preliminary report. Digital Libraries '95: 2nd Annual  Conference on the Theory and Practice of Digital Libraries.   http://csdl.tamu.edu/DL95/papers/vanhouse/vanhouse.html