The project lead shared his estimate for the development of the proposed API: 21 business days with four resources. The project requirements were to migrate the features and functionality of a legendary network-monitoring application to a new Web-based application.
The initial project meeting started with an analysis of each of the existing features, during which the team discussed them in detail. When the discussion moved to a feature relating to a Network Monitoring widget, the product owner was very keen to enhance the feature. He believed it would be one of their key selling points once the product launched. Even promotional activities would focus on this feature. So he proposed some concepts for enhancing this feature and had an in-depth discussion regarding them with the marketing and sales teams and technical managers. The project team came up with an estimate of the effort necessary to meet the product owner’s expectations.
Champion Advertisement
Continue Reading…
The stakeholders discussed various aspects of this feature, but a few of them were unconvinced about certain ideas. Since the discussion was going nowhere, the technical lead suggested bringing in a team member who had previously worked on this product to get her input before making a decision. So they called in this team member, explained the context of the decision they needed to make, and asked for her opinion. The team member’s totally unexpected response took the whole group by surprise:
“In my experience with the application, I hardly used this feature. I had almost forgotten about the existence of this feature until you brought it up here. There are better shortcuts to get the same details. I might have used this feature a couple of times in the past three years.”
Most of the stakeholders assumed she was an amateur who hadn’t had much exposure to the product, so they decided to get opinions on this feature from seven to nine engineers who had been using this product for nearly three years. The results were the same: they had hardly used the Network Monitoring widget. Since users rarely used this feature, the project team decided to remove it.
By conducting a simple survey, the team was able to save 21 days of effort by four resources, which would have enhanced a feature that users seldom used. Obviously, the effort it took to survey several engineers about the feature was far less than developing the feature would have required. Plus, the new functionality would have cluttered the user interface rather than adding value.
The Need for User Research
The scenario I’ve described could have been avoided if the project team had been more proactive and involved potential users of the product during the first stage of product development. By conducting user research, the team could have better understood users’ behavior, attitudes, and needs and made better-informed design decisions to address their needs.
However, teams that are redesigning a product sometimes do not have access to the product’s actual users. In such cases, a team needs to create personas to identify appropriate participants to recruit for user research—personas that represent the target users of the product. Figure 1 shows an example.
Figure 1—Example of a persona
A set of personas should itself be the outcome of user research during which a project team interviews and observes various prospective users. Each persona describes the needs and painpoints of a particular type of user. On the project I’ve described, if the team had done user research and defined a set of personas, they could easily have avoided spending time on an unwanted feature.
The Impact of Budgetary Constraints on User Research
Nevertheless, most development projects have tight budgets and timelines, so project teams often prioritize and allocate their budgets to what they consider to be more critical tasks. Often, they come to understand the importance of user research only when it is too late, if they do at all.
But user research is a proven methodology that helps prevent unnecessary rework and ensures a better experience for users. Plus, the cost of user research is usually much less than the cost of making whatever fixes would prove necessary to address problems that result because of a lack of user research.
User-Research Methods
The cost of user research depends on the feedback-collection and observation methods a team uses, as well as the number of rounds of research a team conducts and the number of participants in each round of research.
You can obtain the richest qualitative data by conducting user interviews or contextual inquiries.
User Interviews
In this popular research method, an interviewer asks questions and records participants’ responses to discover potential users’ attitudes, beliefs, and experiences. The interviewer usually conducts each interview speaking with an individual participant either face to face, over the phone, or using video streaming. Because of the one-on-one nature of these interviews, the interviewer can address any individual concerns or miscommunications directly. Depending on the context in which the interview occurs, the interviewer may also be able to capture verbal and nonverbal cues such as emotions, facial expressions, and body language. Ideally, conducting interviews requires a team of people to facilitate them, capture notes, and record the sessions, so it may be difficult to keep personnel costs down.
Contextual Inquiries
When conducting contextual inquiries, a user researcher can collect detailed information about users’ work practices by observing and interviewing them in their actual work environments. The researcher takes a back seat and lets the prospective user take the lead as much as possible. This method of research helps the researcher to understand users’ everyday tasks. Its objective is to understand how and why a user performs a task—or why the user chooses not to perform a task or is unable to perform a task successfully. Again, it’s a process that involves one-on-one interactions and requires travel to each user’s workplace, resulting in increased costs.
Cost-Effective User Research Methods
However, user research does not always have to be expensive. While interviews and contextual inquiries are the most effective user-research methods, there are other alternatives that are more cost effective and still deliver useful results. These techniques are generally faster for individual participants and let you collect data from multiple individuals. Because these techniques are less time consuming, they are also less expensive. Plus, they can cover a wide range of users in a short span of time.
These alternative data-gathering techniques include focus groups, facilitated workshops, surveys, help-desk data logging, and Web analytics.
Focus Groups
In focus groups, a facilitator leads a group discussion or brainstorming session. Optionally, an observer can document key inputs from the participants. This method helps save time because focus groups involve multiple participants.
Facilitated Workshops
While facilitators lead focus groups to gather inputs from a group of prospective users, facilitated workshops also involve the technical team. Interacting with prospective users directly helps key stakeholders to get rapid feedback on critical issues. However, the danger exists that stakeholders might attempt to justify their solution during discussions with users. But, with a good facilitator, the team should be able to avoid this.
Surveys
Surveys cover a larger user population than any other research method. Targeting a specific user group ensures that the results are more accurate, helping you to make better design decisions. There are many types of surveys, including online surveys, paper surveys, telephone surveys, and social-media surveys. You can automate data collection and analysis to reduce time and cost.
Customer Data from a Help Desk
Monitoring customer-support phone calls, email messages, chat conversations, and in-person requests helps teams to identify users’ painpoints. Thus, you can gather valuable data on where users are getting stuck or are repeatedly facing the same issues. This data can help you identify what areas of an application to focus on and suggest specific solutions to issues. It also helps you to understand the user’s vocabulary.
Web-Analytics Logs
Web-analytics logs provide rich quantitative data on what actions users take on specific pages and how many users take each course of action. This data helps you to evaluate the success or failure of a design and identify areas for improvement. This data also provides input for other direct and indirect data-gathering methods such as interviews and surveys.
Conclusion
User-research data provides valuable information about your potential users, their needs, behaviors, and painpoints. While user research methods such as interviews and contextual inquiries provide the richest qualitative data on users, there are alternative methods that are more cost effective and time efficient.
The persona-creation process should be informed by research and an intimate knowledge of an established user base. Personas can help you create better design solutions for a particular user base. They are useful not just during the design process, but also in validating that your designs meet users’ needs.
Ignoring the benefits of user research can lead to designs that are based on assumptions and personal opinions and are limited to the concepts and ideologies of the developers or designers on your team. Applications that teams design without involving users will likely fail to address their needs.
Lead Interaction Designer at HCL Technologies Ltd.
Chennai, Tamilnadu, India
As a Lead Interaction Designer at HCL Technologies, Saravanan focuses on integrating the voice of the customer into UX design and advocating for a better, user-inspired experience. He’s found that by combining his research skills with his artistic sensibilities, he can speak the language of both the customer and the designer. Saravanan is a certified usability analyst. Read More
