Getting to know you: User research fundamentals anyone can use

Editor's Notes

• #7: The quote by Hackos and Redish is actually about user and task analysis. The two are frequently paired with good reason, but they answer different questions. If you are conducting a single activity to conduct both user and task analysis, you need to be certain to understand in detail what questions each should answer. Coe speaks of the “users’ psychology.” This understanding provides the proper foundation for development.
• #8: The quote by Hackos and Redish is actually about user and task analysis. The two are frequently paired with good reason, but they answer different questions. If you are conducting a single activity to conduct both user and task analysis, you need to be certain to understand in detail what questions each should answer. Coe speaks of the “users’ psychology.” This understanding provides the proper foundation for development.
• #9: Several reasons users may not know what they really need: faulty memory, limited perspective, resistance to change How can the final product ensure user satisfaction?
• #13: Who: Categories of users; business plan, marketing research, and other business analysis artifacts may define users Tasks: Business artifacts such as marketing research and competitive analysis may inform this, but you may also discover some tasks while conducting user research that were not uncovered through other means Questions: What do you need to know to develop the product? The questioning process is iterative. You will probably want to refine your questions at each round of user research if you are able. If you are not able to have more than one round of research with target users, consider using surrogates, including family and friends. Method: More on the next slide, but in general, watch them or ask them (Summers and Summers) Plan and conduct: Working directly with users is often a ticklish business. Sales, account reps, marketing, and other business people may be protective of their contacts. Developing a plan that allows them to participate in the planning process to gain buy-in and allay any fears that you might adversely affect their business relationships. Beware common objections to direct interaction: “Marketing already knows the users. We don’t have enough time… money…. We are users ourselves.” (Hackos and Redish) and many more. Present: A bargaining chip to use with other stakeholders—you will be acquiring information they might need. Also, useful to demonstrate value of research as well as share the data with other stakeholders and team members. First step to getting team members to consider user satisfaction in the project plan.
• #14: Not meaning that a big MS Project Gantt chart is required. As simple as the bullets shown here.
• #15: Research will evaluate these goals to see where they match and where they differ. Look for gaps and questions that don’t even have a starting point.
• #17: Training includes what users have had and what they can realistically expect to receive. Age ranges example: ages of insurance underwriters were considerably higher than that of their assistants. These older workers had already managed to work around and even outside the current computerized system by transferring the burden to the assistants or by relying on manual means that were still available. Usage constraints: accessibility questions fall in this category as well as management imposed constraints among others.
• #19: Immediate managers of users will likely err on the side of what should be done vs. what is actually done to perform a job. Research: if you can’t get to users, this is the only way to answer the questions. Recent experience with start-ups has meant relying on research as the primary means of learning about target users. Anticipating a user advisory board, but marketing is arranging that and expect some bias.
• #20: Krug: “Recruit loosely, grade on a curve.” More niche the product, the more important it is to recruit target users (domain knowledge) Honoraria and motivators
• #21: Users get hung up on the data. For target users, get meaningful and plausible data. Provide some so users don’t expend brain cycles making it up.
• #22: Methods: Barnum, Chisnell and Dumas, and other resources
• #23: Methods: Barnum, Chisnell and Dumas, and other resources
• #25: Audio: Good quality microphone
• #27: Surveys and questionnaires: May misrepresent their view to make themselves look better or provide the answer they think management wants, may forget or believe they do things differently than they do, may lie because they are hostile to the project at all. Feedback: Especially from previous versions Usage tracking: Better for task analysis, but can reveal superstitious behavior (DOS delete followed by directory command) Interviews and focus groups may not provide access to real users, but instead provide at best a limited subset of the total user group (frequently the experts). At worst, these are interactions with direct managers, former users who have moved on to higher responsibilities, and the purchase decision makers (high-level management). Additionally, focus groups introduce group dynamics and a dynamic personality may dominate more passive personalities. If this is a concern, you as the usability expert must provide opportunities to get complete input from those passive personalities Usability testing should come at all phases of the development life cycle and ideally supplies any updated information to enhance an existing user profile. Observations may be remote (video of a factory line, observation deck of a auction flow) while site visits are actual users in their real environment.
• #31: Even if it’s just you, make others aware as appropriate People to share with include peers, team and project leads, and management Recognize the limits of your data Avoid forcing more conclusions than the data support Acknowledge the other constraints (business drivers, schedule, budget, and so on) on development when making recommendations Recognize that the details that may grab your attention may not be that significant If you slant the results, you will get caught
• #32: Hackos & Redish confirm that the types of analysis you apply depends on your project: New product: detailed user profiles including outliers Legacy product: list of the user skills compared with what they will need The information gathered in the user analysis will benefit all members of the project team; however, the other team members may not be quick to realize the benefits. Make the information readily available and publicize that availability. Put up posters about users. Understand how your team views usability, whether they actively support your activities by collecting and sharing information themselves, whether they expect you to provide all the relevant information, whether they support the idea of usability at all. Understand their experience with using direct user data. Less experience means a slower pace. Don’t try to force them to accept your conclusions.
• #33: The quote by Hackos and Redish is actually about user and task analysis. The two are frequently paired with good reason, but they answer different questions. If you are conducting a single activity to conduct both user and task analysis, you need to be certain to understand in detail what questions each should answer. Coe speaks of the “users’ psychology.” This understanding provides the proper foundation for development.
• #34: The quote by Hackos and Redish is actually about user and task analysis. The two are frequently paired with good reason, but they answer different questions. If you are conducting a single activity to conduct both user and task analysis, you need to be certain to understand in detail what questions each should answer. Coe speaks of the “users’ psychology.” This understanding provides the proper foundation for development.
• #38: Hackos and Redish list (pg. 13) The objections have a grain of truth in them that provides a resource to you. Formal request may be for a whole series of user interactions or for a single opportunity. Either way provide a detailed account of your goals for the analysis. Develop a usability life cycle plan that mirrors current development lifecycles. The process of user analysis will lead to new questions and new needs for information. Change also means that as the mental model of the user unfolds, some design decisions may need to be revisited.
• #46: From “Creating Effective User Surveys,” originally presented with Caroline Jarrett