Designing Scenarios

Created: Tuesday, 20 January 2009 Written by Gary Elsbernd

Robert Mager wrote about behavioral objectives from an instructional standpoint.  Before designing a training program, designers must know in very concrete terms what they are expected to do to demonstrate their mastery of the material.  The same factors that go into developing good performance and learning objectives are used to develop thorough scenarios that can be easily evaluated.

Mager’s Theory of Behavioral Objectives

In the design of instructional materials, training needs are first analyzed and the learning goals of the program are determined. Mager’s central concept is that a learning goal should be broken into a subset of smaller tasks or learning objectives. By his definition, a behavioral objective should have three components:

• Behavior. The behavior should be specific and observable.

• Condition. The conditions under which the behavior is to be completed should be stated, including what tools or assistance is to be provided.

• Standard or Degree. The level of performance that is desirable should be stated, including an acceptable range of answers that are allowable as correct.

A fourth component can be inferred of Actor – who is required to perform the task.

Consider the following behavioral objective:

Given a stethoscope and normal clinical environment, the medical student will be able to diagnose a heart arrhythmia in 90% of effected patients.

This example describes the actor (the medical student), observable behavior (identifying the arrhythmia), the conditions (given a stethoscope and a normal clinical environment), and the degree (90% accuracy).

Applying ABCD to Scenarios

A good scenario also covers ABCD

• Actor (who is using the system, what access and motivation does he/she have),

• Behavior (what action is required? What result is expected?),

• Condition (are there elements in the work context that influence the design, such as noise, lack of time, etc.), and

• Degree (to what extent must the task be done accurately and/or quickly?).

This construct allows reviewers to identify with the situation and clearly identify if the scenario is realistic and appropriate.


My Designs: Process Mapping through Prototyping

Created: Tuesday, 20 January 2009 Written by Gary Elsbernd

My wife doesn't know what I do at work.  I tell her all the time, but her eyes glaze over sometime into the second paragraph like mine do when she discusses her work in the neonatal intensive care unit.  I find my work endlessly fascinating, but I'm in the minority.  What I do is develop user experience designs from which talented developers create world class web applications.

The job is part psychologist, part librarian and part artist.  I have to understand organizational objectives and personal motivations, catalog knowledge and design components, and weave them together into a interface that so closely supports the intended task that it becomes invisible to the user.

I learned my craft over the past two decades after being exposed to a variety of methodologies and techniques.  My current practice most closely resembles the Performance Centered Design methodology developed at Ariel Performance Centered Systems and documented by Barry Raybould.

Business Process Mapping - A clear understanding of the current and desired business process, including what the business needs out of the process and how the user is incented to perform the task, is needed to develop a system that satisfies everyone.  These flow charts are then broken down into information needs for each step to ensure the user can make the right choices.  I don't usually have to do the process maps myself, but I usually influence them and must understand them.

Scenario Development - A scenario describes a single instance of a use case in as much detail as necessary to tell a story.  The scenario provides a narrative that can objectively be assessed to ensure the prototype solves the problem.  A number of scenarios are developed to cover variety of tasks, user groups and work contexts.  Sometimes I share these with my team, but often it's just a structure for me to demonstrate the prototoype.

Prototyping - The processes are divided into screens to support the task and an interface flow is developed to show how the screens interact.  HTML prototypes of the screens are developed and linked to support the story developed in the scenario.  The evaluators can see how the task progresses from screen to screen with as much fidelity in the data and functionality as necessary to understand the intended design.

Evaluation - Users review and identify holes in functionality, information or the process.

Refinement and documentation - After iterating through the prototype, the design will solidify and coalesce into an accepted design.  That design is documented with an annotated powerpoint of the prototype and user interface specification describing every control, behavior and data element present in the prototype.

Maintenance - inevitably, the scenarios don't cover anything, and sometimes technical limitations require compromises in the design.  As a designer, I stay involved through testing and deployment to ensure the system works in the real world.


Rethinking the Hierarchy

Created: Friday, 16 January 2009 Written by Gary Elsbernd

