CHAPTER 7
FIND THE REAL NEED
Megan Sapp Nelson, Purdue University
Learning Objectives
So that you can guide student design teams to find the real needs of clients, upon reading this chapter you should be able to
•Distinguish between different types of stakeholders in a design project, in particular between client(s) and users
•Describe the common challenges that student design teams face in identifying and capturing the full range of needs, wants, and expectations of various stakeholders
•List and describe the benefits of a user-centered approach to developing project requirements and constraints
•Demonstrate how active information gathering techniques reveal the needs and wants of project client, users, and other stakeholders
INTRODUCTION
Once the team is organized and a code of conduct has been agreed upon, team members are ready to explore the design task. This usually commences with a design brief that contains the client’s initial interpretation of the problem to be solved. However, a project team that considers only the design brief may substantially miss the mark in their design solutions. This is not only because only so much information can be communicated in a written document, but also because often clients do not know what exactly they want. This can be because they are unaware of possibilities or because they themselves have incomplete information about the needs of different stakeholders in the project.
Stakeholders are central to the design process. They are any individual who has a vested interest in the outcome of the project. That interest may be of a financial, utilitarian, or social origin. Stakeholders may provide funding for the process, specify problems that must be resolved or improved in the resulting solution, and influence both the scale and the time frame for a given project.
Stakeholders have both needs and wants that have to be captured, analyzed, and transformed into a set of requirements (those functions and features that must be present in the final artifact). They may also be a source of constraints, limitations placed upon a design project by any of a number of factors, including available resources, environment, legal requirements, and societal impacts. There are a few different kinds of stakeholders who are important to the design engineer (see Figure 7.1.) A client is a stakeholder who requests that an artifact be developed—that is, the entity that is paying the bills for the project. A user is a stakeholder who interacts with the artifact at any time during its life cycle, generally with the purpose of taking advantage of its features.
FIGURE 7.1 Stakeholders, clients, and users.
While clients make the investment of resources (time, money, personnel) to initiate a design project, they are not the only people impacted by the design process and the resulting artifact. Customers of the product, other end users, community members, maintainers of the artifact, and those who will ultimately dispose of the artifact when it has exceeded its natural life are all stakeholders in the design process.
The process of designing with the end user in mind is called human-centered design. The International Organization for Standardization’s (2010) ISO 9241-210:2010 lists the following benefits for adopting a human-centered design approach:
a. Increasing the productivity of users and the operational efficiency of organizations;
b. Being easier to understand and use, thus reducing training and support costs;
c. Increasing usability for people with a wider range of capabilities and thus increasing accessibility;
d. Improving user experience;
e. Reducing discomfort and stress;
f. Providing a competitive advantage, for example, by improving brand image;
g. Contributing towards sustainability objectives. (p. 4)
Central to the human-centered design approach is the need to elicit information from stakeholders. Effectively eliciting information from others requires strategies and tools not often covered in the engineering curriculum, first to identify who might be a client or stakeholder in the project, and then to retrieve relevant information from those individuals. This chapter provides guidance for gathering useful information from a variety of stakeholders for the development of design requirements and constraints.
COMMON CHALLENGES FOR STUDENTS
Eliciting information from the design client and other stakeholders is a significant challenge even for experienced engineers. For students, it can be highly frustrating. The challenge for the engineering designer lies in drawing out the design client’s understandings and observations and comparing that information to ideas elicited from others in order to get a comprehensive picture of the existing environment, the identified problem, and the most desirable outcome. Constructing this knowledge relies heavily on communication skills, not as taught in undergraduate speech classes, but as practiced on the library reference desk and other public service points. These interactions often require extensive interaction and follow up to tease out the client’s fundamental question, let alone the final answer. Most undergraduate engineering design students will need to be explicitly taught skills to enable them to perform this type of interaction (Nelson, 2009).
You can illustrate the challenges of communication to your students with an icebreaker used to build communication skills. Two individuals sit back to back. One individual is given a piece of paper with an abstract geometric drawing. The person holding the paper describes the abstract geometric figure to his or her partner. The partner then draws the figure as he or she believes that it has been described. The outcome frequently looks very little like the original drawing. In many ways, this icebreaker illustrates the challenges of accurately communicating design specifications and requirements.
Undergraduate engineering students are frequently accustomed to having all the relevant information presented to them, in the form of course textbooks, lecture notes, and supplementary materials. Such passive information acquisition does not work in the context of an open-ended design project. It is simply not possible for the design client to provide all necessary information to the design team in a single interaction, or even many interactions (Damodaran, 1996). The student designer needs to develop active information gathering skills, so that they have the ability to seek out important issues and relevant information that are not presented to them. Students frequently struggle with this change in their learning experience and consider it annoying, frustrating, and difficult (Zoltowski, 2010). Practicing active information gathering in prior course work can increase student abilities to adjust to the active information gathering that is necessary for design success.
Gathering user input can also be challenging for students because the information is not always direct or consistent, and the stakeholders may not be able to articulate their needs explicitly. They have latent (hidden or unknown) knowledge of the system or the problem that they might never have considered on a conscious level: “Oh, of course, we always put the peanut butter on before the jelly” (Vokey & Higham, 1999). And they may be able to identify that an aspect of the design project isn’t in accordance with their understanding of the situation but are unable to articulate the specific ways that it does not mesh with their worldview: “It just doesn’t feel right, I can’t describe it.” The engineering designer needs to understand the situation being described by the client and translate the client’s observations into a design deliverable that interfaces well with the existing environment that the client works in, as well as fixing or eliminating existing problems. Students need practice turning an initial statement, such as, “I need a pencil and paper,” into a functional need, such as, “I have to communicate with others in a textual/graphic manner.”
Students will also need to learn how to engender an open mode of communication to facilitate access to latent information. For the engineering designer, establishing a relationship with the client and providing prompt responses to suggestions or concerns raised helps create an environment in which the client feels comfortable sharing ideas, perspectives, and uncertainties. The initial client discussion should not be thought of as a one-time meeting but rather as the opening contact point in an ongoing relationship. If the design team does not maintain effective communication with the client and indeed other stakeholders after an initial meeting, it is much more likely that the artifact they design will not meet expectations or the real needs and consequently need extended revisions (Zoltowski, 2010).
Finally, it is critical to recognize that the client and the engineering designer may talk about the problem and possible solutions in quite different ways; the former in everyday language and the latter in technical terms that might not be understood by a lay audience. In other words, engineering as a discipline and an engineer as a practitioner must be aware of their use of words in particular and privileged ways. If a word is not clear to the client, the client may not ask for clarification to avoid looking unintelligent to the designer. In that way, important clarifications are missed and crucial opportunities to build mutual understanding between the client and designer are overlooked. Designers should target their language to the level of a senior in high school. This is slightly more sophisticated language than used in popular media, but much less sophisticated than used in an academic journal.
EXPLORING CLIENT BACKGROUNDS
Prior to meeting with a client, it is important to seek out basic information that will assist engineers in understanding the context of the client. That context may include motivations, available resources, goals, and financial information, as applicable. The request for consultation received from the client may be either vague or specific but generally does not give much context. The website, mission statement, strategic plans, and newsletters or press releases detailing recent developments within the organization are the first place to start gathering information about the client. These resources detail factual information, as well as provide insight into the organization’s goals and culture. The resultant product will have to perform successfully within the setting and culture of the organization, so this information provides important context for the design project.
Another important corporate document is an organizational chart. This helps the designer understand what part of the organization the task is being solicited from, what other departments the project will likely impact, and potential additional stakeholders to interview. Having a basic understanding of the organizational structure will assist the designer in collecting and understanding information from the stakeholders.
Once company-specific documentation has been examined and understood, the next step is to look beyond the organization for additional information. Public information about the client organization can come from a variety of sources. Newspaper articles generally are tied to press releases and will contain information similar to the internal documentation. However, they can be valuable for getting a community perspective of the project stakeholders. Newspaper articles can also uncover ethical contexts that the design deliverable will exist within. For example, if a newspaper article highlights how a client is dealing with privacy issues in the online environment and the design solicitation is for an online application, the team needs to clarify that aspect with the client.
Government documents provide insight as well, particularly when the client is a public corporation that must file quarterly and annual financial statements. These statements can give insight into emerging areas of growth for the organization, areas that are less competitive, and the available resources that the organization may draw on to support this project. For more on gathering information on the external context of a design project, see Chapter 8.
ELICITING INFORMATION FROM CLIENTS AND OTHER STAKEHOLDERS
In terms of the engineering design process, clients represent a significant source of specialized knowledge; they have unique knowledge and expertise related to the design context, as well as insights into the needs, wants, and constraints of the project. In the course of their day-to-day processes and activities, clients provide insight into what works well, what does not work, idiosyncrasies of any systems or technology currently used, and local cultural or organizational expectations. Clients and users are seldom consciously aware of some of the particularities of the work processes in their organization. They generally just go about their activities, carrying them out as they normally would without extensive consideration regarding how and why a process works or does not work. Thus much of their knowledge is tacit—hidden and thus difficult to gain access to (Polanyi, 1966). It is knowledge similar to how to ride a bike or perform a similarly complex manual task.
Related to this is latent knowledge—that is, things generally known but not under conscious control of the individual (Vokey & Higham, 1999). Latent knowledge may be experienced as a gut feeling or just a part of everyday life that, when changes or violations emerge, the individual may say just doesn’t feel right (Gorman, 1999). This cumulative wealth of tacit, unrecorded knowledge of clients and users includes information that will determine whether a design project is ultimately successful in the long term.
For designers, eliciting the tacit and latent knowledge of their clients is a significant challenge. Each individual client and stakeholder has a unique perspective that may influence the determination of design requirements and constraints. In particular, as experience, job responsibilities, and personality vary, so do the observations that individuals make and the resulting understanding that they have of how the project design will impact and interact with current practice. There are multiple methods for retrieving this information. Interviewing can be used to assist the clients to think in new ways about what they know. Observation can identify behaviors and patterns that the clients don’t even realize exist.
IDENTIFYING STAKEHOLDERS FOR INFORMATION GATHERING
Success in design depends heavily on successfully eliciting the knowledge that stakeholders have accumulated through experience, observation, and other institutional knowledge that they maintain. But who are the stakeholders—beyond the client and people who will use something that is designed? Brainstorming a list of everyone who could potentially come in contact with the artifact to be designed is the first step to developing a comprehensive information collection plan. Personnel lists and organizational charts may provide insight into who should be asked for information. Identifying a specialist insider (e.g., a secretary, a manager, a supervisor) who sees the big picture of the organization as well as the work flow that occurs daily can be invaluable for determining who should be asked for input in the design process.
If possible, observing the clients, users, and other stakeholders in the operational environment in which the artifact will be used provides access to information that may not be available in any other way. In a demonstration of this technique for a news magazine story, the design firm IDEO went to a grocery store and observed shoppers. The firm determined that professional shoppers went about the process of shopping in a different way than household shoppers. The professional shoppers were much more efficient, and the key to their efficiency was to leave the cart at the end of the aisle so that there was no possibility of getting caught behind slowly moving household shoppers. This influenced the ultimate design of their cart (ABC News Nightline, 1999).
Observation is a time consuming but flexible model for identifying individuals who possess latent information and then collecting that information. Noyes and Garland (2006) provide a short overview of observational practices. Observations can be designed so that the observer is either covert (not engaging the subjects of observation) or overt (interacting and asking questions with the subjects). A good plan for an observation (Noyes & Garland, 2006) attempts to answer the following:
•Why?
•Who? (All or a selection of stakeholders?)
•What? (Define the behavior to be focused on.)
•Where? (Define the physical boundaries.)
•When? (Define the overall appropriate temporal parameters.)
•Duration? (Define the sampling method.)
•How? (Define the type of recording.)
•Role? (Define the researcher’s level of participation.)
The primary advantage of observation is the immersive nature of the process. It helps the designer become familiar not only with the client and users in their work context but also with the environment, including stakeholders, organization-specific work flows, and the exceptions that are evident only in the environment where the design deliverable will be introduced. Immersion within the environment (even if only for a few hours) combined with in-depth interviews gives a deeper understanding of the situation and constraints for the design project than an interview alone.
INTERVIEW TECHNIQUES
A design project is generally initiated at the request of the client. Multiple meetings with the client help tailor the client’s vision of the project into actionable information. An interview plan is an important tool to improve the efficacy and efficiency of a client meeting. Based on the questions typically asked of journalists—who, what, when, where, and how—a planned interview provides the interviewer an opportunity to brainstorm potential topics of discussion before the meeting, organize the interview so that it flows well, phrase the requests for information in an open-ended manner so as to draw out the knowledge the client has, and create a document that structures notes taken and reminders for follow ups at a later time (Nelson, 2009). Figure 7.2 provides an interview plan that was developed for Engineering Projects in Community Service (EPICS) at Purdue University.
FIGURE 7.2Client interview plan.
The planned interview not only focuses on open-ended questions but also encourages the interviewer to strategically design the interaction to foster the outcome of the interview. Active listening, a process that encourages critical consideration and follow up on statements at the time of the interview, is made easier by having a plan for the interview. It allows the conversation to be redirected back toward the goal the interviewer has in mind. Active listening requires vigilance during the interview. Including questions that will check the perceptions of the interviewee is important for developing a common understanding of the problem and eliciting more detail (Nelson, 2009). Perception checking is a process by which the engineering designer verifies his or her understanding of what the interviewee has said by rephrasing the question—for example: “If I understand you correctly, the file is then sent from you to someone in quality control for testing.” This allows the interviewee to confirm, deny, or augment what was previously said. This type of language does not come naturally, so perception checking must be practiced in order to enable successful, smooth implementation during an interview.
It is very important to keep a detailed record of what transpires within a client interview. Video or audio recording provides the most complete record. However, indexing or transcribing the resulting file generally requires specialized software and trained transcribers. Generally, permission of the interviewee should be requested prior to recording an interview, even if it is just a simple permission form presented to the client. Prior communication will avoid surprises so that the team does not arrive at the site only to be told that the company has a policy against recording.
In the case that audio or video recording capability is not available, or a permanent record is prohibited by confidentiality agreements (see Chapter 5), team roles should be assigned to ensure duplicate notes are taken and full coverage of the interview is captured. Multiple note takers should record not only the oral content of the interview, but also make notes of topics that body language and other cues indicate should be followed up on at a later time. For example, if a supervisor is the primary client and makes a statement, but a subordinate opens his or her mouth to speak and then closes it again, a note should be made to talk to that individual again at a later time about that specific topic.
As an interviewer, the engineering designer also must consider his or her own role in the interview. Body language on the part of the interviewer can send a message to the interviewee either that the interviewer is engaged in what the interviewee is saying or is bored and would rather be someplace else. Similarly, nervous habits such as clicking pens or tapping feet can give the impression of impatience or distraction. Practicing interviews ahead of time will help to make interviewers aware of their tendency toward these distracting actions. It is useful to have others on the design team brainstorm alternative ways that interviewers can deal with nervous habits.
If an interview is being conducted one on one, and the interviewee is having difficulty explaining his or her latent knowledge (the “it doesn’t feel right” phenomenon), several different approaches aligned with the preferences of different learning styles may help to draw out the information that the client has in mind. Table 7.1 provides examples of strategies that might assist interviewers in eliciting information from informants according to their preferred learning styles. It uses the four dimensions of learning style based on Felder and Silverman (1988): active-reflective, sensorintuitive, visual-verbal, and sequential-global. For example, walking a client who is an active, sensor, visual, and global learner through a physical space or work flow may help the client preferentially to see how a proposed solution might impact the current work flow.
TABLE 7.1Information-Eliciting Strategies Based on Informant Learning Style (Using Felder-Silverman Learning Styles Inventory)
| Learning Style | Key Characteristics | Eliciting Information Strategies |
| Active | Prefer doing something active; discussing or applying it or explaining it to others | Ask them to show you what they do. Invite them to talk you through it and to demonstrate in the authentic location |
| Reflective | Prefer to think about things quietly by themselves | After talking with them, offer them an opportunity to think about things (say, overnight) and suggest they write down their thoughts and send these to you later |
| Sensing | Prefer facts, details, practical matters, the “real” world | Encourage them to give you the facts as they see them; ask them to explain what is done and why |
| Intuitive | Prefer discovering possibilities and relationships |
Ask them for their ideas about how things work around here Elicit their theory of what is happening and why |
| Visual | Relate best to visual information—pictures, diagrams, flow charts, time lines, films, and demonstrations | Get them to discuss what happens here using available operational charts, performance graphs, and the like |
| Verbal | Get more out of words— written and spoken explanations | Invite them to tell you stories about how things work here; these can be war stories of practice or anecdotes about the organization or the personalities therein |
| Sequential | Prefer linear steps, with each step following logically from the previous one | Ask them to walk you through what happens step by step and explain the rationale of why it is so or what has been tried previously |
| Global | Take large jumps; think almost randomly without seeing connections, but then suddenly get it | Encourage them to paint the big picture about the place Ask if they have a metaphor that captures what happens around here |
Modified from Felder & Silverman, 1988.
At various time all people prefer to receive and deliver information in different ways. As Felder and Soloman (n.d.) observe: everybody is active sometimes and reflective sometimes and everybody is sensing sometimes and intuitive sometimes. It depends upon the circumstances, so it is critical not to pigeonhole informants into a set of characteristics. The designer should keep all the strategies at hand and deploy them as most appropriate, treating each informant as an individual with unique learning and informing styles.
Using Post-it notes to capture ideas from a group and then categorizing them by collating them on the wall or table may be helpful. Similarly, encouraging a client group to model or act out a work flow or process may provide additional insights as well. The client interviewee group can be split by similarities (IT personnel, sales people, etc.) and those groups asked to brainstorm the implications of the design solution for their department. Then, the client interviewees can be grouped across function (e.g., one IT person, one sales person, and one manager) and asked to brainstorm how the design task facilitates or hinders cross departmental communication and work flows. Using activities, drawing on visual and oral cues, and group discussions will help the client or client team to fully consider what each person knows and to articulate their opinion(s).
Additionally, wire framing or concept mapping may assist the client or client team in categorizing and identifying their work flow. Talking through either of the previously mentioned approaches will assist them in articulating ideas about their work and processes.
After the interview, it is very important that the designer immediately return to his or her notes and/or recordings of the interview to confirm that the contents are unambiguous and that no major points were missed, and to add in any additional impressions or ideas that occurred to the engineer during the interview session. This can be as simple as a brief review of the notes, or as complex as a weighted decision matrix (see Chapter 11). If the interview was recorded and transcribed, the designer can annotate the print transcription where further follow up is needed. If a full transcription is not possible, the interview can be indexed by listening to it again, making note of the time stamp when a topic emerged, and noting the topic, as well as any additional follow-up questions.
Regardless of technique, the goal is to immediately return to the interview and add any emerging observations or questions into the written record for the project. A significant amount of value from the interview is lost as initial impressions and questions are forgotten over time. For future design team members, an accurate, extensive record created at the time of the interview is a valuable asset for the rest of the design cycle. A strong knowledge management system for the team will ensure that the information gathered remains accessible throughout the project, to maintain alignment with the determined needs.
PERSONAS
A useful exercise at the end of a group of interviews is the creation of personas. In this case a persona does not represent one person, but an archetypical user of the design deliverable. This persona helps draw together the major commonalities across multiple interviews and highlights specifications that will serve the greatest number of users. The personas then become living documents by which to test assumptions made by engineering designers and recall the human-centered part of human-centered design (Pruitt & Adlin, 2006).
In general, a persona looks a little like an online profile of a person. It includes a representative photo and sample characteristics, such as age, work roles, home life, immediate and long-term goals, and a description of how that archetype interacts with the design deliverable. For extended information on the process of creating a persona, see Pruitt and Adlin (2006). Creating personas is a quick way to summarize the pertinent information found during the interviews. Either way, the persona serves to recall the designers back to the specifications elicited from the interviews throughout the design life cycle. For further discussion of the use of personas, see Chapter 8.
ADDITIONAL TECHNIQUES
IDEO has created a deck of cards (http://www.ideo.com/work/method-cards) that contains 50 strategies for eliciting information based on four approaches—learn (from what already exists), look (at what people do), ask (people), and try (out an idea). Comparable strategies are published by the d.school at Stanford (http://dschool.stanford.edu/use-our-methods). These and similar toolboxes of need-finding and knowledge-eliciting techniques can be used as a resource for a design class to not only prompt students to learn and adopt creative new approaches to get a more comprehensive information background on their project, but also teach the students to become creative design thinkers.
SUMMARY
In this chapter we considered the information that our stakeholders possess regarding our design project. We looked at several techniques that allow us to access that information and gather it for the creation of design requirements and constraints. Using the information gathered by users who are clients and stakeholders in combination with the information gathered from external sources (see Chapter 8) allows the engineer to understand the problem more deeply, refine the requirements, and identify constraints. These are then used to create the design specifications that will guide the creation of solutions to the design problem.
SELECTED EXERCISES
Exercise 7.1
Have students brainstorm five to six potential sources of information about the organization they are working with that were not authored by someone in that organization. Have them search these sources for information. Ask them to discuss what they found and how the information produced by someone outside the organization differed from the corporate authored materials. Have them evaluate the strengths and weaknesses of both types of information.
Exercise 7.2
Practice perception checking using the following exercise.
Have one individual in a student team speak for two to three minutes on a topic with which they are familiar. Examples include changing a bicycle tire, baking a special dessert, playing an instrument, building a website, programming in a specific language, gardening, and so forth. Have the other members of the team listen and write down follow-up questions phrased to check perception. For instance, a student might ask a speaker on the topic of changing a bike tire: “If I understand correctly, you are matching something about the tube to the tire. How do you know which tube goes with that tire?”
Exercise 7.3
Students learn to recognize their own body language and verbal ticks when they are made aware of them either by videotaping or by having peers provide feedback. Videotaping a mock interview, with students taking on the role of both interviewer and interviewee, allows the students to objectively understand how their communication skills appear to others. (This can even be done with a simple smartphone.) This is best done in a small group rather than as an entire class. If possible, the students should take turns interviewing and being interviewed so that every person plays both roles. Those who are acting as interviewer should plan the interview with the goal of eliciting specific information. Provide feedback on body language and word choice and expose students to alternative interview techniques they may use to get similar or better quality information.
ACKNOWLEDGMENTS
Special thanks to David Radcliffe for creating the mapping of information-eliciting strategies to the Felder and Silverman (1988) preferred learning style of the informants (see Table 7.1).
REFERENCES
ABC News Nightline. (1999). The deep dive. ABC. Retrieved from http://www.youtube.com/watch?v=JkHOxyafGpE
Damodaran, L. (1996). User involvement in the systems design process-a practical guide for users. Behaviour & Information Technology, 15(6), 363–377. http://dx.doi.org/10.1080/014492996120049
Felder, R. M., & Silverman, L. K. (1988). Learning and teaching styles in engineering education. Engineering Education, 78(7), 674–681. Retrieved from http://www4.ncsu.edu/unity/lockers/users/f/felder/public/Papers/LS-1988.pdf
Felder, R. M., & Solomon, B. A. (n.d.). Learning styles and strategies. http://www4.ncsu.edu/unity/lockers/users/f/felder/public/ILSdir/styles.htm
Gorman, M. E. (1999). Implicit knowledge in engineering judgment and scientific reasoning. Behavioral and Brain Sciences, 22(05), 767–768. http://dx.doi.org/10.1017/S0140525X9936218X
International Organization for Standardization. (2010). ISO 9241-210:2010, Ergonomics of human-system interaction—Part 210: Human-centred design for interactive systems. Geneva, Switzerland: Author.
Nelson, M. S. (2009). Teaching interview skills to undergraduate engineers: An emerging area of library instruction. Issues in Science & Technology Librarianship, 58. http://dx.doi.org/10.5062/F4ZK5DMK
Noyes, J., & Garland, K. (2006). Observation. In W. Karwowski (Ed.), International encyclopedia of ergonomics and human factors (2nd ed.). 3 volume set. Boca Raton, FL: CRC Press. http://dx.doi.org/10.1201/9780849375477.ch635
Polanyi, M. (1966). The tacit dimension. Garden City, NY: Doubleday.
Pruitt, J., & Adlin, T. (2006). The persona lifecycle: Keeping people in mind throughout product design. Boston, MA: Morgan Kaufmann.
Vokey, J. R., & Higham, P. A. (1999). Implicit knowledge as automatic, latent knowledge. Behavioral and Brain Sciences, 22(05), 787–788. http://dx.doi.org/10.1017/S0140525X99582186
Zoltowski, C. B. (2010). Students’ ways of experiencing human-centered design. (Doctoral dissertation). Retrieved from ETD Collection for Purdue University.