What Every Designer Can Learn From Rimsky-Korsakov
by
Gary J. Dickelman

This article originally appeared in CBT Solutions Magazine, July/August 1997.

It was a dark and stormy night. The locomotive left Chicago heading toward Columbus. It was 9PM. The train crept along through a dense, chilling fog...at 30 miles per hour. A second locomotive left Columbus heading toward Chicago at 9PM, also traveling 30 miles per hour - and on the same track! The distance between Chicago and Columbus is 350 miles. *The plot thickens!* At the moment the train left Chicago, a bumblebee sitting on its engine's windshield flew toward the Columbus train at 40 miles per hour. When it reached the Columbus train, it instantaneously headed back toward the Chicago train (still at 40 miles per hour) - and repeated the process until the trains collided. Question 1: What was the last thing that went through the bee's mind before it got squished? Question 2: How far did the bee travel?



Figure 1: The Bumblebee Problem


If your answer to #1 is "the abdomen" then congratulations! For #2, I can hear, "AAaahhhrrggghh!!" - from almost everyone. Right? As a math teacher, father, and human being, I know too well the agony inflicted by word problems ("story problems" if you're from Indiana). As a designer of computer systems, I hear the same cries from "end-users" whose attempts to master applications are the moral equivalents of solving problems such as this one. The above exercise is for many a metaphor for torture and is therefore a good representation of many contemporary computer applications. It follows that the activities of designing performance centered systems to solve such problems is a first step toward creating applications such as Quicken. Ready?

The solution to a problem is nothing more than a restatement of the problem in simpler terms. Psychologists refer to these equivalents as cognitive isomorphisms - fancy term, but very descriptive. The best such example I've seen is the "Game of 15" from Donald Norman's book Things That Make Us Smart: Defending Human Attributes in the Age of the Machine (1993, Reading, MA: Addison-Wesley Publishing Company). I won't repeat all the details here but refer you to the book or to my review of it in the January 1995 issue of the Performance Improvement Quarterly: Things That Help Us Perform: Reviewing the Ideas of Donald Norman.

The "Game of 15" is a two-person game where the players alternatively select numbers from the digits 1 through 9 until one player has a combination of three (any three) which adds up to 15 or until the game ends in a draw. Try playing the game; it will most likely be confusing insofar as you have to keep the rules in your head (if you're at all clear on them), you have to keep track of which numbers have already been selected, and you have to add all the possible combinations of three numbers from those you've selected - plus keep track of the same things for your opponent and implement a strategy for winning.

Analysis of the game ultimately yields a cognitive isomorphism that is the game of tic-tac-toe - and a myriad of lessons about performance centered design. The bumblebee problem, while more complex, presents a better example of the processes that we must model for performance centered interface representations because it includes dynamics - a time dimension with things happening over time, not unlike business processes. Think, for example, of a system designed to manage retirement plans. They typically involve allocating investment dollars among several funds (investment vehicles) which comprise the plan. The best way to allocate your investment dollars at a point in time depends on fund performance in the marketplace - which varies with time. So the retirement plan problem is dynamic - like the bumblebee, but unlike the "Game of 15."

The goal is to find a representation of the bumblebee problem that captures the dynamics but does not obscure our understanding of the problem - or a solution - with irrelevant or confusing data. What, I hear you cry, are irrelevant data? Any one or combinations of the following:

  1. things that do not contribute to the process model;
  2. things that are confusing to the people who have to understand the problem; or
  3. things that generally include more description, attributes, or behaviors of the process than are necessary for solution.


In other words, the best representation is found in the Performance Zone:



Figure 2: The Performance Zone

A common error in modeling is to capture every process step so that the model is one-to-one with reality. A model by definition is an abstraction of only those elements of reality that are necessary to focus on problem and solution - nothing more or less. What would a one-to-one model look like for the bumblebee? Simple(!):




Figure 3: Bumblebee model that is one-to-one-with-reality.


Warning: Mathematics follow! In the spirit of Gershom's Law (CBT Solutions Oct./Nov. '96) I'll include no more math than is necessary to illustrate the point (which is to repulse you nonetheless). Still, there may be more than the faint-of-heart can take - which magnifies the point about bad models. There is a terribly complex way to look at the bumblebee problem, which is precisely the one-to-one-with-reality model shown above. With this model the total distance flown by the bumblebee is calculated as follows:



Figure 4: Flight of the Bumblebee

The bumblebee's flight is x1+ x2+x3+ x4+x5+... which can be symbolized in an even more intimidating way as

