To the front pageThe Interaction Designer's Coffee Break - Weekly postings and quarterly articles about interaction design  
  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI  
   
 

ISSUE 10 - Q2 2004

Use Cases and interaction design
Modelling user workflows with Use Cases


Use cases are widely used in large projects to capture the functional requirements of software systems. In the hands of interaction designers, use cases can serve as a powerful tool for brainstorming workflows and bridging the gaps between design and development.

Low-fidelity prototypes usually visualise one path of interaction – the successful one. Exceptions, such as what will happen when a user enters incorrect data or gets no results from a search, are usually left out. If you are designing complex applications, such as e-commerce sites, you might have experienced that this is not good enough to feed into the development phase. Developers can't deduce from your prototypes what will happen when the flow takes other paths than the successful one or they might confront you with some far-reaching consequences of your design that you never thought about, because you never considered the entire workflow. The risk is that important details in the design fall between chairs and get caught late in the project, when changes and adjustments are costly and time consuming.

Modelling task flow

Interaction designers have the responsibility for the task workflow and need to describe their designs with sufficient completeness, in order for developers to be able to write code from them. Anything left unsaid is likely to be misconstrued or ignored.

In order to lower the risk of designing ill-considered solutions or losing important details between design and development, interaction designers need a tool to model task workflows, when dealing with complex applications. Flowcharts are widely known and Jesse James Garrett's visual vocabulary is also becoming widespread. While these diagramming techniques are great for visualization, they tend to become unmanageable as you add more and more items to them. You end up wasting a lot of time, dragging boxes and connectors around to make it all fit together.

While looking around for a solution to this problem, I've found that use cases are the answer. Not that they can substitute prototypes or flow diagrams. But they can help you consider your designs in more depth before you start prototyping and serve as an input to the development phase.

Essential Use Cases

One of the major problems with use cases is that there is no standard way to write them. Since they are mostly written by system engineers, they tend to have a strong focus on the internal workings of applications - not what the user does or wants. This has contributed to problems in applying uses cases to interaction design.

Larry L. Constantine and Lacy A. D. Lockwood have suggested an approach to use cases, called Essential Use Cases, which is becoming common style. In their version, developed specifically to fit into a user-centred development process, the nerd factor is remarkably reduced. Their approach promises to bridge the gaps that tend to appear between requirement analysis, design, and implementation.

An example

A use case describes a single and well-defined goal of interest to a user, and the steps involved to reach this goal. The goal could be to buy a product at an online store, and the steps involved would be to browse products, pick a product, go to the check-out, sign in, fill in shipping and payment information, and submit the order. Such a scenario would be described as a "main success scenario" in use cases.

As we all know, life can take surprising turns - both good ones and bad ones. The customer may have mistyped his credit card information, or the customer could be a returning customer and already have registered shipping and payment information. These scenarios are "exceptions" to the main success scenario.

Here is how a use case for buying a product at an online store might look:

Buy a product

Main scenario:

  1. User browses products
  2. User adds a product to shopping basket
  3. System displays the shopping basket with the new product added
  4. User proceeds to check out
  5. User may register as a new customer, sign in as a returning customer, or have password sent by e-mail in case the user has forgotten it
  6. User fills in shipping and payment information
  7. System validates shipping and payment information
  8. System displays order
  9. User confirms order
  10. System confirms sale

Exceptions:

6a. User is a returning customer

  1. System displays the user's current shipping and payment information
  2. User may edit current shipping and payment information

7a. Required information has not been provided

  1. System asks the user to provide the required information

7b. Credit card information is not correct

  1. System informs the user that the provided credit card information is incorrect and asks the customer to try again.


In reality, a flow like this will be more complicated than described in this use case. It doesn't answer questions such as "how does customers browse products?" or "how does one register as a new customer?"

In a complex flow, such as shopping, users will have sub-goals along the way. Such goals can be described in sub-use cases. If we take step five for instance, we might want to extend it with three sub-use cases.

