🍌 Banana
"Of the three layouts, is the first your favourite?"
Lesson: Do not use leading questions.
Better: "How might you rank these three layouts in order of preference?"
As you start research on a new possible feature, you reach out to your 3 go-to contacts.
Lesson: Don’t build for the few.
While they are Geotab champions, and are accessible, consider branching out.
Lesson: Beware of "Polite Confirmation”
Vague responses are a sign that the interviewee is being nice, and not providing valuable insight.
In an interview with a user, they express how impressive your work on the prototype is, and that it looks very nice.
Lesson: Beware of "Polite Confirmation"
You're seeking feedback on the product/feature. Overly nice, or vague compliments may be kind, but shields you from honest input.
One month away from deployment, you organize some interviews with users to validate what the market research report suggested as a feature.
Lesson: Interview at the problem stage.
While market research is a great resource, direct user feedback is critical before development kicks off.
"We are looking into 5 possible features, most people we've spoken to said 2 and 4 are the most critical. Would you agree?"
Lesson: Do not use leading questions.
Lesson: Avoid social bias.
Avoid leading people into solutions before validating the problem, and avoid introducing peer pressures to your interviews.
In an interview with a user, you feel an awkward silence and speak out to make the interviewee feel comfortable.
Lesson: Let the user talk (and think).
Silence isn't a bad thing! People need time to think.
"I surveyed 20 people who said they struggle less with communication than they do with analysis, does that align to what your team struggles with?"
Lesson: Avoid social bias.
Better: "can you explain or show me what your team does?"
"We are deciding between two options: filter A or filter B. Lets just focus on filter A. How would your fleet manager use this?"
Lesson: Ask about the past, not the future.
Lesson: Do not use leading questions.
Avoid leading people into your own preferences, and focus on the current problems, rather than predicting behaviours.
During an interview, the interviewer asks "what would you do with this kind of a report?"
Lesson: Ask about the past, not the future.
Better: "how do you navigate this process right now? What are the pains, what works well?"
In an interview, a user says "x is useful but y is what my team usually struggles with". The interviewer parks this comment, and is able to direct the conversation back to the feature being built.
Lesson: Identify the "Why."
Better: "you mentioned y, could you elaborate on that?"
"Last time we spoke you said consistency is important to you. Requirements for this prototype are being scoped by engineering - does this meet your expectation?"
Lesson: Avoid pre-committing.
Showcasing prototypes prior to development should remain as focused on the core problem as possible.
After developing a new, high-traffic feature, you decide to interview a handful of users you speak with frequently.
Lesson: Interview at the problem stage.
Lesson: Don't build for the few.
Validate the problem's merit early, before developing anything. Ensure you're validating assumptions with a diverse group of users.
After a very engaging call with a huge client, you develop a detailed prototype using Figma Make, and organize a follow up interview to show the feature's components.
Lesson: Show the concept.
Focus early exploration on validating concepts and problems, not detailed features.
As the interview is only 15 mins, you as the interviewer skip formalities and dive right into the content of you prepared script.
Lesson (surprise addition): Build rapport.
Build a relationship before asking people to unearth their challenges. It leads to honest input grounded in trust.