User:JKlein (WMF)/guerilla-user-testing
Quick summary edit
What is guerilla user testing, and why should I do it? edit
Martin Belam defined guerilla testing as “the art of pouncing on lone people in cafes and public spaces, and quickly filming them whilst they use a website for a couple of minutes.” While this is an accurate definition, we can expand upon it by using the term to apply to testing any product produced in service of Wikimedia, at any fidelity. The basic idea is that this is a method for testing out product ideas on real humans in an inexpensive way.
Here are a few times that you should consider performing this kind of testing:
- To test: When you have a product in beta and are looking for bugs
- To think: When you have a proof of concept and you want to experiment with it to see where the idea goes
- To learn: When you want to gain a better understanding of how your users are currently using a product
What do I want to learn from testing? edit
Before showing up to an event with your product, think about who you want to test with and what you want to learn from your test.
Here are some tools that you can inform your decisions:
Personas edit
Personas give us a person to connect with, someone who has goals for using the product, ensuring human centered design. Typically you will have a user in mind when you are creating a tool, you use this information to think about recruiting people or meeting these user types in places that they already inhabit, such as an Edit-a-thon or IRC channel.
Journey Mapping edit
Map your personas to a happy path. Use journey mapping as an exercise for determining a list of requirements for your project as well as uncovering hidden issues. This will help you to consider what you to do with participants who volunteer to test and will inform your script writing
Hypothesis Definition edit
Defining our solutions through a hypothesis framework allows us to acknowledge that we are making assumptions and testing those assumptions through our prototypes validates our hunches. This will ensure that you know why you are prototyping and testing. With this information you can figure out if you are using the right method and/or prototype to validate your hypothesis.
Where to test edit
- Edit-a-thons
- wiki salons
- chat platforms
- On Wiki
- usertesting.com
Pre-event edit
You've decided what you want to learn from your test, so now you need to do all the prep to make sure that it happens smoothly
Collaboration edit
If you plan on showing up at an event, it's a good idea to connect with the event organizers.
Script writing edit
Write out what you want the testers to do as well as the person who is conducting the testing
Testing devices and Prototypes edit
Think about where you want folks to test.
- paper prototypes
- nonfunctional clickable prototypes
- In production on Wiki - on desktop, mobile, tablet
- on the web or on app
- In a test environment
Sandbox wiki pages edit
- how to make
- where to make
- why to make
Recording devices edit
- screen recording
- video
- audio
- data logging
- microphones
- headsets
Materials to advertise who you are edit
- business cards
- swag
- signs
At the event edit
Testing edit
- introducing yourself
- getting over the jitters
- going with the flow
Analyzing edit
- have a set of questions that you are trying to always get the answer to
- have a notepad for anecdotal and unrelated findings
Real-time iteration edit
- do you need to change your questions, framing, script ?
- do you need to massively fix the prototoype?
- can you make a tweak on the fly?
Testing with remote participants edit
special considerations
Post-event edit
Synthesizing feedback edit
- Write findings
Feedback Party edit
- Share with your team
- Work openly
Identifying next steps edit
-proposed solutions and/or plans for solving