This is a guest post by Emily Goligoski who is a Design Researcher on Mozilla’s Open Badges. You can read more of her thoughts on design and research on her blog and on twitter as @emgollie.
Research is a tool–a periscope offering you a better view of your surroundings. It can be very powerful if applied thoughtfully. Rather than piling on the costs, research can save you and the rest of your team a ton of time and effort.
In featuring this in the early pages of her book, Erika Hall had me nodding, highlighting, and bookmarking early into reading “Just Enough Research.” Hall, a Mule Design co-founder who shares design research musings as @mulegirl, joined a group of UX Book Club-goers at Mozilla’s SF offices this week. One of the topics that came up first was presentation: how we as researchers describe ourselves (“customer advocate” and “user developer” were amongst the suggestions) and our methods (including “fast insights testing”) to potential skeptics. The author encouraged the group of 20 to consider the mental models of research that naysayers of the field may have. Resistant clients and partners may simply be unfamiliar with what they can expect from professionals’ processes–including that they, too, are expected to be observant of users’ behaviors throughout the process.
Additional ideas suggested by Hall and readers taking part included:
- Don’t recruit people without an incentive. You may inadvertently solicit customers who have an axe to grind, she warned. Even if the acknowledgement or reward for participation is a gift card in a small amount, it gives more options for recruitment and helps in avoiding opt-in participation by disgruntled users who just want to speak with someone–anyone–representing the product.
- Get product managers, engineers, and everyone else on the team to answer customer service calls at least once a month. Hearing questions and confusion from users directly (and during a time that isn’t set specifically aside for testing) creates more empathetic organizations. On the Open Badges team we’ve experienced this recently–the more that people working on the product are hearing from users of it directly (as opposed to second hand), the more all users benefit.
- Usability test your competitors. Seeing what delights your users–as well as what frustrates them–outside your product can be enlightening. I recommend bringing in development team members for this portion of your research too. I would love thoughts from others who have integrated this form of testing into their plans: What did it tip you off to? How much time did you dedicate to it? Thoughts appreciated.
For more information on the book club you can join our Facebook group or follow us on Twitter at @uxbookclubsf.