Needfinding

The best sources of information for needfinding are user interviews and direct observation. Usually, you’ll have to observe how users currently solve the problem. If you want to redesign a campus tour experience, you would want to observe tourists on campus. You would also want to interview them, in order to better understand their goals and challenges.

Contextual inquiry is a technique that combines interviewing and observation, in the user’s actual work environment, discussing actual work products. Contextual inquiry fosters strong collaboration between the designers and the users.

Participatory design includes users directly on the design team - participating in needfinding, proposing design ideas, helping with evaluation. This is particularly vital when the target users have much deeper domain knowledge than the design team. It would be unwise to build an interface for stock trading without an expert in stock trading on the team, for example.

A good collection of information-collection techniques is summarized by Need Finding Tools.

http://hci.stanford.edu/courses/cs447/docs/NeedFindingCribSheet.pdf

The reason for user analysis is straightforward: since you're not the user, you need to find out who the user actually is.

User analysis seems so obvious that it's often skipped. But failing to do it explicitly makes it easier to fall into the trap of assuming every user is like you. It's better to do some thinking and collect some information first.

Knowing about the user means not just their individual characteristics, but also their situation. In what environment will they use your software? What else might be distracting their attention? What is the social context? A movie theater, a quiet library, inside a car, on the deck of an aircraft carrier; the environment can place widely varying constraints on your user interface.

Other aspects of the user's situation include their relationship to other users in their organization, and typical communication patterns. Can users ask each other for help, or are they isolated? How do students relate differently to lab assistants, teaching assistants, and professors?

Many problems in needfinding are caused by jumping too quickly into a system design. This sometimes results in wishful thinking, rather than looking at reality. Saying "All users should have our app installed on their phone" is stating a requirement on the system, not a characteristic of the existing users. One reason we do needfinding is to see whether these requirements can actually be satisfied, or whether we'd have to add something to the system to make sure it's satisfied.

Many, if not most, applications have to worry about multiple classes of users. Some user groups are defined by the roles that the user plays in the system: student, teacher, reader, editor.

Other groups are defined by characteristics: age (teenagers, middle-aged, elderly); motivation (early adopters, frequent users, casual users). You have to decide which user groups are important for your problem, and do a user analysis for every class. If you're designing an interface like Piazza, you'll need to identify several user classes by role: students, TAs, and instructors.

When developing an application, you need to think beyond users. We need to think of “stakeholders.” Stakeholders are those who have a share or an interest in the application. There are many ways of defining stakeholders, but we can simply divide stakeholders into three layers.

• The first degree stakeholders are generally referred to as “users” (those who actually use the product).
• The second degree stakeholders are those who work with the results from those who use the product.
• The third degree stakeholders are those who install, deploy, or support the system. 

Let’s think about school information systems for a sports complex (or gym). The first degree users are actual “users”: students/faculty/staff (who do the workout!), and supporting staff (cashers, ID checking). The second degree users could be school management officials/committee, exercise equipment manufacturers/suppliers, and security services. It may include friends/families of the “users.” The third degree stakeholders are those who actually install, deploy, or support this kind of system.

The best sources of information are user interviews and direct observation. Usually, you'll have to observe how users currently perform the task.

For the Piazza example, we would want to observe students asking questions about homework assignments, and interacting with teammates. We would also want to interview instructors to understand their goals in running a Q&A forum for their course.

The premature-system-design mindset can affect this part too. If you're writing down tasks from the system's point of view, like "Notify user about appointment", then you're writing requirements (what the system should do), not user goals. Sometimes this is merely semantics, and you can just write it the other way; but it may also mean you're focusing too much on what the system can do, rather than what the user wants. Tradeoffs between user goals and implementation feasibility are inevitable, but you don't want them to dominate your thinking at this early stage of the game.

Needfinding derived from observation may give too much weight to the way things are currently done. The steps of a current system are concrete tasks, like "save file to disk." But if we instead generalize that to a user goal, like "make sure I can come back to my work later", then we have an essential task, which admits much richer design possibilities when it's time to translate this task into a user interface.

A danger of concrete analysis is that it might preserve tasks that are inefficient or could be done a completely different way in software. Suppose we observed users interacting with paper manuals. We'd see a lot of page flipping: "Find page N" might be an important subtask. We might naively conclude from this that an online manual should provide really good mechanisms for paging & scrolling, and that we should pour development effort into making those mechanisms as fast as possible. But page flipping is an artifact of physical books!  In fact, you don’t need to duplicate this (bad or less efficient) existing procedure in your new software. It might pay off much more to have fast and effective searching and hyperlinking in an online manual. That's why it's important to focus on why users do what they do (the essential tasks), not just what they do (the concrete tasks). If you focus too much on very concrete tasks and aim to fix very specific errors within such tasks, it’s likely that you may end up making minor improvements against existing procedures---remember the local maximum problems in the design process.

Conversely, an incomplete analysis may fail to capture important aspects of the existing procedure. In one case, a dentist's office converted from manual billing to an automated system. But the office assistants didn't like the new system, because they were accustomed to keeping important notes on paper forms, like "this patient's insurance takes longer than normal." The automated system provided no way to capture those kinds of annotations. That's why interviewing and observing real users is still important, even though you're observing a concrete task process.