Elsbernd's Hierarchy of Needs, described in my blog a few months ago, has been hanging on my wall at work.  I've given it some thought and while there are aspects of it that I really like, such as the concept of satisfiers and delighters (functionality and performance are satisfiers, usability and aesthetics are delighters), I was forced to admit the model doesn't hold true for all applications.

The original idea came from the traditional commercial enterprise software development model, in which at first, relevant functionality was enough for a new application to be successful.  As long as the software accomplished something users were previously unable to do, it didn't matter if the system was slow, difficult to learn or use, or hideously ugly, it accomplished a task.  Eventually, users become complacent and start demanding more functionality, faster or more dependable performance, easier to use and more pleasing to the eyes. Eventually, functionality and performance is taken as a given, and only their absence is noted.  Usability and Aesthetics, on the other hand, are delighters, in that their presence can increase satisfaction with a system.  This is a gross generalization, of course, and doesn't adequately defend against some very legitimate criticisms.

Systems aren't built in a hierarchy - all systems have some level of all four attributes.  They serve some purpose, have some level of performance, can be used at some level, and have a presentation.  It's not accurate to say systems are built one layer of the hierarchy at a time or to imply that the concerns are always approached in the same order.

The dividing line between satisfiers and delighters is not black and white. Some features and functionality are delighters.  When a system does something for you that you didn't expect or even know you wanted can be a delighter, and many of the aesthetic choices made are definitely dissatisfiers.

Not all systems will become "self actualized" at the top of the hierarchy. There are reasons systems may never be developed into an attractive, easy to use system.  Sometimes the benefits don't justify the cost.  If a system is going to be retired, no new development will be funded.  The model does not address the downward pressure of cost or limited resources against the desire to climb the hierarchy.

After weighing these criticisms, my thoughts lately have changed.  I no longer see the factors in a hierarchy, but as competing priorities for a limited pool of resources.

All systems development teams must prioritize their time and resources among the four factors.  To increase the resources for usability, attention is taken away from the others, unless additional budget is found. There is no ideal allocation of resources to each of the factors.  Just as no two applications have the same requirements, the needs of the organization or users may be different from one project to the next.  Depending on the functionality needed, performance environment, age and training of the users and the visibility of the application in the marketplace, any one of these factors may be weighted more heavily during development.

The allocation of resources may change over time as a system matures.  Once the application is established or as competition enters the market, balancing the factors may become a higher priority.  The main point is the factors must fight for space within a given budget of resources and energy. 

Traditional systems may follow the hierarchy early in their evolution and favor functionality over any other factors.  Systems like mainframes and legacy systems may have interfaces considered unusable by modern standards.  They may be difficult to learn and use, involve obscure and arcane codes, or even paper punchcards. Younger users may not believe it, but there was a time before graphic user interfaces.  Many of these systems still exist in organizations because they work.  They do something relevant for the company and they haven't caused enough pain to be retired or upgraded.  Because these systems do what they do well, they no longer receive funding, and the resources they do get are focused on maintaining the system, not upgrading functionality or improving the user experience. 

On the other end of the spectrum are the trendy novelty applications that take advantage of trends or new developments and are seen as the "gee whiz" stuff for a limited amount of time. Consider new developments such as animated gifs, scrolling marquees or flash intro pages.  These toys don't add much functionality to a website, and are mostly eye candy. For the most recent examples, turn to the iPhone applications.  Developers saw a rich media device with the novelty hooks of a touch-screen and accelerometer and rushed out the technological equivalent of cotton candy such as the virtual lighter (moves as you move the phone), koi pond, virtual beer and light saber. These applications have next to no functionality other than momentary amusement.  The performance of the application is not a focus as it doesn't do that much to start with.  Likewise, if it doesn't do much, it won't be hard to use.  These applications have a limited shelf life as the novelty dies, but for the brief period of time, they can be successful.

I have to thank several people for challenging my thinking and discussing the concepts with me, including Matt Sanning and Greg Moore.  These thought exercises, like the iPhone apps, may not be the most productive things, but they keep me entertained.



