Design anti-patterns: Exploding Whale

An early step in problem solving is the process of problem decomposition, whereby a large problem is broken down into smaller, managable parts, and each problem part is attacked in turn. An advantage to the technique is that it can often allow simple solutions to be successfully applied to the constituent parts that, by themselves, wouldn't scale up to the full undecomposed problem.

Problem decomposition can go wrong when the problem is not sufficiently decomposed and an overly-simple solution is applied to the constituent parts. In the design of information websites this is seen clearly when individual pages appear as large masses of text with different topics and headers on one page. In such cases the designer may have committed to a simple navigation scheme before understanding the amount and complexity of the information he or she was dealing with. In some cases the project was underfunded or understaffed and the unfortunate designer was left with only bad choices before the time or money ran out on the project. In any case, the consumers of the information are left to struggle with a site with minimal navigation and verbose pages of text. Many FAQ pages are designed as such not because customers ask the questions posed on the page, but because the designer hadn't the time and/or ability to break the information down properly and supply adequate navigation.

The name of this design anti-pattern derives from the Mother of All Problem Decomposition failures, the Exploding Whale incident, popularized by a newpaper column by Dave Barry. In his column Barry describes an attempt to remove a whale carcass from a beach by the use of dynamite. For many years the story was considered an urban legend until a video of the event was discovered and circulated online.

Some things to note about the Exploding Whale. The first step in the solution to the problem (dynamite) was regularly and successfully applied to the removal of large rocks from roadways, so the engineers had reason to believe it would work in this case. As noted in the video of the newscast, they had never dealt with whale removal before, and were inexperienced in this particular domain. The engineers incorrectly assumed that pieces of the carcass would be rendered small enough to be handled by the second part of the solution (the numerous scavengers). This failed in two ways, as humorously described by Barry. Many of the carcass pieces were too big to be eaten by scavengers, and the scavenging birds were frightened off by the blast.

Of interest, the newsman responsible for the video notes at the end of the segment that the engineers will, in the future, know "what not to do" when removing a whale carcass. He understood that this event qualifies as an anti-pattern.

Digression: Christmas Truce of 1914

The song Snoopy's Christmas by the Royal Guardsmen gets a lot of play in the U.S. during the Christmas season. It's a perfect little late-1960's pop song with great hooks and a singable chorus and a nice message. More than just a hit novelty song for a short-lived band, however, it's based on an incident that occurred during World War I.

In what became known as The Christmas Truce of 1914, German and British soldiers fighting in France defied their commanding officers and celebrated Christmas with each other in no-man's-land between the barbed wire and trenches. As in the song, the Germans initiated the truce. The soldiers exchanged presents and sang carols. They played football (soccer) with each other. The truce lasted only a day in some places, in others it lasted into the new year. After the truce ended the massacre began again.

The truce is one of many stories that demonstrate that the people in the trenches often have a good deal more sense than their supposed superiors. A lesson for people who would aspire to be leaders.

Design anti-patterns: Serial jigsaw puzzle

Anti-patterns describe approaches to problem solving that can potentially work well in one domain but are applied to inappropriate domains, leading to negative outcomes. I refer the reader to Wikipedia's excellent description and collection of anti-patterns.

Nearly every project I've worked on has employed some sort of issues list that is used to track project issues that need to be resolved. An issue usually includes a number, issue name, date opened, priority level, name of a responsible party, and due date. Project leads work the issues list on a regular basis, usually starting with the oldest issue, pushing the responsible parties to provide solutions so the issues can be closed. This is a good technique for ensuring that issues are resolved on a timely basis and the project is kept on track.

A problem occurs when the technique is applied to the early stages of user interface design. Design is by nature iterative. Good designers sketch high level solutions to design as requirements are gathered, but resist making a commitment on some individual aspect of a design until the framework is understood. Designers also produce alternative designs to one problem as a way of exploring different solutions to a single problem.

Project team members who want to "help" with design will often place design issues on the issues list early in the project. Where will the navigation bar go? How many sections will this web site have? Will we offer help on every page, and for which fields? In the worst-case scenario, a business contact is named as responsible party, bypassing the designer completely. The project lead then works the issues list, pushing to close the interface issues before the design framework is complete.

Imagine trying to construct a jigsaw puzzle this way: you're handed a bag of puzzle pieces. You don't know the dimensions of the puzzle, nor what the completed picture looks like. You're allowed to reach into the bag and take one piece, then place it on the table in front of you. Once you've placed the piece you can't move it. You take the next piece, and place it on the table. Proceed in this fashion until the bag is empty. What do you think the picture will look like?

That's the issues-list approach to user interface design. If you find yourself on a project with a project lead that doesn't understand design take the time to explain how design works, with reassurances that the dates can still be met. And, in the early stages of design, keep those design issues off the issues list.

