Welcome back to those of you that have been waiting with breathless anticipation for part 2. Also note, I am aware that number is quite probably null considering my mother doesn’t read this.
That said, I am excited to be just one day away from my 9 a.m. session on “Guerilla Usability Testing” at SharePoint Techfest here in Houston this Wednesday (November 5th, 2014 - for those that found this a little later.) If you're in the area, stop by! During my session, I’ll be going into three Guerilla Usability Testing techniques a bit deeper but this short post should at the very least prove to you that asking your users for feedback is critical for successful software/apps. Oh, and the list of excuses presented in Part 1, is just that ... excuses.
For a refresher, by excuses I mean:
- It’s too hard
- Don’t have enough money
- Don’t have access to users
- Don’t have the time
- We are the users
- We already know what the user wants
Now the disclaimer. These techniques are not fool-proof and certainly not without their potential issues. They are, however, exactly as I am presenting them.. guerrilla tactics.
guerilla warfare -sudden unexpected attacks carried out by an unofficial military group or groups that are trying to change the government by assaults on the armed forces
My translation for our goal: guerilla user testing -sudden and rapid talks with users carried out by an individual or group that are trying to determine user preferences.
Again, our goal is successful software/ apps. In an ideal world, yes a user testing lab and some $3,000 software, etc. Again, ideal world. Show of hands, how many of you live and work in an ideal world? This is clearly a scientific poll.
Throughout my time doing this, the one thing I am completely sure of is that there is no ‘silver bullet technique’ – every company is different. Different goals, ideals, etc. I know? Amazing in-depth analysis.
This was in no way a goal when I started doing some of these techniques a few years back, but as it turns out they can all be easily done for as little as around $50 in materials and a bit of time on your part.
My Top Three Guerilla Usability Testing Techniques
The quick and dirty whiteboard:
Yeah, your whiteboards. Every office has them, and most of the time they sit around waiting for meetings. I prefer to put a whiteboard somewhere I know will get a high amount of traffic.
For example, the last place I worked at provided lunch daily. So, I had a whiteboard installed right on the wall across from where the line formed. Now, we had a large format printer so I could print out interfaces on a nice 18x24 inch sheet, but a drawing works just as well.
Write out one question you want the people to answer. Leave it open, and invite comments and suggestions. Also, include a note inviting people to come and talk directly with you.
This works exceptionally well in an agile environment. I would typically post a wireframe or idea on Monday mornings a good sprint or two ahead of the development team and leave it up for a week inviting feedback. After a week, pull it down and review the feedback and make adjustments accordingly. This will make sure that the wireframe has at least gone through a couple of revisions before development started. Did you know... a wireframe more often than not only gets 1-2 revisions after being presented before development begins? Clearly not always the case.
Coffee Time:
Coffee, tea or any tasty beverage will do. Not surprisingly most people find it more comfortable to have honest conversations when they are just sitting having a drink. Especially a free one. Just as an FYI, feel free to google “Drunk User Testing” … yeah, it’s a thing.
In a user testing lab, people are not in any sort of natural setting. Typically a room with a moderator and a big window where they know some people are sitting behind watching their every move... oh and bonus the whole thing is being video recorded... so yeah COMPLETELY natural settings. Your users will NEVER use your software or app in this environment again. So why not go to a coffee shop and offer to buy some people their morning coffee for 5 minutes of their time?
Take your laptop, tablet or just a pen and paper and set up in a corner. Offer to buy coffee for people for 5 minutes of their time looking at an interface. I frequent a few Starbucks where the baristas know me at this point, and will send people to me when the chair across from me opens up. So at this point, even that part has been taken care of for me. Coffee shops have become the user testing labs of 10-15 years ago.
Just like the whiteboard technique, this also works well in agile environments. Same principle, just more beverages.
Sketch boards:
Lastly but certainly not least is the ‘sketchboard’ technique. Consider this something like ‘crowdsourcing UX’ for lack of a better description. While this is particularly effective for the start of projects it can also be used throughout the development process, just not as quick and dirty as the previous two.
Essentially, you need some ‘arts & crafts’ materials, and a group (no more than 5-6 people) or groups of users, a moderator and your ‘business goals’ to keep in mind.
Sketch board shopping list:
- Roll of brown/ butcher paper (You will want a piece about 6ft long)
- Sharpies (regular, not the small or fine point)
- Masking tape
- Post-it-notes
Last but not least you will need a 6-up template, and a 1-up template. Fortunately, I’ve got these in one handy little PDF for you to download: sketchboard-templates.pdf.
Make a shortlist of possible ‘parts’ that the users can select from for the interface. Think of it as a box of Lego. Make sure they know, these Lego are there IF they want them, but aren’t necessary.
Now starting with the 6-up template and a sharpie. The group has a time-boxed period to come up with 6 different possible interfaces. I typically make it around 10-12 minutes total. That’s roughly 2 minutes per interface for the mathematically challenged and yeah, 2 minutes isn’t much time. That’s the point. So is the sharpie. No details, just big blocks, and ideas.
After the first time-box. Each user comes up to where you’ve taped up that 6ft piece of butcher's paper and explains why they did what they did on their 6-ups. The moderator should take notes during the discussions asking follow up questions if necessary, but for the most part, just stay out of the way and let the conversations flow between the people.
Once the 6-up round is done, everyone gets to their 1-up. This can be identical to one of the 6-ups they just did, or more often than not will incorporate parts others have brought in. This is typically time-boxed to 5 minutes or so.
Repeat the presentation and conversation with the finished 1-ups. Once done. Thank everyone for their time.
At this point, the real work begins. Taking these various templates, the moderator's notes and looking at the original business goals. How do they match up? How do they not?
This particular technique, while a bit more time consuming than the others is absolutely invaluable when you're thinking about a company intranet. I have done countless of these sessions, and the ‘users’ almost always have numerous suggestions or pain points that the ‘executive team’ never considered and had no intentions of including into their intranet. Which inevitably leads to 'users' not using it for any reason other than ‘they have to’. I don’t know about you, but I’m certainly not looking to make anything that people ‘have to use’, I WANT them to WANT to use it.
So, another marathon post completed.
As you would imagine, this was more of a really broad overview of these techniques, and just like anything they take practice. Some a bit more than others, but I think the key take away would be that there are no longer any good reasons or excuses to not ask users throughout your software/app development process.