User testing involves watching people use your site or app to see what difficulties they have. Guerrilla user tests can take a few different forms (covered below) but what they have in common is that they are relatively unplanned and quick to conduct. They're traditionally done in-person.
Guerrilla tests are good for checking a user journey in the form of a clickable/tappable prototype. They sit in-between design testing, which I would use for checking individual screens or elements, and a longer form of user testing such as remote testing, which is better for live websites.
The main purpose of these tests is for sense-checking your work as you go along and for testing out how a flow works together. You'll discover usability issues with your work and whether people understand what they're interacting with. It's missing some of the scientific rigour of other user testing methods but it certainly beats sitting around and theorising or guessing at what users are going to do.
First off, a bit of preparation: think about what you're testing and decide the tasks you want people to carry out on your design (two or three tasks is about right for this type of test). If you're just showing a single screen then decide what your primary question to them will be (and make sure it isn't a leading one).
It’s worth noting down in a simple script what you want to say so you're consistent with each person. Also make sure you have a way of recording the feedback: write it down immediately after or make a video recording with your phone.
The main challenge for this type of test is finding relevant people and getting them to try out your design or prototype. Five users should be enough to give you useful feedback but if it's quick to get a couple more then do so.
Here are some options for finding people to test with:
After testing you should always spend a bit of time going over your results and writing them up in some form. You might think you can remember what the issues are but it's surprisingly easy to forget one or two a few days later.
Sort the usability issues into a rough priority order of severity, and also include the things that users liked about the site. You can put your test results in a lightweight testing report so you have a record for yourself and others to refer to in future.
Testing with other people who work on your project or in your team is fairly useless. They are going to have such a clear idea of what you're doing that they won't ask the ‘obvious questions' or test your assumptions.
Don't develop long tests with multiple tasks to go over. People's attention will wander pretty quickly and if you’re testing a prototype it will probably lack the realistic detail to sustain a long test.
You should be aiming to take about 5-10 minutes of their time. If you've got a big prototype then focus on the things you're most unsure about or run multiple guerrilla tests.
It can be hard to do it all on your own (especially in public) so you might need someone else to help. They can note-take or record while you engage with the user and build a bit of rapport. If there’s just one of you having to do both tasks then you can miss important things (and it can look like you’re ignoring the user).
A test that isn't recorded may as well have not happened, as you’ll have no evidence to point to if people challenge your findings. By getting it written down and having video clips you can share your findings with others. Definitely don't write a long report though or you're defeating the objective of speed.
You’ll need something to test on (your laptop, tablet, or phone) and you’ll need something to record with (another phone, QuickTime screen recording). Obviously these cost money but you’re likely to have access to them to design with so it shouldn’t cost any extra.
It can be as quick as an hour or two to run five tests but I recommend spending half a day to properly record and analyse the results.