How to Design a Simple UX Test

Thoughts on my user testing design process

Based on my background with instructional design and  guerrilla web building, I’ve tried take a new look at my design process from the perspective of usability and user centered design.

I’m sure it fits in with the larger context and conversation going on in the very robust user-centered design community. My purpose isn’t to make it fit, but rather just notice how I would go about conducting a user centered design. I know it will change- it’s already changed twice this week. It seems I change this design process each time I read an article on Smashing or usability counts blog.

With most good things, my user-centered design process has a beginning, middle and end… Thinking of changing that to include the word terminus which is a beginning and ending, but I digress.

Beginning – “Stand in the place where you are” – R.E.M

I like to start with what I (or the client) know. Business goals should not be confusing, abstract nor complicated. “Sell more widgets”, “Make money”, “Provide health care to my workers”, etc. They should be clearly stated in a business plan or firmly in the mind of the business owner. From these business goals we can derive site goals and page goals.

Site goals can be anything:

  • to inform
  • to sell
  • to build trust
  • to reduce paperwork
  • to recruit new employees
  • to build a community
  • to entertain

Each page should have a primary goal-or the thing you want the user to do. Don’t give your pages an identity crisis. Don’t make your users search for the purpose, or ‘call to action’, or banana. Pages, like PowerPoint slides, are free. Use as many as you need. The idea is to have a clear goal  for each page. You can test this clarity directly in your user tests.

The clearer the goal, the more straightforward the user test.

Align Business, Site, Page and User goals for Whomp Ass UX

Align Business, Site, Page and User goal for Bad Ass UX

Aligning the business goals, site goals and page goals is key. If the business goal is “to sell” and the site goals are “to entertain”, then there’s going to be a problem. The biggest problem I see in websites is unclear or confusing site goals.

The last part of the defining what you know is to collect information for baseline performance. You may need to survey company employees or site users to collect this data. Much of this information is”laying around” or extant within the organization. Examples of this are business plans (for business goals), previous website’s design documents or web traffic data (for redesigns) or advertisements or marketing materials.

Now that you’ve collected and define what you know, it’s time to make a few estimates and educated guesses. This could be called a hypothesis. You’re going to make guesses about the users, and how and where they use your site. Why is this important? One, this is what you will confirm or refute with your test results. Two, a Saturday morning website is very different than a Saturday night website. Other questions are, are people using the site at work? At their desk? On the couch? On a mobile? Users determine how your site will be used and you have to make design decisions based on these assumptions.

You want to dive deeper into who these users are. What are their goals? Why are they going to your site? How did they get there? What are their demographic attributes?

Closing the beginning of this design process is choosing the testing environment and tools. Basically-whether you use technology or not – it comes down to interviews, surveys, and small-group testing [watching / observing the user interact with your site]. I suppose for websites you can also add automated reports and services like the W3C site checkers.

The middle part – a.k.a. the fun part

Once you have all of your “knowns” about the business and you’re educated guesses about the user and their context, you are ready to draft and refine your testing instruments. What sort of things are you still unsure of? Which assumptions are not agreed upon-there will be some in any group. That’s what and why you test.

You generally test a website or any system for these three things:

  • Effectiveness – Can users do what they ( And you) expect? mechanically, does it work?
  • Efficiency – Is it easy to use? Does it work naturally or does it take concentration?
  • Satisfaction – Sometimes called the ‘smile test’. Do people smile when they use it? Are they happy to use it? is it delightful?

I won’t go into too much detail here, but the general structure of a user test is:

  • Pre-test Questions
  • Participant Tasks
  • Post-test Interview
  • Post-test Survey

Before you conduct the test there are a few steps to follow. You have to:

  • Choose a facilitator-preferably one without much experience with the design or site itself. Recruit testers-preferably of the target market demographic
  • Decide on the links and location of the test – preferably close to the environment that the user will interact with the site, at home, at work or in a mobile situation.
  • Prepare a script for the facilitator-this avoids bias delivery and provides a standard control especially if you’ve got multiple facilitators
Vader, Bad ass, believes in testing

Vader, bad ass, believes in testing

Fin – the end

The last part is to collect, analyze and report the results. If you prepared and conducted a well made test (lucky?) clear patterns will emerge from the test results. You may see that people are unclear about your menus and can’t find certain information. Or you may find that there is a loophole in the structure such that people get in but can’t get out.

It’s important to remember to test the user experience – not your design. The users are experts in their own experience.  They couldn’t care less about color scheme or fonts. They won’t tell you that experience and less you ask them. If you ask about design, they will tell you about design.

The goal of all of this is to make new assumptions about your users. These assumptions are now based on your test results. You have a more complete picture of your users and your site. Hopefully there are some clear improvements you can make to your site. You can make those changes and test again to see if  “the needle moved”, the changes were effective as anticipated. Then, you start the process over and test again.  Each time you will get a more complete picture of your users and insights into how to make their experience with your website better.

Thanks to Flickr: Sebastian Bergmann

One comment on “How to Design a Simple UX Test

  1. Pingback: How to Design a Simple UX Test « Sen's Blog

Leave a Reply