Usability Testing

Software Development Lifecycle

Waterfall

There are numerous approaches to taking a software program from an idea to a finished product.

For example, large, complex software tends to have a very formal process involving:

1. writing a user requirements document

   • audience for document: users
   • users describe what they want the software to do
   • developers document what they hear users asking for
   • everyone agrees that what was written down is accurate

2. writing a system specifications document

   • audience for document: users
   • developers describe what they are capable of making the software do / are willing to make the software do
   • users agree to proceed with the project (or, choose to revise requirements, essentially starting again)

3. writing a design document

   • audience for document: developers
   • developers make detailed technical plans for how the software will operate

4. authoring the software

   • developers actually write code to implement the agreed-upon design

5. testing the software

   • developers compare the application’s capabilities to the specifications to ensure all functionality is present and works as promised

6. delivery and maintenance

   • application is delivered to end users
   • bug fixes and performance improvements provided as needed by developers

This is typically referred to as the waterfall model — where each stage of the software development lifecycle is separate from the others, and the project proceeds through each stage eventually ending with a completed product.

Agile

Mobile and web-based applications sometimes follow this model, but often adopt an Agile approach based on prototypes, where:

• small bits of functionality are implemented in a sprint
• these are tested by end users and developers
• based on feedback, the program design may be modified
• cycle repeats as needed to refine existing features or add new features

Usability testing is a big part of the software development lifecycle — no matter what approach is used — and can be very formal, completely informal (a.k.a. “guerrilla”), or somewhere in between.

Guerrilla Usability Testing

There are entire university courses devoted to usability considerations when designing software.

For this course, we will focus on guerrilla usability testing.

Let’s have a look at how Google engineers conduct these types of tests:

Questions

1. What does the term usability mean?
2. How many users are required to catch most of the usability problems with your app? As well, who did the research to determine this number?
3. How many people should be involved in watching a user during a guerrilla test? Why?
4. Why can’t developers find usability problems with their own applications? Who is best suited to finding usability problems with an application?

Thinking Aloud

Now, let’s take a look at another short video that illustrates in a bit more detail what it means to “think aloud”:

Questions

1. What does a “think aloud” test involve?
2. Referring back to the first video, how can a designer or developer analyze the results of a guerrilla usability test?