Created: Thursday, 21 August 2008 Written by Gary Elsbernd

“Using Billion-Dollar Satellites to Find Tupperware in the Woods”

What do you get when you cross an old Boy Scout with a technogeek who loves toys?  Geocaching.  Geocachers hide treasure boxes in the wild as well as urban settings and post the GPS coordinates online.  Other geocachers load the coordinates into their GPS receivers and hunt for the caches.  You sign the log in the cache and then sign online.  Your online profile tracks the number of finds, hides and types of caches found.

It amazes me that I can’t get my boys to go for a hike with me, or go for one myself for that matter.  Walking for walking’s sake?  No way.  But if there’s a geocache at the end, I’ve walked up to 4 miles each way, and recently completed a cache that required wading through a creek six times each way to find caches.  I used to travel for work quite a bit, and would return to my room in the evenings and work.  Recently, I’ve been to Seattle and Boston and spent evenings walking, up to eight miles a day, to grab caches in a new part of the country.

Geocaching is also a community.  There are socially accepted guidelines governing behavior (for example, if you want to be looked down on, log a cache more than once or “find” one of your own caches) and forums for sharing ideas as well as bitching and moaning.  The community is administered by local reviewers, such as Glen – RattlingCrew – in Salina, and online by a team of moderators.  All of these are responsible to GroundSpeak, the owners of, who set the rules.

Some random thoughts:

  • Log the caches you didn’t find.  A “Did Not Find” (DNF) log lets the owners verify the cache is still in place, and warns future cachers that this may be missing or difficult. I’ve had as much fun on some DNFs as I do on caches, and log the experience, regardless of the outcome.
  • There are different kinds of caches.
    • Traditional caches include a container, from a small magnetic container the size of a pencil eraser up to an ammo can, and a logbook.  To claim a find, the cacher must sign the log.  Period.
    • A multicache takes you to one set of coordinates where you are given the coordinates for another stage.  Most are two stages, but I completed a nine-stage multi in Topeka once (FTF!)
    • A puzzle cache requires the cacher to figure out a code, clue or other puzzle to determine the location of the cache.  Sometimes you can solve the puzzle at home, but sometimes you have to solve the puzzle using clues at the location.  If you have to do something in addition to signing the logbook, for example, hide a cache of your own or sign the logbook in verse, that is also considered a puzzle cache.
    • Virtual caches are no longer allowed to be created, but there are a few out there.  Those take you to a location and require you to send an email to the owner verifiying you were there by answering a question that can be answered by looking around on-site.
    • Earthcaches are a special breed of virtual in that they are educational about some geological formation.  These are still approved by Groundspeak.
    • Webcam Caches require you to go to a location covered by a public webcam and have another person grab a screenshot of you.  These are no longer approved by Groundspeak.
    • A.P.E. Cache – these were a tie-in with the Planet of the Apes movie (not the Charlton Heston one, the Marky Mark one).  Thirteen caches with props from the movie were hidden around the world.  Of those thirteen, only two are left – one in Brazil and one in Seattle (I found that one).
    • Events, CITO Events, Mega Events – these are all gatherings of cachers and are logged as attended.  They do increase your find count, but are usually just fun gatherings.
  • FTF – First to Find.   This is considered an honor by some, and as an early cacher I raced to newly published caches, only to be beaten by Kstatealan most of the time.  I have a few now, so I’m not as competitive about it.  I usually let newcomers and FTF hounds test the coordinates first before trying them out.  I’ll grab one when it’s available, but I don’t reschedule my time to get one.
  • CITO – Cache In, Trash Out – this is motto of geocachers.  We pick up trash along the trails to leave the woods better than we found them.  CITO events gather multiple cachers to clean up an area or park.
  • Log shortcuts – TNLNSL (Took Nothing, Left Nothing, Signed Log), TFTC/TFTH (Thanks For The Cache/Hide), ROOF (Ran Out Of Fun – usually on difficult or unpleasant cache locations).