User testing

Owned by Former user (Deleted)
Last updated: Sept 02, 2011Version comment
2 min read

Note: This page is outdated. Please see User Testing for the current user testing space

. User testing integrated into the design process - DRAFT

We want to do testing early and often.  We've been talking about 3 types of user testing to incorporate into our design process:

Type of User Testing

  • Hallway testing - during day to day design, grab a few people for a few minutes (should be unfamiliar with the system - preferably potential users) and put paper wireframes in front of them to help make design decisions.  This is great for testing 2 different design ideas or just to see if concepts make sense.
  • Distributed informal quantitative testing -  test a chunk of functional designs fairly fleshed out.  We should use a shared protocol (likely created by designer) to test a few users at each of the core institutions.  Results are meant to inform design still fairly early in process.  These may be paper prototype tests, omnigraffle clickthrough, or a working prototype.
  • Formal(ish) testing - quantitative & qualitative - once designs are baked (perhaps even implemented), do fairly significant tests with large chunks or functionality to look for problem areas not previously identified and to do qualitative analysis (can 80% of users complete X task on 1st attempt?)

We also want to increase and better integrate design reviews and expert evaluations into our design process.

Tools / Artifacts for Testing

The key to Distributed informal quantitative testing (and more formal testing if done distributed) is to share a protocol across our locations so we have consistency in the activities we have users do and the questions we ask.  This will allow us to compare across tests.  This also means the protocol is imporntant.  Below are some example artifacts that can help us with our consistency and thinking through what we want to test.  Anyone can create the artifacts to be shared across our campuses but it's likely the designer who is most familar with what the designs are meant to enable.

  • Example protocol - to be used by the facilitator.  The protocol walks through intro to test, tasks we want users to accomplish and any follow up questions.
  • Example task sheet - to be used for note taking (may also prefer to use a notepad).  Task sheets are an efficient way to track how we expect users to complete activities compared with how they do.  
  • Example demographic questionairre - given to participant at beginning at test to find out some basics about who they are.
  • Example consent form - unless a colleague, we should always give users a consent form and keep a signed copy on file
  • Example Post-test questionairre - for quick constrained feedback about the participants experience.  We will also want to ask interactive questions to get deeper into the experience (see protocol). 
  • Example results - from Fluid wiki
  • Facilitation and planning tips - highlights from the experts on dos and don'ts

Other resources:

Versions of all these resources and many more can be found in the Fluid Design Handbook.

User testing presentation recently given at a workshop in Berkeley.