As an industry, people who develop software and online services have taken great leaps over recent years in developing attractive, usable products. But there can still be a reluctance to test things early and often with users – especially if you’re developing for internal or enterprise users.

If you’re developing software and not testing it with users, you’re missing a trick – your software will have problems you don’t realise (making it harder or slower to use) and if you wait until the software’s released to find and fix those problems, it will take a lot longer and cost a lot more.

Often, people don’t usability test because they perceive it as difficult, time-consuming, or expensive. One of the techniques we use at Avecto is guerrilla usability testing. The idea is to use the equipment you already have and go to where users might be, which makes guerrilla usability testing simple, quick, and cheap.

Deciding what to test

Usability tests are based on the idea that you ask people to do realistic tasks with your product, and observe how they behave. A guerrilla usability test is just the same, but as the test needs to be relatively short, you need to pick a small number of important tasks to try.

When you’re deciding what you test, think about which are the things people might perform when they first encounter your product, things that are particularly important for them to succeed at, or perhaps areas where you’re least confident about the design.

Prepping the test

Think about the materials you’ll need to test those tasks. It could be the software you’ve built, or a prototype of it (even paper or other low-fidelity prototypes will give you great information). Remember that a prototype (or the software) doesn’t need to do everything or be without bugs: it needs to be just enough to test the tasks.

List out the tasks that you’re going to ask people to do. You need to be able to describe them to participants in a way they’re going to understand but without giving them information on how they should do it. Keep it to a small number of tasks – including your introduction and any questions you’re going to ask, try to keep the whole test to 15 minutes or less.

It’s then worth trying out your tasks and prototype with a colleague or friend, just to check everything’s clear and works as expected.

Finding your participants

The key to any usability test is representative participants – people who have similar characteristics to those your software is for. This doesn’t mean they need to be exactly the same people though. Figure out what the important characteristics are, and then think of where people like that might be.

For example, if your target market is students then you’ll probably find them in the university library or coffee shop. But if it’s people who claim expenses in your company, you’re more likely to find them queuing up at your work canteen. If you can find a place that’s similar to where or how your product will be used (for example noisy/quiet places, people’s own devices) that’s an added bonus.

When you’ve thought of places those people will be, you may need to check with someone managing that space if they’re happy for you to collect some feedback there.

Running the session

Now you’ve got some tasks, something to test, and somewhere to go. All you need to do now is go there and find some people to take part!

Make sure you’re got a couple of helpers – this will make it easier to get participants, run the sessions, and take notes. It also lets them see for themselves the problems users encounter with the software.

A few things to think about are:

  • Power and peripherals, if you’re running a test using software
  • Print outs of any materials you need to give participants
  • Whether you need an internet/network connection (it’s easier if you don’t)
  • Finding a good place to sit that’s relatively quiet but not out of the way
  • Whether you’ll offer something to people to take part – paying for their coffee or lunch or a small voucher is a great way to encourage participation
  • How you’re going to take notes – a simple system to record what goes well (and badly) will help you analyse the results. You don’t need to take masses of notes, and doing so could make the participant anxious

The hardest bit can be getting up the courage to ask passers-by to take part. Be brave! If you explain that you’re looking for their feedback, how much time it’ll take, and the incentive (if you have one) you’ll find that many people will be happy to help.

During the test itself, it’s important to explain what you’re doing, be reassuring to the person taking part (it’s the software that’s being tested, not them), and attempt to keep your mouth shut as much as possible. Remember that you’re here to observe their behaviour as much as you can, and to learn about what doesn’t work well.

Using the results

The best time to analyse the results from your sessions is straight afterwards while it’s fresh in your mind. Get together with the other people who ran the test and pool what you’ve learnt. Identify the most important problems you observed and then take them back to your wider team to decide how to fix them.

Rinse and repeat

The beauty of guerrilla usability testing is that it can be very quick, cheap, and simple to run. But don’t think of it as a one-off activity; rather as something you can repeat regularly to see whether changes work and to constantly re-evaluate new functionality or designs.

Pack up your excuses in your old kit bag

If you’re involved in developing software – whether it’s for individuals, companies, or for internal use - you might have been scared off usability testing by the need for budget, equipment, or time. With guerrilla testing, you can quickly and cheaply get priceless insight to help you develop better software faster.

So pack up all those excuses, and get going!

Further reading

7 Step Guide to Guerrilla Usability Testing

10 tips for 'ambush guerilla user testing'

Doing pop-up research