These use cases might look something like this:

Register as a new customer

Main scenario:

  1. User provides name, e-mail, password, and confirmation password
  2. System verifies name, e-mail, password, and confirmation password

Exceptions:

2a. All information has not been provided

  1. System asks user to provide the missing information

2b. E-mail format is incorrect

  1. System asks user to correct the e-mail

2c. E-mail is already registered

  1. System informs the user that the e-mail is already registered
  2. User may sign in as a returning customer or have password sent by e-mail

2d. Password doesn't validate against password rules

  1. System asks the user to provide a password, which complies with the password rules.

2e. Password and confirmation password don't match

  1. System informs the user that the password and the confirmation password didn't match and asks the user to try again.

Sign in as a returning customer

Main scenario:

  1. User provides e-mail and password
  2. System verifies e-mail and password
  3. System signs user in

Exceptions:

2a. E-mail is not provided

  1. System asks the user to provide an e-mail

2b. E-mail format is incorrect

  1. System asks the user to correct the e-mail

2c. E-mail is not registered

  1. System informs the user, that there is no one registered with this e-mail, and suggests the user to try again or register as a new customer.

2d. Password is not provided

  1. System asks user to provide a password

2e. E-mail and password doesn't match

  1. System informs the user that the provided password is incorrect and asks the user to try again or have password sent by e-mail.

Have password send by e-mail

Main scenario:

  1. User enters e-mail
  2. System verifies e-mail
  3. System sends password by e-mail

Exceptions:
2a. E-mail is not provided

  1. System asks the user to provide an e-mail
  2. E-mail format is incorrect
  3. System asks the user to correct the e-mail

4a. E-mail is not registered

  1. System informs the user, that there is no one registered with this e-mail, and suggests the user to try again or register as a new customer.

As you can see, use cases are so simple and unsophisticated that they almost feel as an insult to your intellect.

There are a number of principles you should consider following when writing use cases.

Use only when appropriate

Use cases don't make much sense when we are dealing with simple informational web sites. There is no point in modelling task flow of how a visitor can go to the "About us"-page. This is better done with site map diagrams. Use cases are primarily useful when we are dealing with more complex flows.

Don't make premature assumptions about the interface

Use cases should be thought of as abstract prototypes. There is no browser, no pages that the user can go to, nothing to click, push, tick off or type text into. The interface is yet to be designed, and premature assumptions can constrain the design unnecessarily. This is particularly important if you are not going to design the interface yourself.

Don't describe internal workings of the application

In use cases, there is the user and the system interacting. If your professional background is programming, it might be tempting to describe software components interacting with other software components. But use cases is a tool for modelling user tasks, and there are lots of other tools more suitable for system modelling.

Cooperate on use cases

Use cases can serve as a bridge between the needs of requirement analysts, designers, and system developers. But this is only going to happen, if the different views of the involved team members are reflected in the use cases. Requirement analysts have client requirements as their focus, interaction designer the user needs, and developers the technological capabilities. If developed in a cooperative setting – and with respect to budget and time scale – use cases can reach long-lasting validity.

In conclusion

Writing use cases adds an extra step to the development process, but since they are fast to write and easy to alter, they support a time and cost effective design process. They fit perfectly into an iterative development process, where you move from abstract concept to finished product in repeated cycles, where the design is gradually elaborated and refined. In this process, use cases can work as an abstraction of the interaction design and serve as healthy warm-up exercise to the real prototyping.

And it's actually quite fun to write use cases - sort of designing in the fast lane.

Text: Henrik Olsen

 
"And it's actually quite fun to write use cases - sort of designing in the fast lane."

RELATED POSTINGS
 
Posting added before you last visit at GUUUI Bridging use cases and interaction design
Posting added before you last visit at GUUUI Diagramming tool for information architects and interaction designers
 
 
     
  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI