Posts Tagged ‘Usability’

Gorilla Usability

Monday, March 8th, 2010

“Wait… if I read the title correctly… are you talking about how people should go about using a gorilla?!?” No silly… it’s a play on words. What I am talking about is a usability study that @michaelseidel and I conducted recently @AJBombers. I want to share how you can do usability studies without breaking the bank.

Traditionally, I have participated in usability studies that have been conducted in a lab. We recruit about 10-15 users and pay them about $100 each to come in and test a website in a lab while designers, developers and business owners sit behind 2-way mirrors and watch the subjects interact with a website. We double book each time slot to make sure we get a participant in every slot and we still pay the people we don’t use. We write scenarios for the users to walk though and we have a couple of usability specialists walking the users though the scenarios and taking copious notes. We analyse the results after each user and compile all the information into a recommendation document.

These type of sessions were the status quo in the past. Unfortunately, these sessions were expensive and time consuming. They were necessary at the time, but the 800 lb. Gorilla in the room (see what I did there) was the cost of these sessions. There may still be a very limited place for this type of testing; however, there is another way…

So here is what we did… We are working on a section of a website that has a search mechanism and refinement tools that help the user narrow the results based on criteria they select. The refinement tools could be placed in 2 different spots on the results page. We wanted to test what position gave the best user experience for these tools.

We didn’t have a lot of time to plan a full blown (gorilla) usability lab and we didn’t have the budget for it either. So what we did is turn to social media and offered free lunch.

We started kicking around ideas on how to get good user testing without breaking the bank when it hit us; we could turn to Twitter to recruit users for this and we need to set up the testing somewhere that is convenient for our local networks to meet. We also need some sort of compensation for these users time. We came up with the perfect spot – AJBombers.

I decided to contact Joe from AJbombers and bounce the idea off him. I told him that we were going to conduct a user study and test some options of a website. I also mentioned that we were planning on buying all our participants lunch at his place. He was more than happy to help us out, in fact, he was excited about it.

We started out by broadcasting via Twitter what we were planning to do and when. Joe helped us out by Re-tweeting it to his loyal following which spurred a good response. The great thing about this entire approach was we planned it on a Friday for the following Wednesday and we filled all the spots we were looking for with very little effort. A few tweets and some re-tweets and we were good to go.

On the day of the testing Joe gave us a prime location to set up so we could funnel users through during the time slots we had set aside and we had a great system for getting food and drink orders started with our awesome waitress “B the Tweetless.” while the testing was going on. I was completely amazed how smoothly the entire session went seeing as this was our first attempt at doing anything like this.

The test went great; we noticed that the atmosphere is more realistic in a setting like that compared to a lab environment. The lab comes off as clinical and stiff. This was relaxed and the users seemed more comfortable in this enviroment… less spotlighty. People were willing to have a conversation about what we were testing; it didn’t come across as a rigid question and answer session. The feedback we gathered was genuine and gave us insight into things about the site we weren’t even testing. It also seemed like people were more grateful with receiving lunch than paying them cash to come out to our lab. “This is it? This is all I need to do? I feel like I need to do more to receive a free lunch.”

The test was a major success. We were able to test 10 users over 3 hours and under $200 total. This method of testing is completely viable, portable, and cost effective. This will now become our preferred method of testing moving forward. Granted, there will still be times where we have to bring people into a lab because we are testing something bigger that takes longer to run users through, but I think those sessions will be fewer and further between.

Finally, I would like to extend a huge Thank You to Joe and his staff @AJBombers! They really helped us out and that place is truly the best usability lab on the planet.

The True Cost of User Experience

Thursday, January 14th, 2010

In some schools of thought, user experience (UX) and usability testing are a box to be checked somewhere in the development life cycle. As long as you, at some point in development, talk to someone about the UX of your product things should move smoothly ahead. Usually these UX talks happen near or at the end of development and any feedback given is taken with a grain of salt.

The problem with this thought pattern is all the hidden costs of overlooking or short selling UX.

Password Reset FormFor instance this very real example shows a very confusing UX while trying to change a password for a login to an online application. (I am not going to reveal the company that had this experience. They have since come to the light side and now embrace usability and user testing.)

As you can see the form is pretty straight forward until you have to select what button to press to complete the task. The form is asking you if would like to reset your password. If you do, you fill out the form and then… Do I hit OK? Maybe that seems like I am giving the form permission to reset my password. Do I hit RESET? I think so… The form is asking me to “reset” my password so “RESET” must be the right button.

Wrong.

The RESET button clears the fields above and doesn’t give you any feedback as to what just happened. Oh, by the way, the OK button does the same thing. There is no feedback telling you that your password has been reset. Now the user can only assume that their task is complete.

So, how do we break down the overall cost of this terrible user experience?

First we take a look at it from the user side. They now assume that their password has been changed. The next time they come to use the application; they put in their user name and their newly changed password. The application tells them that “The username and/or password are incorrect. Please try again.” So thinking they misspelled something they try again… same error. Fumbling around with this several times is taking precious time and patience away from the user. This is just the tip of the iceberg when it comes to cost.

Next that user then calls customer support to get some help. In walks the cost to the proprietor of the application. They are paying for every call that comes into their call center to troubleshoot this issue. They have thousands of users and are now funneling hundreds of calls through their call center on this one issue (Especially because this particular application requires users to change their password every 90 days.).

Some users even go as far as dropping the service and using a competitor’s application. “If it’s this hard to change your password, I can only imagine how difficult the rest of the application is.” Now, this may be an extreme viewpoint, but there were still some customers who felt that way. Hidden cost number 3 — loss of users.

Fed up with all the issue troubleshooting, the company decides that they need to get to the bottom of all the problems their users are having and perform some user testing. They go through several sessions of usability, take the finding and come up with a plan to implement the necessary changes to make the UX better for their customers.

The final cost of that is taking part of the development staff off their current tasks, getting them to crawl back through all the code to fix all the troubled spots of the application, retesting the application to make sure the changes haven’t caused any additional issues elsewhere in the application and finally rerolling that application out to a production environment where the users can take advantage of the new improved UX.

Had this company taken the mock-ups through user testing prior to one line of code being written, they would have discovered this issue (among others) and could have resolved it prior to launch. This would have prevented all the hidden costs of aggravated customers, larger call center volumes, troubleshooting time with each customer, lost customers and a ton of rework getting in the way of new enhancements and pushing back future releases.

The cost of that simple change up front would have been minor compared to what actually occurred.

Hello Goat Footer Divider
Hello Goat Footer Divider
Hello Goat: The Blog is proudly powered by WordPress.