Introduction to User Experience
What Is User Experience?
If you are reading this book, you already have some idea about, or at least interest in, User Experience (UX). However, you likely arrived at this book and this field via a different path from the colleague sitting next to you or the classmate across the country who is taking the same online human-computer interaction (HCI) or human factors class as you. User experience practitioners and students come to UX from a diverse range of backgrounds, including computer science, psychology, design marketing, business, anthropology, and industrial engineering (Farrell & Nielsen, 2014). This diversity is an advantage; our community adopts the best practices and benefits from the knowledge of all of these disciplines. However, it also means that there is not one singular activity, style, or approach that defines UX.
There are many definitions of UX (see http://www.allaboutux.org/ux-definitions). The User Experience Professionals Association (UXPA) defines it as “Every aspect of the user’s interaction with a product, service, or company that make up the user’s perceptions of the whole. User experience design as a discipline is concerned with all the elements that together make up that interface, including layout, visual design, text, brand, sound, and interaction. Usability Engineering works to coordinate these elements to allow for the best possible interaction by users.”
Whereas usability is about creating problem-free interactions, user experience is much broader and holistic. Usability is objective and product-based (i.e., a product is usable), whereas user experience is subjective and human centered (i.e., a person and a product co-create the user experience). Very often, user experience research seeks to gather “user requirements” for the design of technologies (e.g., mobile devices, websites, wearable technologies, software) or evaluate the usability of an existing technology.
User requirements refer to the features/attributes a product should have or how it should perform from the users’ perspective. User-centered design (UCD) is an approach for collecting and analyzing these requirements. This chapter introduces the basic concepts behind UCD, introduces stakeholders and their requirements, and tells you how to get buy-in for your user research activities.
Who Does User Experience?
Lots of people from many different backgrounds do work in user experience (see Figure 1.1). In industry, there are a variety of titles for UX practitioners, including (Farrell & Nielsen, 2014):
■ User experience researcher
■ Information architect
■ Interaction designer
■ Human factors engineer
■ Business analyst
■ Consultant
■ Creative director
■ Interaction architect
■ Usability specialist
At the executive level, the titles include (Manning & Bodine, 2012):
■ Chief client officer
■ Chief experience officer
■ VP of user experience
Fundamentally, UX research is about understanding people, the domain, and technology. In that sense, while we have written this book from the perspective of UX research, the methods we describe can be used in any situation where you want to understand more about human behavior, perceptions, ideas, needs, wants, and concerns and how those play out in various contexts and with various technologies.
User-Centered Design
UCD is a product development approach that focuses on end users. The philosophy is that the product should suit the user, rather than making the user suit the product. This is accomplished by employing techniques, processes, and methods throughout the product life cycle that focus on the user.
Principles of User-Centered Design
There are three key principles of UCD (Gould & Lewis, 1985): an early focus on users and tasks, empirical measurement of product usage, and iterative design.
An Early Focus on Users and Tasks
The first principle focuses on the systematic and structured collection of users’ experiences. That is the focus of this book. We will teach you how to effectively collect users’ experiences using a variety of methods.
To maximize the quality of the user experience of a product, the user should be involved from the product’s inception. The earlier the user is involved, the less repair work needs to be done at the final stages of the life cycle (e.g., after a usability test). The UCD process should begin with user experience gathering. By collecting user experiences, you can gain an understanding of what your users really want and need, how they currently work or how they would like to work, and their mental representations of their domain. This information is invaluable when creating a superior product.
Empirical Measurement of Product Usage
The focus here is on classical usability: ease of learning and effective, error-free use. This can be assessed early in the life cycle via usability testing of prototypes. Metrics such as errors, assists, and task completion rates gauge this. In a usability test, users are given a prototype or the final product and asked to complete a series of typical tasks using the product. This activity allows you to identify usability issues with your product. Then, changes are made to improve the product before its release. We describe usability evaluation in Chapter 14.
Image based on cartoon #5 at http://www.usability.uk.com/
Iterative Design
The final principle recommends that experiences are collected and the product is designed, modified, and tested repeatedly. The idea of iterative design is to fail early; it is much easier to change the user interface of an early prototype than a deployed system. This could mean that you and your team start with paper prototypes and iterate at that stage multiple times and only then move on to an interactive prototype. You do not go through the development cycle once; you continue to iterate and fine-tune with each cycle until you get it right. No one gets all the information the first time, no matter how expertly you execute each user research activity.
Incorporating UCD Principles into the Product Development Life Cycle
This book offers research techniques for every stop in the product development life cycle, but it is unlikely you will have the time, resources, or even need to do every one of them. To be successful, it is your job to identify the critical research questions facing your team, company, or academic lab and then to identify the method(s) necessary to answer those questions. Stone (2013) wrote, “To me, great UX research is four things—in this order—timely, believable, actionable, and surprising. Timely because we need to learn to work at the same pace as product teams, otherwise our direct impact on the product will suffer. Believable comes from thinking hard about the context of use and structuring your tasks to capture this context. Actionable comes from knowing the decisions the product team is facing, and being on the same page with them…. Surprising comes from understanding how to observe and report on user behavior better than anyone else on your team. This is the only trick I know. Do excellent work and do it fast, and people will notice and thank you for it.”
Figure 1.2 illustrates the ideal product life cycle with these UCD processes incorporated. The ‘Concept’ phase (Stage 1) encompasses an early focus on users. The ‘Design’ phase (Stage 2) incorporates an early focus on users and empirical measurement. The ‘Develop’ and ‘Release’ phases (Stages 3 and 4) tend to focus on empirical measurement. Sample activities in each phase are discussed in this section.
Stage 1: Concept
This is the idea phase of your product. You are:
■ Developing user experience goals and objectives
■ Creating user profiles and personas
■ Executing user experience research activities, such as interviews and field studies
Stage 2: Design
At this stage, you begin using the information collected in Stage 1 to create iterative designs. Some user research activities include:
■ User walkthroughs of low-fidelity prototypes (e.g., paper)
■ Heuristic evaluations
■ Execution of user experience research activities, such as focus groups and card sorts
Stage 3: Develop
The developers or engineers now begin to create the product. Some usability activities include:
■ Preparation, planning, and execution of pre-product release heuristic evaluations
■ Preparation, planning, and execution of pre-product release usability testing
Stage 4: Release
The last stage is when your product is released to the public or customer or within your organization. This stage often blends both user experience research activities with other types of empirical measurements. In software environments, formal usability tests are typically executed on the live code. In addition, user experience research collection for the next product release often begins at Stage 4, to gauge users’ feedback on the product that has been released in the real world. Some Stage 4 activities include:
■ Surveys or interviews to gain feedback on released code
■ Field studies to see the product being used in its environment
The third principle of UCD—“iterative design”—is employed throughout the entire cycle, as well as within each stage of the process. For example, you may do a field visit in the concept phase. This activity will begin your user experience research data collection, but may also open up new questions prompting you to run a follow-up activity such as individual interviews. You will then use the results of the interviews to go back and revise and refine or iterate your user experience research document based on your new data.
Design Thinking
If your colleagues have not adopted a UCD process, you have a larger issue on your hands. Conducting a few user research activities will not lead to a cure. One option is to consider “design thinking.”
If your company, client, or academic advisor does not understand the value of user research, design thinking can be a great way to get them to see the necessity. Design thinking is an approach to innovation that can be applied to all areas of business and practice. It does not refer to a formal step-by-step process, but to a framework and a mind-set. It is focused on a bias toward action, a human-centered viewpoint, and a mode of continual experimentation. The core idea is that by deeply understanding user needs, opportunities for innovation will emerge. These ideas can be further refined through rapid prototypes and iterations with users to result in breakthrough outcomes. The process of collecting user requirements is an integral part of this approach. The design thinking approach provides greater context so people understand why understanding users is so critical to creating great products and services. The Hasso Plattner Institute of Design (Stanford d.school) has done a good job of popularizing this approach in the d.school classes and its executive boot camps. You will now find similar workshops offered by other academic institutions and consultants. With a day or two of training, you can get a team to understand the criticality of user empathy.
A Variety of Requirements
Thanks to a growing awareness of user experience, many product teams now realize the importance of understanding their users and the consequences that result when users are unable to utilize products with maximum ease and pleasure. As a result of this awareness, many companies and academic labs have incorporated some of the UCD process into their product or scientific life cycles. For many though, user experience still begins and ends with the usability test.
There is a clear difference between usability testing and user experience research. Usability testing determines whether a given solution is usable—easy to use in an error-free manner. User experience research provides insight into the many possible solutions and allows a team to select and investigate the best solution from the users’ perspective. The difference between a good designer and the outstanding designer is the latter’s vision of solutions. Without user research, your vision is seriously limited.
Although usability testing is a critical part of an effective UCD life cycle, it is only one component of the UCD. This book is focused primarily on the user experience research stage, which often receives less attention than usability testing, but is equally important. User experience research can be used to gather “user requirements” for the design of technologies. By user requirements, we mean the features/attributes the product should have or how it should perform. Requirements can come from a variety of sources—marketing, product development, end users, purchasing decision-makers, calls for proposals, etc. All sources have valid requirements and they must be taken into consideration by the team. For example, if you are building a mobile app for booking travel, some user requirements might include the following:
■ The mobile app must be available on iOS, Android, and Windows phones.
■ Users must register with the site before making purchases.
■ The site must be available in English, Spanish, and French.
■ The site should appeal to all demographics of users.
■ Users should not require training.
We next describe the different types of requirements you may encounter, with a focus on industry settings. The advice here can be applied to other settings such as nonprofits or academia by considering the perspectives represented on your team (e.g., you may not have sales requirements, but you still have stakeholders). In all cases, by understanding a product’s “competing” requirements, you can better position the user requirements for inclusion.
The Product Team’s Perspective
In industry settings, the product team is composed of everyone who has a stake in building, deploying, and selling the product. The requirements-gathering phase is the period when the product team must do its initial research to determine the direction of the product. They must collect requirements from a variety of sources (e.g., sales, marketing, managers in your company, customers, end users) and use this information to determine what functionality will be included in the product. This stage is critical in creating a basis for the design. Poor requirements collection will impact the remaining stages of the product life cycle depicted in Figure 1.2. You will end up with a misguided product that will not sell or will be unusable and useless to the users and/or the company that purchases it.
There are a variety of different requirements that factor into product development, and there is often confusion between them. Figure 1.3 illustrates some of the many requirements and sources that a product team must deal with.
We often encounter teams who say, “We have already collected our user requirements,” but in reality, they have collected functional or marketing requirements, not actual user requirements. Below, we discuss business, marketing, and sales requirements because they are often confused with user requirements. It is important to note that each of these is important, but not a user requirement. There may be overlap, but it is critical for all of the different sources of requirements to be independently collected and then prioritized as a group. You cannot assume that what the salesperson wants to see in the product is the same as what the end user wants to see in the product. To collect the different requirements effectively, you must be able to distinguish among them.
DILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.
Business Requirements
The people who are considering purchasing your product have requirements for that product. These people are typically corporate professionals or executives. They are often referred to as “the decision-makers.” Their requirements often reflect the current business practices of their company or new practices they want to adopt to employ cost savings. They want to make sure the product matches their requirements. If you want to keep these customers, being aware of their business requirements is very important. Sometimes these requirements overlap with the users’ requirements, but often, business requirements are higher-level and/or more technical. In academia, the “decision-maker(s)” may be your advisor or thesis committee.
Marketing and Sales Requirements
The marketing and sales departments want to ensure the product sells and their requirements reflect this goal. They may have requests for features or functions that they think customers want, that competitors have or do not have, etc. Marketing requirements tend to be at a high level that lacks detail. Marketers are not interested in sending a message about the minute details of the product; they want to send high-level messages to potential customers that will lure them to the product. For example, for a travel app, they may have a requirement that the app should have more airline choices than all other competitors or that it will find the lowest guaranteed airfare.
The sales representatives are in the field with customers day-in and day-out, so the requirements they have are frequently based on what they are hearing from their customers during product demos. Keep in mind that they are usually demonstrating the product to purchasing “decision-makers” and not end users. They may have requirements such as “It needs to be fast” or “It needs to look like the number one travel app in the marketplace.” It is important to remember that these requirements may be very customer-specific and not applicable or scalable to other current (or future) customers.
Sales and marketing departments do not typically collect detailed information regarding what users must be able to do with the product, how they must be able to use it, and under what circumstances they must be able to use it; however, some marketing and sales requirements do represent a form of end user requirement. Consequently, you will likely see some overlap between the user requirements and what sales and marketing have uncovered. The reality is that if the product does not do what users want, it does not matter how usable it is. Marketing and sales folks often talk to end users, and sometimes, they even talk to them about usability, even if only at a high level. Mostly, they talk to users about features and capabilities. This is valuable information. Its weakness is that the information they collect is often incomplete, and they almost always collect it in “demo mode” (i.e., selling rather than listening). They may try to understand users, but because it is not their primary goal, they do not have time or motivation to gather true user requirements. In addition, they may encourage new features to be included in the product because the latest technology is easier to sell, not because users actually want it or will end up using it.
User Requirements
Whether you are working in academia, in private industry, or at a nonprofit, you will have stakeholders with their own goals to meet. Those stakeholders have to keep in mind the needs of a government agency that is funding the grant for your research (e.g., NIH), or private donors, or shareholders in your company. It is everyone’s job to balance user needs against business, reporting, or sales needs. But before a product or service is complete, you want to make sure that end users can actually use it and that it contains the features they need. If you ignore this important goal, increased training and support or decreased user productivity will lead to unsatisfied users. That can harm future development efforts, your scientific success, and future sales or decrease renewed licenses or product upgrades. It can also lead to a poor reputation, unhappy funders, or no new customers.
As was discussed above, you may think you understand what the end users want and need because other sources have told you on their behalf. This is the number one mistake that product teams make. In reality, purchasing decision-makers, sales, and marketing may think that users interact with the product in a certain way, but because they (decision-makers, sales, and marketing) are not the true end users, they are frequently mistaken. In other cases, they receive information from one single source that has spoken to the end user, but much gets lost in the translation and interpretation by the time the information gets to you. Figure 1.4 illustrates many of these problematic communication paths from which the product team receives “user information.”
As a result, you must talk to the actual users—the people who will use the product at the end of the day—to gain an understanding of their perspective and needs. This understanding includes their tasks, goals, context of use, and skills.
By addressing your users’ requirements, you can create a product that fulfills their needs. This fulfillment will in turn:
■ Increase sales and market share due to increased customer satisfaction and increased ease of use
■ Decrease training and support calls that result from user interfaces that do not match the users’ needs
■ Decrease development time and cost by creating products that contain only the necessary functionality
Getting Stakeholder Buy-In for Your Activity
If you are lucky, the stakeholders you are working with already know the value of user research. However, we have found that many times, the evidence about how user experience research drives innovation, acceptance, productivity, and profit has not made its way to all stakeholders. Therefore, one key skill you need as a user experience professional is to be able to effectively convince people of the importance of user research.
UX brings a huge amount of value to a project beyond just financial benefits. However, when you need to convince stakeholders to buy in to your activity, money often talks. Good UX leads to increased productivity, increased user satisfaction, decreased errors, decreased training costs, decreased support costs, increased sales, savings on redesign costs, increased audience/traffic, and better online reviews (Bias & Mayhew, 2005). Here are some specific pieces of evidence for you to use to help demonstrate the value of UX:
■ Understanding UX is critical to innovation. “Innovation is not invention. Innovation may involve invention, but it requires many other things as well—including a deep understanding of whether customers need or desire that invention” (Keeley, Walters, Pikkel, & Quinn, 2013).
■ The quality of a firm’s customer experience strongly relates to loyalty measures such as willingness to consider the company for another purchase, likelihood to switch business, and likelihood to recommend to friends and family. These factors are strongly related to yearly revenue (Burns, Manning, & Petersen, 2012).
■ Improving customer experience, even in small ways, “can translate into billions of dollars of incremental revenue per year…. No industry is totally immune from the revenue impact of customer experience” (Manning & Bodine, 2012).
■ Integrating UX early can save a huge amount of redesign effort in the long run. Sun demonstrated that $20,000 of upfront UX research could have saved $152 million (Rhodes, 2000).
Arguments and Counterarguments
Along the way, you may encounter arguments for avoiding user experience research. In Table 1.1, we present the most common arguments we have encountered and suggestions for how to handle them. On the left side of the table, there are statements you can quote directly, and on the right side are explanations of the rationale behind each quote.
Table 1.1
Arguments Against Doing UX Research and How to Counter Them
| “We don’t have time for such a study.” or “We’re already behind schedule.” | |
| “We can scale the project to the time available. We could have some preliminary information to you in as little as a day.” “Even if we cannot get the information in time to influence the upcoming release of the product, we can use data we collect now for future releases.” “A little time now may save us a lot of time later. Inaccurate user experiences are responsible for up to 60% of the errors in software production alone (Weinberg, 1997).” “Poor user experience research practices can lead to delays. Sixty-three percent of large software projects significantly overran various estimates when planning and many of these relate to poor UX (Lederer & Prasad, 1992).” | A little information is better than no information. You want information to make an impact as soon as possible, but do not let this prevent you from collecting information altogether. It is fast and easy to show cases where products went wrong and could have been saved by conducting user research. See Hackos and Redish (1998) for a plethora of case studies. See also Johnson (2008), GUI Bloopers 2.0,Chapter 8, Management Bloopers. There were 24 different reasons for the inaccuracies in the estimates, and the four with the highest responsibility were related to a lack of poor user experience gathering (Marcus, 2002). |
| “We don’t have money for such a study.” | |
| “We can conduct a study for very little money.” “The return on investment for creating a good user experience is very high. In a 2011 study, customer experience accounted for between $31 million and $1.2 billion of revenue.” “Our competitors know the value of user research.” “Incorporating ease of use into your products actually saves money. For every dollar spent to resolve a problem during product design, $10 would be spent on the same problem during development, and multiply to $100 or more if the problem had to be solved after the product’s release.” “We don’t have money NOT to conduct such a study. The maintenance costs of unmet user needs can account for 80% of lifecycle costs.” | Discount techniques are cheap. Start small and demonstrate value to build upon. User experience is an investment in future revenue (Forrester’s North American Technographics Customer Experience Online Survey, Q4, 2011 (US)). Understanding your users provides a competitive edge. It is far more economical to consider user needs in the early stages of design than it is to solve them later. Robert Pressman calculated the cost at design, development, and release in Software Engineering: A Practitioner's Approach (IBM, 2001 via Marcus, 2002). Eighty percent of software life-cycle costs occur during the maintenance phase. Most maintenance costs are associated with “unmet or unforeseen” user requirements and other usability problems (Pressman, 1992 via Marcus, 2002). |
| “It’s not our problem if users are stupid.” | |
| “You are not the user. Just because people aren’t like you (e.g., don’t know every keyboard shortcut by heart or can’t recall 25 different 30-character passwords) doesn’t mean they are stupid. Not everyone has had the same experiences and training as you.” | Findings from user research can help show stakeholders (often engineers) that even other very smart people do not use products the same way they do. The key to countering this argument is to help stakeholders realize they are not a good representation of the people who will be end users. |
| “Users don’t know what they want,” or “If you asked users what they wanted, they would have said a faster horse.” | |
| “It’s not the job of the users to be able to articulate exactly what they want or need. It’s my job to study how people behave and what they need. I elicit relevant information from them and translate that into useful, actionable information.” | Understanding users is a skill that takes training and practice, just like all the other roles in product development. Users should not be mistaken for designers. It is the UX team and the product team who are responsible for providing potential solutions. |
| “We don’t want to ruin any potential deals or make the customer unhappy by pointing out what our product doesn’t do.” | |
| “When systems match user needs, satisfaction often improves dramatically.” “In all of our years of conducting user research and usability tests, we have never caused our company to lose a deal or caused a customer to be unhappy with our products. User experience research improves relationships with customers because they see your company is trying to understand them and their needs.” | In a 1992 Gartner Group study, usability methods raised user satisfaction ratings for a system by 40% (Bias & Mayhew, 2005). If customers perceive that the product development or sales team is not meeting their needs, this will lead to unhappy customers and frustrated developers or salespeople. |
| “Sales owns the customers.” | |
| “We are all responsible for creating a user experience that is pleasant and satisfying for users.” “If sales does not have time to help us find participants, we can figure that part out on our own.” “It’s our research.” | Other stakeholders may fear that you will undermine their position and authority. Reassure them that UX has different goals from sales and your work will help them achieve their goals. In the end, if you cannot get access to customers, there are other ways of accessing end users (refer to Chapter 6, page 139). See Sharon (2012), It’s our research getting stakeholder buy-in for user experience research projects, for a thorough introduction to helping the team take ownership of UX. |
| “You’ll make promises we can’t keep.” | |
| “We will not make any promises to customers. We will listen and collect data only. The team will make decisions about how this information will be used in the product.” | Participants understand that you are seeking their input and will not expect you to immediately create a magical product that fits all their desires, and you will not promise to either. |
| “You’ll let out confidential information.” | |
| “We have all our participants sign a non-disclosure agreement.” “We will develop a standard script and pass it by everyone for review prior to using it with any participants.” | If it is obvious to your participants what you are working on based on your questions, non-disclosure agreements (NDA; refer to Chapter 3, page 76) can be put in place to keep them quiet. |
| “We have information already. Why collect more?” or “I’ve been in this business for a decade. I think I know what our customers want.” | |
| “That information is good and we do not intend to replace it. However, we need additional information to supplement what you have already learned.” “The methods we use and goals we have are different from those that were used to collect that information. We want to make sure we have unbiased, empirical data.” | Show how the information you plan to collect will be different. For example, you want to interview actual end users, not purchasing decision-makers; or you want to learn how users currently complete tasks, not get feedback on a prototype. The product team may have already conducted their own “focus groups,” the marketing department may have already interviewed potential users, or the sales team may have already conducted their own “site visits,” but these teams have different goals. |
| “We are introducing a different process, so don’t waste your time studying the current process.” | |
| “We need to understand the user’s current environment, even if it will change to understand what challenges we may end up facing when changing the process.” “We need to understand how people currently work, so we can leverage the good and leave the bad behind.” | You also want to understand a transfer of training. You could end up designing something that is incompatible with current practices. You also need to understand the ripple effect of your changes. You may end up inadvertently affecting other groups/systems/customers. |
| “This product/process/service is completely new. There is nothing to observe.” | |
| “If the potential users do not exist, who will buy the product?” “There is always someone or something we can learn from to inform your designs.” | How was a need for the product determined in the first place? There has to be a manual or automated process currently in place. Look for the non-obvious. |
| “Everyone does it differently so there is no point studying a few users.” | |
| “There will be individual differences. This is why we want to study a range of users and environments.” “Studying even five users can reveal 80% of the most critical issues users may encounter.” | The differences may also be smaller than everyone assumed. If the differences are large, knowing that is important. Studying “a few” users can be useful (Nielsen, 2000). |
| “We’re changing just one part of the system/product/environment. We don’t need to study more than that.” | |
| “The most successful systems are developed when all parts integrate seamlessly—and this cannot happen if we only consider each part in isolation.” | Systems are much more interrelated than most people realize. You need to understand the context that the change fits into. Users do not work in isolation. |
| “We don’t need this method. The product is only for our own organization. Plus, the time you’ll take with our employees isn’t billable.” | |
| “The productivity hit is actually twice as bad when an unusable product is implemented in your own organization. Employees are less productive and they depend on the support of people in your organization to help them.” | Frame the time as an investment. Time that is spent now will save time, and thus costs later. Try to schedule participants during time that employees are not at their max productivity. For example, are there some people who are between contracts? |
Preventing Resistance
The best way to combat resistance is to avoid it all together. There are two ways to accomplish this:
■ Get stakeholder involvement.
■ Become a virtual team member.
Get Stakeholder Involvement
One of the key themes that is reiterated throughout this book is “getting your product team (or stakeholders) involved.” You want them to feel ownership over the activities that you conduct. You want to have their agreement and buy-in that user experience activities will benefit their product. If they do not believe in what you are doing or are skeptical, then they will likely be hesitant to implement your recommendations after the execution of your activity. To gain acceptance of user research, you need to involve them in all stages of the activity—from the preparation stages to the recommendations stage.
Become a Virtual Team Member
If you are not organizationally a member of the product team, you will want to virtually become a member. From the moment you are assigned to the project, you will want to work to become an active, recognized member of the product development team. You want to be perceived as part of the team; otherwise, it is too easy to be forgotten in the distribution of critical information or in a meeting that is deciding directions without critical input that you can provide.
If you work in a consulting capacity, the product development team may view you as an outsider. Even if you are a dedicated resource to that product, the developers or management may not view you as a team member because of your unique skill-set. Deliverables such as your activity proposals and activity findings may not be taken with the same sense of ownership if you are not seen as “one of them.” The product team may even feel that you are not knowledgeable enough about the product to be taken seriously. Clearly, this is a detriment to your work.
The ideal situation is when you can become a virtual member of their team. You need to be as knowledgeable about the product and the factors that feed into the process as possible. You want to be perceived as someone who contributes to developing solutions for the product, rather than just identifying problems with existing solutions. This may require you to develop technical expertise and attend weekly staff meetings that do not always apply to user research and design. You will need to gain the respect and trust of the team, and this takes time. You are not there to sabotage their hard work; you are there to help them develop the best product they can. To do this, you need to understand how user research fits into the big picture. Of course, user research is critical for a successful product, but you must be willing to acknowledge that the users’ needs are not the only requirements.
The earlier you can get involved, the better. The more time you spend with the team and the more familiar you become with the product, the more the team will respect you and your effort.
What Is Next?
Now that you know what user experience is, who does UX research, the principles of UCD, the stakeholders you will work with, and how to get buy-in for your research, it is time to start planning your user research activity. In the following chapters, we will teach you what you need to do before you choose a research activity, what ethical and legal issues you should consider, how to set up space in which to conduct user research, and how to choose and prepare for your user research activity.