Here is perhaps a better picture of what you'd see if you focused on the bumblebee as it flew back and forth between the trains:


Figure 5: Total distance traveled by the bumblebee

According to my trusty pocket executive planner, the distance between Chicago and Columbus is 350 miles. By this reckoning (and a little algebra - trust me), the expression becomes:



or

200(1 + (1/7) + (1/7)2 + (1/7)3 + (1/7)4 + (1/7)5 + . . . )

 This is a bizarre mathemagical things called an infinite series. Take out your calculator and add - and see that the sum is:

233 1/3 miles.

While this series is not particularly difficult to sum, the subject of doing so is nonetheless addressed in a typical second year calculus course. Like the first rendering of the "Game of 15," it's clear that the model and the solution do not match the performer's way of doing things (Ugh! Math!!). Not only is there too much information, but the representation obscures the problem for most people rather than helps to find a solution.

A much simpler approach is to consider the context - the boundaries of the problem - rather than just the bumblebee. Too narrow a focus is a corollary to the error of building models that are one-to-one with reality. When modeling business processes for EPSS design, properly defining the boundaries of the process is often the key to finding the representation that hits the Performance Zone. The context for the bumblebee is the physical constraints of the approaching trains and their inevitable crash. The trains are traveling toward each other at 30 miles per hour, so for each moment they are in motion the distance between them is decreasing. They will crash at time t hours when 350 = 30t + 30t. Solving this school algebra (versus calculus) equation shows that the trains crash when t = 350/60 hours (no need to simplify). The bee obviously gets squished at this time, right?

Think about the flight of the bumblebee. It never stops flying. It instantaneously changes direction when it reaches a train, according to the statement of the problem. What this really means - from a modeling perspective - is that the direction of the bumblebee is irrelevant. It travels 40 miles per hour for all 350/60 hours that the trains are in motion. Now do the arithmetic:

40(350/60) = 233 1/3 miles.

This is a much simpler way to look at the problem and a much simpler calculation to perform than summing an infinite series! Mathematicians may be interested in the latter, but the average performer - like you and me - is not.

Consider, for example, a business EPSS that was intended to support the New Business Analyst for group retirement plans in the home office of an insurance company. The business problem was analysts receiving incomplete and/or incorrect information on applications for new retirement plans. A process model revealed a great deal of their time was spent conducting research to complete and correct the applications. At the same time, the company was unable to deposit the premiums - which was a cost to the business as well as a risk of being penalized according to SEC regulations. An EPSS was suggested for the New Business Analyst that would assist with identifying the errors and researching the problems - at a potential cost of about $150,000 and six months development time.

On the other hand, when the team sought to define the boundaries of the model, it was discovered that the Field Office Producers were the culprits. They had no incentive to provide complete or correct information, but would earn their commissions provided they identified legitimate customers and sent applications to the New Business Analysts - whether or not correct or complete. There were throwing the research problems "over the wall" -and why not? They had no incentive to do otherwise. The Field Office / Home Office boundaries of the model suggested a much simpler EPSS: align incentives. A simple on-line laptop application form that the Field Office Producers were required to use - and a few new rules imposed by the Field Office Managers - solved the problem. The cost was about $5,000 and took only three weeks to implement. Within the first month of implementation new business monthly bookings were up by over $1.5M.

Performance centered design of a system to support solutions of such problems as the bumblebee (or similar business applications) includes two important elements: a model that falls within the Performance Zone and a minimalist use of the computer to organize information and perform calculations for you. The Performance Zone model for the bumblebee is the one that reflects the right context: the reality that the trains will crash and when. The performance centered interface is the one that organizes the model and performs the calculations. The following dialogue is a suggestion:



Figure 6: Suggested Interface Dialogue for the Bumblebee

Just fill in the speed of the trains and the speed of the bumblebee, press the Calculate button, and you're done. The system performs the arithmetic:

total bumblebee distance =
(starting distance between trains)x(speed of bumblebee) ¸ (2x train speed)

An additional element of performance support might be a behind-the-scenes check that the bumblebee flies faster than the trains (otherwise it's stuck to the first train and travels 175 miles - which is how far the Chicago train travels before crashing into the Columbus train at the half-way point). You may even wish to consider a system enhancement which allows for the trains to travel at different speeds. The "Help" button might give a brief explanation of what's being calculated - if learning is a goal of the system. Some might argue that the latter needs to be included because performance centered systems must manage the knowledge component of the process. Good idea - particularly in this day and age where knowledge has greater recognition as a corporate asset.

The model we've ultimately adapted - the one in the Performance Zone - satisfies an important principle of EPSS development: the one who does the work must be the one who benefits. As Jonathan Grudin puts it,

When those who benefit from the technology are not the ones who perform the work, then the technology will either fail or be subverted.

System development which proceeds according to the more complex model often occurs because of misaligned incentives: the more difficult representation is often more satisfying to the engineer or designer. It presents the greatest challenge and therefore produces the most satisfaction when solved. The underlying solution to the series model - which looks like this -



- may solve the problem, but it certainly doesn't match the performer's preferences (i.e., it's intimidating, to say the least), and contains way too much irrelevant information, which we see in comparison to the simpler model. In fact, the simpler model focuses only on how long the bumblebee is in flight at 40 miles per hour, not how far it goes back-and-forth relative to the trains - which is what the above expression reflects.

So what's the job of the EPSS designer? Discover where the fluff is, remove it, and leave a clear, elegant model for the performer - while addressing the compelling business need. On the latter point, note that the word performance in Electronic Performance Support System is business performance. It is enabled through human performance, but is fundamentally business performance. From this perspective the flaw in the more complex design model is an assumption that human performance alone is at issue. Indeed, human beings can learn about convergence of infinite series in time. How often have you heard a designer (or sponsor) say, "So what if the system is complicated. It works, and the 'end users' will just have to learn it." Perhaps, but the business cannot afford the luxury of time to develop the more complex system, time to develop the training programs, or time to train "end users" over and over and over. When the business is the driver, performance occurs when an environment exists where the elegant solution is represented by the system; that requires a very different skill set and perspective to develop than merely addressing human performance - as the bumblebee has demonstrated. The business, after all, is the customer; systems must be developed in the Performance Zone.

The bumblebee teaches another important lesson through Rimsky-Korsakov's music. "Flight of the Bumblebee" is just one of many "perpetual motion" (moto perpetuo) pieces. The score is a relentless sequence of eighth, sixteenth, and thirty-second notes, which forms a breathtaking composition - quite literally! As a brass player, I once had to master breathing in through my nose while simultaneously blowing out into the instrument to execute Rimsky-Korsakov's masterpiece. It was doable, but incredibly difficult and took an excessive amount of time to master. The result was art - and there were those who would pay for it in the concert hall. When we introduce similar complexity and time to competence into a computer system, both the performer and the business suffer. Ultimately, there are no patrons willing to pay the prohibitive cost.

Performance support systems become a reality when appropriate design methodologies - such as modeling within the Performance Zone - are incorporated into the systems development lifecycle. It's refreshing to see system sponsors requesting performance centered design, actively seeking the right team players early in the lifecycle, and measuring the right things - like time to performance - to evaluate success. But for every such project there is still the traditional one, which satisfies the designer rather than the performer at a huge cost to the business. When these systems are rolled out, you can hear the unfortunate cries of both the performers and the business: "Son-of-a-BEE!

Gary J. Dickelman is the Vice President for Mission-Critical Applications at Guru, Inc., of Herndon, VA. He specializes in the application of human factors engineering, learning technology, information technology, and business process engineering to performance centered systems. He is a contributing author to Using Computers in Human Resources (Jossey-Bass, 1992) and The Instructional Technology Handbook (McGraw-Hill, 1993). You can reach him at gdickelman@pcd-innovations.com.

Bibliography

  1. Cooper, Alan (1995), About Face: The Essentials of User Interface Design, Foster City, CA: Programmers Press / IDG Books Worldwide
  2. Dickelman, Gary J. (Oct./Nov. 1996) Gershom's Law: Principles for the design of performance support systems intended for use by human beings., (CBT Solutions Magazine)
  3. Dickelman, Gary J. (January 1995), Things That Help Us Perform: Reviewing the Ideas of Donald Norman, (Performance Improvement Quarterly)
  4. Lackoff, George & Johnson, Mark (1980), Metaphors We Live By, Chicago, IL: The University of Chicago Press
  5. Laurel, Brenda (1993, 1991), Computers as Theater, Reading, MA: Addison-Wesley Publishing Company
  6. Norman, Donald A. (1988), The Design of Everyday Things, New York, NY: Doubleday
  7. Norman, Donald A. (1993), Things That Make Us Smart: Defending Human Attributes in the Age of the Machine, Reading, MA: Addison-Wesley Publishing Company
  8. Polya, G. (1957), How To Solve It: A New Aspect of Mathematical Method, Princeton, NJ: Princeton University Press

 1