Contextual Inquiry

The key idea of contextual inquiry is to actually understand user needs in the context of their work by collecting real data from users who are doing real work at the site of a real workplace. As Steve Blank said, we “get out of the building” and go to users’ real workplace to get better understanding. There are always huge gaps between what we think and what we observe. What we already know is often the case, “biased.” You may argue that you know something fairly well, and you’re not biased in your judgment. However, it is often the case that “reality” is very different from what you assume. You need to change your “hat”: i.e., from the secondary user’s hat to the primary user’s hat. You need to immerse yourself in the context; you need to put yourself into the user’s shoes!

Now you have to think about what to capture. As the name “contextual inquiry” tells, you need to capture the entire context of a user. First, you need to capture their roles, responsibilities, and types of communications.  For example, in a research lab, a research staff member could do research, but also have a manager’s role as a project leader. Also, it is important to understand social environments and how people are communicating for what. Second, you may want to understand their work environments (e.g., how a research lab is organized? How users are moving around within a lab?) Third, you then need to find out what are the artifacts (e.g., computers, lab devices, or any other things related to tasks) that users use or refer to. You can take photos of these artifacts if you wish. Fourth, you need to understand the key tasks that you’re interested in understanding. As shown in the following, you need to study how the work is organized in a systematic way. You can draw a flowchart to visualize how the work is done; that’s why it’s also called “(work) sequence modeling.” For each task, you can also note what triggers that task and what’s the user’s intention behind. While you’re doing contextual inquiry, you need to be keen on finding “breakdowns” (= problems). Breakdowns may be due to physical environments, artifacts, or task sequences.

Let’s consider how a class lecture happens. An instructor arrives at the classroom. The instructor turns on the projector and tries to connect the laptop. He has a problem of connecting a laptop to the projector. After adjusting resolution, he was able to finally project the laptop screen on the projector screen.  Then, he launches PowerPoint and searches for the lecture slide deck.

Sequence modeling is simply a step-by-step recording of the tasks. You can think of it as “task analysis.” During the contextual inquiry, you can easily identify a set of tasks that a user is performing. For each task, you then need to be keen on observing (1) what’s the intent of performing that task (why users perform that task?), and (2) what triggers the user to perform that task. Also, you need to follow the user so that you can detail each step of the task. In the end, you can draw a flowchart of each task. Interestingly, you can also notice “breakdowns” ( or problems) that users encounter while performing a given task. In the below example, the instructor wants to make HCI course assignments to the students by referring to the last year’s course materials. However, the instructor encountered two problems: (1) not able to quickly find the assignments; and (2) failed to download the files due to permission errors.  

Physical and artifact models are quite straight-forward. If users are okay, you can take photos to capture a user’s physical work environment. You may want to detail physical structures/layouts of the office; and how tools/objects (what we call “artifacts”) are like. If there is any information displayed on the tools/objects, you may want to capture that as well. Observe how a user performs a task within the physical space and how the user uses the artifacts to accomplish the task. As in sequence modeling, you can easily find breakdowns/problems and identify some design ideas as well. Below example is from Rapid Contextual Design:

After interviewing, you’ll have many notes!  You can meet the key informants (stakeholders) and have collected many notes. During the contextual inquiry, you have probably collected information about breakdowns/problems (that the user encountered during the work), intents of some work that the user is performing, some of the strategies for working, and triggers of tasks that the user is performing. Also, you can make notes about design ideas and implications that can better improve the current workflow. You don’t need to simply capture individual steps of work. Affinity notes do not have order, and the structure of the task cannot be captured.

You can go over the notes to identify “what are the major issues.” Just skimming through your notes, you can immediately identify the common issues.  To be precise, you may want to print each note (say in the sticky note) and physically cluster similar notes together. You can use computer software tools (like mindmap) as well. There are no strict rules about how you do affinity diagramming.

After contextual inquiry, you can make a persona. You can think of a persona as a generic representation of the target users that you’re interested in. After several contextual inquiries, you can easily find out what their goals, roles, and tasks are. You can give a persona a name, say John or Jane. Persona building helps you to better capture the characters of “common users” ; i.e., scenarios, goals, tasks, and roles. How many personas should we build? It really depends on your situation. As long as you can capture the characteristics of major stakeholders (i.e., the first degree stakeholders), it would be fine.

If you like to know more about persona, please read this article:

Personas: Practice and Theory, John Pruitt and Jonathan Grudin

http://www.jonathangrudin.com/wp-content/uploads/2017/03/DesignChapter.pdf 

This is the final step of needfinding. You have work models, major issues identified through affinity diagramming, and persona. From this dataset, you are now able to “objectively” talk about what are the key issues and how to tackle those issues.  Well, as you do contextual inquiry and summarizing/interpreting the data, you and your team members already have rough ideas about what the key issues are. Data reviewing helps you to “remind” of the issues and to better prioritize issues and ideas.