Lessons Learned from an Election

I was in Tampa, Florida, in mid-November 2000 to attend the last of three IEEE Technical Activities Board (TAB) meetings for the year. TAB includes the presidents of all the IEEE societies and councils, so it's very much an international body, with members from many different countries. Of course, at that particular moment, it seemed that Florida was the center of the universe because of the contest over the state's vote in the U.S. presidential election the week before.

During conversations over meals and during breaks, the election was usually the center of attention, especially because the candidates and their supporters were constantly on television news programs. The question I heard repeated by attendees from both inside and outside the U.S. was "How could something like this happen in a country that prides itself on being the most technologically advanced in the world?"

The answer is easy, actually. This kind of thing happens everywhere, everyday, but the consequences aren't usually so important to so many people.

Technology Is Fallible

On 31 January 2000, an Alaska Airlines jet fell from the sky, killing everyone aboard, apparently because a jackscrew-one of the least expensive and least sophisticated parts of the aircraft-failed. Unfortunately, that low-cost part was crucial to the operation of the plane's horizontal stabilizer, and without it, the pilots were unable to control the pitch of the jet's nose, thus dooming the craft, its five-person crew, and its 88 passengers.

Compared to that tragedy, the tale of the "butterfly ballot" and hanging chads seems trivial-except that the future of the U.S. and the world could hinge upon failures of technology in the November 2000 election in Florida. The pundits were quick to point out that the large number of punch card ballots rejected by the tabulating machines as invalid (about 150,000, or 7.5% of the total votes cast in Florida) was not unexpected for that type of voting system; what was unusual was the very small number of ballots (about 500, or .025% of the total votes cast in the state) that would prove decisive in determining the winner.

In today's high-tech world, both the jackscrew involved in the airliner crash and the punch card involved in the election controversy are rather primitive technologies; their origins can be traced back hundreds of years. And like the O-rings that caused the Challenger explosion in the 1980s, the jackscrew and the punch card are simple, inexpensive devices whose failure at a critical moment had consequences out of all proportion to their complexity and significance.

Communication Expertise Is Ignored

For more than 100 years, the discipline that we know as document design has promoted the use of plain language, legible typography, effective spatial cues, and integrated text and graphics to ensure successful communication. The Florida election, however, shows that a century's good work in this arena had essentially no impact on the ballots that might be legitimately called the most important public documents of a democracy. In two important instances, this expertise in document design was ignored-expertise that might have resulted in a different outcome had it been noted and heeded.

It is ironic that the "butterfly ballot" was designed with the intention of making the names of presidential candidates large enough to be clearly read by the many seniors voting in Palm Beach County, Florida. Unfortunately, because of the number of presidential candidates, it was impossible to fit them all on one page of the ballot book if they were set in a suitably large typesize. Instead, the ballot book (into which the individual voter's ballot card was inserted) featured two pages of candidates' names flanking a single column of chads on the ballot card, one of which should be punched. The column of chads on the ballot card corresponded, alternately, to a candidate on the left-hand page of the ballot book and then a candidate on the right-hand page of the ballot book. To complicate matters further, the instructions circulated with sample ballots called for voters to punch the chad to the right of the intended candidate's name.

Electrical engineers know that they must post warnings and cautions when use of a product could cause injury to people or property, or other serious consequences. The problems associated with punch card ballot technology have been widely known to election officials throughout the U.S. for many years. Nonetheless, most polling places and punch card voting machines did not feature instructions to alert voters that they must punch the ballot with sufficient force to dislodge the perforated chads corresponding to the candidates for whom they intended to vote, When notices were present, they were not displayed prominently.

As a result, the county supervisors of elections failed to observe another principle of document design, that documents to facilitate the use of products be provided when needed and that those documents be clear, precise, and prominent. Document design should not be delegated to amateurs who mean well. Decisions about when and how to document products and their operation should be made by those who are experts in the field of communication and should not be left to chance. These should be conscious choices made with full knowledge of the consequences that those choices will have. We need to do a better job of promoting our expertise in document design to those outside the field of professional and technical communication. That expertise can indeed change the course of history.

The Users Get Blamed

The saddest lesson of all is that innocent parties-the voters in the 2000 U.S. election-are often blamed for technological problems. But did anyone test the usability of the ballots? Did anyone ask what types of assistance would support voters in performing this occasional task? Did those who conducted the election think carefully about who their "users" were and what problems those users might encounter in doing their civic duty? For the most part, the answers to those questions are "no."

Are those answers surprising? They shouldn't be to most engineers and professional communicators because we seldom take the time to analyze the users of our products or the tasks they need to perform with those products. Too often, we assume that users are just like us, when most of the time, we share very few traits in common with them. Too often, we assume that our product interfaces are transparent, that our procedure documents are clear and precise, that documentation is a luxury that can be foregone if the budget or schedule is tight.

It's no wonder that users frequently blame themselves when they aren't able to operate products successfully. The fact is, we regularly blame the users despite the fact that it is our products that fail them. Woe is us if our users ever realize that the failures of technology must be laid at the feet of those who created the technology.

The bottom line? When technology fails, we owe it to our users to accept the blame and act to ensure that it doesn't fail again.