Designers characterised by clever, unusual strategies. Guerrilla User Testing.

guerrilla: a member of an irregular armed force that fights a stronger force by sabotage and harassment. The word ‘Guerrilla’ quite often conjures up notions of left field irregular strategies and popular terms such as Guerrilla Warfare is something which rests in many peoples minds, even if they know nothing of the subject and its history. ‘Guerrilla’ comes from the Spanish language and literally means ‘war‘ (guerra) and is said to have been used to describe “The Guerrillas of Spain” in the Peninsular War (1808-1814).

Lets apply that term to user testing…

The English term comes from the irregular way in which the Spanish army used guerrilla tactics to defeat larger forces. They did this by remaining small and mobile, then seek to defeat smaller units of soldiers to weaken the overall strength of the larger army. […] Prado_in_Google_Earth.jpg

It helped the allied forces of Spain, Portugal and the United Kingdom to defeat the French in the earlier mentioned Peninsular War. In essence, this applies directly to usability testing when evaluating the quality of a web product. Today we use the guerrilla tactics of archaic times to test websites. I know it doesn’t sound as interesting as guerrilla warfare, but it’s related, so stick with me.

What is Guerrilla Testing?

Good question. It’s a very wide mix of things but in general, it’s when we use a method of testing products which doesn’t form the normal day to day QA testing or formal user testing ordinary web agencies undertake. An ordinary project would maybe undertake (vaguely) the following tasks:

  • Procurement – Selling your service
  • Specification/Requirements – Working out the projects goals
  • Design – Pencils, crayons, ‘user journeys’, functional spec and prototyping
  • Development – .NET, Numbers and The Matrix
  • QA Testing – Clicky clicky button button
  • Dev & Design fixing
  • QA Testing etc
  • Deployment

Guerrilla testing (and user testing in general) is an important addition to this simple design process. It’s not an extra line item, it’s not something you add on at the end if you have time, it’s something you add in early, and repeat throughout the process. Clients may not understand the importance that usability testing brings and many see it as an unnecessary expense when it should actually dictate most of the direction the project takes. You can test against:

  • Sketches
  • Wireframes
  • Concepts
  • Prototypes
  • Test builds
  • Pretty much anything. That’s the beauty.

Usability testing is quite often an afterthought and people prefer to conduct quick fixes after the project has been completed rather than catch errors or problems up front. It can save time, money and effort to get these things sorted. There is no better testing replacement than actually getting users to play with the site. Because everyone is different, you’ll receive different results with just a handful of people who will often take part for the sake of a treat.

So, how can I get started?

Step 1. Find your guerrilla testers You’ll need to find the users which fit in with your requirements. Students accept beer and pizza (and would be good to test Spotify for example) and trendy women like shoe vouchers (and would be good to test, err, a shoe site). The point is everyone has a price, and everyone has a user type related to the website. Profile your test subjects, locate them then find them an incentive to help you out. There are many means to recruiting your test subjects. By using your existing connections (social media), networks and your clients connections (through the website or with customers) you’ll quickly build up a list of test subjects. If you have too many, ask if you can pop them on your internal list for use another day. Why You Only Need to Test with 5 Users This is one for Nielsen:

Some people think that usability is very costly and complex and that user tests should be reserved for the rare web design project with a huge budget and a lavish time schedule. Not true. Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford.

Step 2. Define your goals & tasksThis is an important, and critical section of a usability test as you need to ensure your tasks are accurate with your goals. Let’s take the following goal for example:

  1. E-Commerce: To improve searching efficiency and overall conversion rates when finding items.

This is quite a simple high level goal. To improve the user experience and to test the ability to find items easily within an e-commerce store. The key to writing a successful task lies in the ability to set a target, without giving clues into methods involved. For example, a well written task, and a poorly written task: Poor: Search for a bookcase The problem with this sentence is it’s too descriptive. The word “search” will take them straight to a search box. They will simply search for a bookcase. Good: You’re trying to organise a collection of books and require some furniture to do so.This is much better. You’re putting a scenario in their mind. This is much more likely to bring out a more useful user journey. They could use search, they could use the navigation, or even Google!

Avoid using action words such as “click, search, type” or giving clues. Instead, write a scenario the user will be able to associate with.

Step 3. Test often and observe The key thing is to test often to catch problems early on. You can test on any of the things mentioned earlier (sketches, wireframes…) and with any type of users. If you’ve already selected your user and goals/tasks you’re ready to rock. Start testing. There are many methods of recording your results. A simple notepad and pen will allow you to make notes on key problems you encounter when watching your testers and a video camera setup pointing at the users screen will allow you to see the problems when you’re referring to them from your notes. There are also some popular pieces of software available online (Silverback, Morae).