40th Anniversary of the Moon Walk

Created: Tuesday, 21 July 2009 Written by Gary Elsbernd

There is so much being made of the 40th anniversary of the moonwalk going on this week (rightly so).  Here’s some more facts you might not have heard:

The Boy Scouts of America teaches young people to be good citizens and trains them to become leaders. These qualities are also found in the U.S. astronaut program.

Of the 312 pilots and scientists selected as astronauts since 1959, at least 207 have been identified as having been Scouts or active in Scouting.  The list includes:

  • 39 Eagle Scouts
  • 25 Life Scouts
  • 14 Star Scouts
  • 26 First Class Scouts
  • 17 Second Class Scouts
  • 13 Tenderfoot Scouts
  • 3 Explorers
  • 10 Webelos Scouts
  • 25 Cub Scouts
  • 1 King’s Scout
  • 2 Wolf Scouts
  • 32 with unknown ranks, including 27 who were Girl Scouts.

Of the 27 men to travel to the moon on the Apollo 9 through Apollo 17 missions, 24 were Scouts, including 11 of the 12 men who physically walked on the moon’s surface, and all three members of the crew of Apollo 13.

All three of the astronauts who died in the Apollo 1 fire, four of the seven who died in the Challenger launch explosion, and five of the seven who died in the Columbia re-entry explosion were Scouts.


This week makes me proud to be both an American and a Boy Scout.


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.


More Articles ...