Shorewalker
  • Home
  • Site-building
    • Content management systems
    • MODX
    • User experience, user persuasion
    • Website project management
  • Public policy
    • The Finkelstein Review's fatal flaws
    • The broadband cargo cult, dissected
    • High-speed rail: an expensive hobby
    • Big infrastructure, big uncertainty
  • Culture & tech
    • Washed ashore: a list of links
    • Bruno Latour and the end of postmodernism
    • Photographing Wilsons Promontory
    • How hacking really works - and how we're making it easier
    • In defence of George Lazenby, the Aussie James Bond
    • ABC Spirit Of Things issues
  • Archive
    • The CEO Magazine columns
    • The Age/SMH columns
  • About
  • Search
  •  
  • Archive /
  • The Age/SMH columns /
  • Avoiding your own "Florida ballot debacle"

Avoiding your own "Florida ballot debacle"

By David Walker (Google profile)

florida

We have all just watched the most famous usability error in the history of information design: the Palm Beach, Florida, ballot paper, designed by Palm Beach County Supervisor of Elections Theresa LePore.

The statistical evidence suggests that the ballot's design caused a significant number of US electors to accidentally vote for fringe right-winger Pat Buchanan instead of Al Gore, and ensured many thousands more voters in the pro-Gore Palm Beach district would accidentally spoil their ballot papers.

So here, courtesy of Ms LaPore, are a dozen steps you can take to ensure your Web site doesn't suffer from "Florida ballot errors". If you remind people how better usability could have changed the course of the US presidency, they may pay a little more heed to Web site usability.

  1. List all your requirements, and seek to fulfil them all. The besieged Ms LaPore got into trouble because she tried to create a large-print ballot that elderly voters would find easier to read. But as she made the form more readable, she neglected other requirements for a usable ballot. The result: you could read the form at 50 paces, but you might not be able to vote with it.
  2. Assume many of your users will ignore or misunderstand instructions, even simple ones. No-one reads instructions. Not Democrats. Not Republicans. Not PhDs in cognitive psychology. Not even cocky foreign political columnists suddenly presented with the irresistible opportunity to poke fun at American voters.
  3. Specifically, assume many of your users will mistake non-verbal cues, such as the Florida ballot paper's now infamous arrows.
  4. Do not assume your user will take the task as seriously as you'd like. Some observers have declared that if people won't take a few minutes to work out how to fill the world's most powerful office, their votes shouldn't count anyway. A pox on that hindsight. Not everyone thinks their individual vote is as important as other things that may be going on in their life - organising a kids' party, visiting a sick friend, finishing that assignment. (Actually, in the case of voting, that usually holds true for a given individual. Except if you live in Palm Beach County in the year 2000 ...)
  5. Assume users will try to interpret your design by reference to more familiar designs. The Palm Beach ballot required users to "read" the ballot in a zig-zag fashion, rather than reading right to left or working down a list.
  6. Put yourself in your users' voting booth. As former Apple interface guru Bruce Tognazzini has pointed out, electoral officials seem to have focused on showing all ten pairs of candidates. But most voters don't look at those ten pairs. They focus on the pair they have already decided to back. The Palm Beach ballot made this task peculiarly difficult for Gore/Lieberman voters.
  7. No matter how much you try, you are not your user. Most people who design information systems become over-familiar with them, to the point where, like Ms LaPore, they can no longer see likely problems.
  8. Your friends, colleagues and peers are not your user either. Ms LaPore asked people much like her to review the ballot paper, and they found nothing wrong with it either.
  9. Resist the lure of unnecessary innovation. Chances are that your problem has been solved before. Find the best existing solutions and examine them. If you can't adopt one, then adapt it. And if you can't adapt it, make sure you ...
  10. Test, test, test - unless you have plentiful existing evidence that your answer has worked before in exactly the same situation. You need to test as few as five or six people to spot many major usability problems. You may need to test on more subjects if you want close to 100 per cent of your audience to complete the task - say, if you're organising voting for the world's most powerful office.
  11. Encourage different parts of your organisation to adopt a well-researched solution to the same problem. If US ballot administrators had simply written and publicised a paper showing how different ballot designs succeeded or failed, a standard would probably have emerged over time. Therese LaPore didn't adopt the standard solution because the US voting system had never taken the time to come up with a solution she could adopt.
  12. Act as if undetected usability errors will surface eventually. They may not. But by assuming they will, you're far more likely to create a usable design. One that won't make you look like an idiot when you suddenly attract the attention of every media outlet in the known universe.

Filed on 18 January 2012 and last updated on 18 January 2012

Copyright 1995-2025 David Walker

Page info

...
...
×

Next Previous Slideshow Download