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.

[et_pb_section bb_built="1"][et_pb_row][et_pb_column type="4_4"][et_pb_text]

A bit of a warning. When I started writing this post I had no intention of doing a 2 part post. It was supposed to be a quick introduction to a session I will be presenting at SharePoint TechFest here in Houston on November 5th but there was just so much information that I felt needed to be presented and it just continually grew. So unfortunately this is will be a 2 part piece.

• Part 1, the one before you, will focus on the importance of why you should be asking your users as early and as often as you can during the process of developing your next project.
• In Part 2, I will focus on how to get user feedback by providing some quick and effective methods for getting feedback from your users that will prove invaluable and quite possibly save your next project from falling short, or worse yet, never getting adopted by your users.

So with that out of the way, I give you Part 1 - Why many projects fail or worse yet never get adopted.

The cost of project failure is immense. Estimates done in 2009 put the cost of IT project failure in the $6.2 trillion, yes that’s a trillion with a ’T’. According to the study done by Roger Seasons, nearly 25% of all IT projects result in failure. In 2012, Michael Krigsman challenged these numbers and asked Gene Kim and Mike Orzen to take a second look into the numbers and make a more accurate estimate of the impact of IT failure on the economy.

Kim and Orzen took a conservative approach and applied a 20% failure rate to start their calculations.

For just the Standard & Poor 500 companies, aggregate 2012 revenue is estimated to be $10 trillion. If 5 percent of aggregate revenue is spent on IT, and conservatively, 20 percent of that spending creates no value for the end customer - that is $100 billion of waste!

When looking at where IT money is spent.

If we conservatively estimate that 50 percent of global IT spend is on "operate/maintain" activities, and that at least 35 percent of that work is urgent, unplanned work or rework, that's $980 billion worldwide of waste!

Their conclusions.

What reward can we expect through better management, operational excellence and governance of IT? If we halve the amount of waste, and instead convert it into 5x of value, that would be (50 percent * $1.2 trillion waste * 5x). That's $3 trillion of potential value that we're letting slip through our fingers!

Kim and Orzen have clearly done some legwork and come to what appear to be a bit more realistic numbers. In either case, though it’s not exactly clear what the criteria for ‘failure’ was.

I won't dispute that “better management and governance of IT” are not significant contributors to a successful product. That being said, a project that is managed by the greatest of managers, running a project so flawlessly that a swiss watch maker would envy, is still open to complete and utter failure. What’s worse it is a chance at failure that can be all but eliminated with a much more simple solution: Ask the users.

Yes. I said ask. Ask users. Ask users as early as possible. Ask early, and ask often.

Some of the typical responses, or reasons offered for not doing user testing or research include:

• 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, before going any further I am sure after reading this list, one of the first things that popped into your head was the often overused and more importantly misunderstood quotes from what has been attributed to Henry Ford.

If I had asked people what they wanted, they would have said faster horses.
- Henry Ford

There are a couple of issues with this. First and perhaps least important, Henry Ford never said it. Certainly none of his biographers attribute it to him, and nobody actually has any record of it being said. However, the second issue is significantly more problematic. This quote is repeated ad nauseum to justify dismissing user feedback and participation. Our misappropriation of this quote just further reinforces this. Even if Henry Ford had said it, he wasn’t looking to solve the “Horse” problem. Henry Ford was trying to fix the mass production problem, how to get more automobiles cranked out.

No one said they wanted faster horses, they wanted less horseshit. -Erik Flowers

Minimal effort will reeal, that Horses were in fact an issue in the late 1800’s and early 1900’s. However, their slowness was not on the list of issues anyone had. In fact, there were more horse related traffic deaths per capita than automobiles today. So asking for ‘faster horses’ would be highly unlikely.

So with that little hurdle cleared I return you to our regularly scheduled post:Asking your users. 

Think about it. If you knew people were not going to use your website or app, or aren’t going to like it, wouldn’t you want to know before you put all the effort and resources into building and deploying it?

Sure, your employees are somewhat a ‘captive’ audience when it comes to your company intranet, or software but how many times have you heard “happy employees are productive employees.”? You absolutely have to weigh user wants, goals and desires against business objectives but the more you can merge the two, the more your project is assured of success.

Next month: Guerrilla User Testing in an agile world - Part 2. In that post, I will focus on how you can ask for user feedback via some quick and effective methods.

And if you’re in the Houston area, think about registering for the upcoming SharePoint TechFest Houston event at the NRG Park.

Resources:
Worldwide cost of IT Failure (revisited): $3 trillion - zdNet April 2012
Worldwide cost of IT Failure: $6.2 trillion - zdNet December 2009
Critique: $6.2 trillion Global IT failure stats - zdNet December 2009
Erik Flowers - "No one said they wanted faster horses, they wanted less horse shit."

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]