One semester down, seven to go

It's the last night of my first term in my MBA program. No final test tonight, just a presentation and report to turn in. It's a relief to be done with it. I knew the program was going to be a lot of work, and I don't mind work, but I'll need to think about whether to continue. The next semester starts in a month.

Ordering your IVR menu options

You might think that, after all these years, putting menu options in order in an IVR would be a solved problem. It's not. There are some general rules for ordering menus, like "order by frequency of use," and exceptions to the rules, like the "specific-to-general rule." However, the observed rules don't account for an important part of the IVR design, and that's the caller's needs for accomplishing tasks.

You have some top-of-flow menus in which the caller is offered several services. Main menu is always a top-of-flow menu. The order of options can influence what the caller selects, and you have some latitude in ordering those items. Let's consider a bottom-of-flow menu, like the presentation of a payment amount. In any pay-by-phone system the caller is given a payment amount and then offered the option to pay using the IVR. Since the company is taking money from a customer, they'll usually make it pretty easy to talk to a representative at this point. How do you order the menu options?

I noticed when I wrote the options for this menu that I followed an unnamed convention that I call psychological distance from the task. I've seen this done so often, and I do it so often, that I don't even give it much thought. In the pay by phone system, from the caller's perspective, they need to select an account to pay, get the payment amount, decide how much they want to pay, indicate their method of payment, pay some or all of the bill, and make sure the company understood their request. Then the caller continues with another task or set of tasks. Here's the ordering of this bottom-of-the flow menu: Repeat amount, Make payment, Main menu, Talk to agent.

How is this related to psychological distance from task? The options are, abstractly, Re-do this step, Go to next step, Leave this task, Leave the IVR. That maps pretty closely to decision the caller makes when presented with an amount. If a caller intends to pay a bill they have to be sure how much the bill is for. They are at the "get payment amount" step. They won't move to the next step until they have the amount. If they didn't hear the amount the only thing they are thinking about is hearing that amount again.

The ordering is also consistent with what the company prefers the caller to do--serve themselves using the IVR before asking for an agent. Some terminal state bottom-of-flow menus include the phrase, "if you're finished you may hang up." Where does that belong in the menu? Obviously, at the end, since it means Stop Contact with the company.

The missing piece in all of this, and the thing that makes ordering menus difficult sometimes, is knowing what the caller wants to do next. In the pay-by-phone example it's obvious. In many others it isn't so easy. The lack of a good task analysis and understanding of why people call leads to the disagreement over ordering menus and menu options. That's why "best practices" rules for ordering menus will never be enough.

Overcoming the "work at home" stigma

Surveys of office workers show that they tend to think that people who telecommute get away with murder. It really does not help when Scott Adams publishes cartoons that cruelly mock telecommuters. OK, so we work at home types don't dress up to go to the office, and we aren't distracted with constant interruptions. We're judged on our output rather than on appearance and schmoozing ability, and that's really a good thing.

Adams gave a nice interview on his experience with working at home. He's right about the eating part. It's really hard to stay out of the kitchen during the day.

Tricking the caller to stay in the IVR

I don't think I've worked on an IVR project when the business people didn't suggest using "tricks" to keep callers in the system. You know what I mean by tricks: disabling the zero key, or playing a routing menu when zero is pressed, or using a non-zero key for transfers, messages that falsely state long queue times, or putting the caller back in the system after they request a transfer. Often the tricks are used in IVRs that are pure misery to try to use. Businesses have a reason to try to increase automation rates - it saves them money. The best way to increase automation rates is to ensure that your automation is useful and usable to your customers. Unfortunately, getting your IVR to that point takes a lot of work, and keep-'em-in tricks are simple to implement. Some business folks take the easy path, and insist on tricks.

The tricks almost never work, or don't work the way the owners intend them to work. If a caller really wants to talk to a representative they'll figure out a way to do it. Eventually. And once they get to a real CSR after they've been plagued by IVR tricks they often aren't very happy. I listen to a lot of calls between customers and IVRs and then follow the calls into the call center. Some customers remain calm with the CSR after a poor experience in the IVR. Others do not, and take out their frustration on the CSR. No one goes away thinking better of a company after a miserable IVR experience.

My recommendation to companies considering using tricks to keep customers in the automation: work on the quality of your IVR first. Monitor, survey, read the reports, improve. Once you're satisfied that the IVR operates flawlessly you can consider using some small inducements (a nice way of saying a subtle trick) to keep callers in the IVR. If it's done properly you might be able to increase your automation rate slightly with no cost to the user experience. However, it all depends on first getting the IVR right. Do the hard stuff first, worry about the tricks later.