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 20 - Q4 2006

Prototyping beyond the sunshine scenario

How to prototype derivations from the main flow

Prototypes often model one flow of interaction – the path that users are most likely to take. But when we create interaction designs with dynamic and complex flows, we often need to include deviations from the sunshine scenarios to see whether they work. In this article, we'll look at how to do this Visio and Axure.

The days are long over where the hardest decision designers of web solutions had to make was whether the navigation should go in the top or to the left. Today, we are being tasked with more and more complex design challenges, such as checkouts at online shops, reservations systems, product comparisons, self-service systems, product configurators, and so on.

The flow of interaction in such designs is more dynamic and complex than the page-to-page flow of traditional websites. And the more dynamic and complex, the more likely it is that people can't find their way through the maze. Therefore, dynamic flows require close attention from designers.

Exceptions and variations

There are two reasons why a user might experience a deviation from the sunshine scenario: exceptions and variations.

Exceptions are scenarios where people do things that the backend system can't process. We might for example mistype our password when we try to sign in at Amazon.com.

Error message at Amazon.com telling that the e-mail and password don't match any accounts

Error message at Amazon.com telling that the e-mail and password don't match any accounts.

Another example is a search that gives no result.

Error message at Amazon.com telling that there are no search results.

Error message at Amazon.com telling that there are no search results.

Variations are derivations from the main scenario that happen either because the user decides to or because the system is in a special state.

An example of a scenario where the user decides to derive from the main scenario would be a shopping site, where the user chooses to sign in instead of registering as a new customer.

When we sign in at Amazon.com, we can either choose to register as a new customer or sign in as a returning one.

When we sign in at Amazon.com, we can either choose to register as a new customer or sign in as a returning one.

A scenario where a user derives from the main scenario because of a special system state would be a shopping site that sends the user past the sign in page and directly to the checkout because the user is already known by the system.

System requirements

If you are working with paper prototypes, there's nothing complicated about simulating alternative flows. You just draw the necessary screens and use these to model the flow in walkthroughs and usability tests.

If you use a computer based prototyping tool, it might not be as easy. It depends on the tool you are using. If you are using Visio or Axure, you are in luck. They both allow us to include multiple destinations to choose from, when buttons and links are clicked.

Prototypes build with Visio and Axure show little pop-up menus when two or more pages are added to a button or a link.

Prototypes build with Visio and Axure show little pop-up menus when two or more pages are added to a button or a link.

If you are using a web-design tool, such as Dreamweaver or GoLive, it would be no problem for a semi-seasoned javascripter to do something similar.

Modeling alternative paths in Visio and Axure

The method is quite simple. When there are two or more paths that the users can take, include a little pop-up menu next to the link or button that was clicked. From the menu, the user can then choose between the alternative paths.

Here's how to do it in Visio and Axure.

How to add multiple paths to links and buttons in Visio:

  1. Select the link or button that you want to add multiple paths to
  2. Choose Insert > Hyperlinks... (or press Ctrl+k)
  3. Set Sub-address to the page with the first case
  4. Add a description to the Description field. This is the text that will show up in the pop-up menu.
  5. Click New to add the next case
  6. Set Sub-address to the page with the next case
  7. Add a description to the Description field.
  8. Repeat step 5 to 7 until you've added all the cases you need

 

The Hyperlinks dialog in Visio with two links added to a single button

The Hyperlinks dialog in Visio with two links added to a single button

 

How to add multiple paths to links and buttons in Axure:

  1. Select the link or button that you want to add multiple paths to
  2. Click Add Case (under Interactions in the right panel)
  3. Add a description to the Description field. This is the text that will show up in the pop-up menu.
  4. Select Open Link In Current Window
  5. Select the page with the first case
  6. Click Add Case to add the next case
  7. Add a description to the Description field
  8. Select Open Link In Current Window
  9. Select the page with the next case
  10. Repeat step 6 to 9 until you've added all the cases you need

 

The interaction panel in Axure with two links (cases) added to a button

The interaction panel in Axure with two links (cases) added to a button

Using the method in usability tests

For usability test, the labels of the items in the pop-up menu should read something like "Case 1", "Case 2", "Case 3", and so on. In this way, the labels won't reveal what is going to happen and we can observe whether the users understand what is going on. If a label for example read "No search results", it would reveal the scenario to the user and the test of the flow would be flawed.

The pop-up menu will seem strange to the users at first, but most will understand, when we explain it to them.

In conclusion

The intention of this article isn't to claim that a prototype should model every possible path of interaction. Some scenarios are too complex and time-consuming to build. Some are too simple to bother.

It's obvious that features, where the possible outcomes of the users' manipulations are countless (e.g. search engines), are impossible to test in-depth using a prototype with no backend functionality. Also, simple exceptions that are easy to correct (e.g. error messages) can be left to be tested with the final product or simulated in usability test using Post-It notes.

Which alternative scenarios to include in a prototype depend on how mission critical the scenarios are to the user experience, and how hard it is to correct them, if flaws are found in the final tests.

Text: Henrik Olsen

Comments

 
"...the more dynamic and complex, the more likely it is that people can't find their way through the maze"

RELATED POSTINGS

     
 
Posting added before you last visit at GUUUI Visio - the interaction designer's nail gun (2nd edition)
Posting added before you last visit at GUUUI How to use PowerPoint for prototyping
Posting added before you last visit at GUUUI The promised land of prototyping
Posting added before you last visit at GUUUI Balancing fidelity in prototyping
Posting added before you last visit at GUUUI Defence of paper prototyping
Posting added before you last visit at GUUUI New Version of DENIM Available
 
 
     
  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI