This paper contains my comments regarding the usability of the Hart Voting System, focusing on the parts of the system I was able to evaluate during a short demonstration in September 2004 before its initial run in the State of Hawaii primary elections. I was able to informally evaluate the JBC setup and eSlate configuration process from the poll worker's perspective, the voting process, and the hardware components involved.

Throughout the demonstration I made note of potential usability issues, and I include recommendations as well as good points (highlights) and points of concern (issues). Interfaces from other evoting systems are provided for comparison, and I have also included points from various evoting system usability standard reports where appropriate.

These comments were submitted to the State of Hawaii Office of Elections, Hart Intercivic, and the Safe Vote Hawaii citizen's group to take under advisement.

I have been a professional software engineer and graphic designer for 11 years and am based in Honolulu, Hawaii. My relevant experience includes:

• Chief Interface Designer at Webify Solutions, where I designed the interfaces for their Web Services portal framework, WYSIWYG workflow applications, and enterprise HIPAA-compliant healthcare forms and applications (2002).
• Creative Director of CommerceOne.net, Commerce One's business-to-business Web portal, which included the design of interfaces for procurement and supplier/buyer marketplace applications (2000).
• Interface design of XML-based procurement systems, working with NTT and Veo Systems (1998).
• Design of ewallet application user interfaces at VeriFone, with three patents received in this area (1997).
• Initial interface design of the Kana CRM (customer relationship management) flagship application (1997).
• Interface design for the Internet Shopping Network, acquired by the Home Shopping Network (1994).

More information on my background can be found here.

I was shown the JBC (Judge's Booth Controller) unit and was shown the process of JBC initialization and registering each eSlate with the JBC. I examined the JBC's interface, hardware ports, and MBB (Mobile Ballot Box) door.

• I was impressed by the overall simplicity of the hardware design. The general philosophy I subscribe to is that you know you have a good design not when you can't add any more to it, but when you can't take away anything more. Hart appears to have followed this criteria - there are no extraneous symbol keys on the keyboard, keys are of the waterproof "chiclet" type, and the printer paper is waterproof. There are no sharp edges or corners to the JBC unit. Clearly the engineering team's long experience with designing medical devices shows here.
• The MBB door is secured by a serialized plastic security tab which can only be opened with a heavy cutter. This appears to address the MBB security issue brought up in the Ohio DRE report from November 2003. I did not check the JBC's bottom for other serial or manufacturer information, but the advantage of serialized tags is that these serials may be matched with JBC units for inventory as well as security reasons.
• The method of assigning eSlate devices to the JBC was straightforward. The way in which the 12 lights on the JBC are used for eSlate status as well as notification is immediately understandable.
• I appreciated how the relevant system information was printed upon startup - operating system version, time, date, etc., serving as an additional document for verification and testing.

• I am slightly concerned regarding the "CLOSE POLLS" button featured so prominently on the unit. As this button will only ever be used once at each polling location, it makes less sense to group it next to printer feed and screen contrast functions which may be used multiple times throughout the day. However, I understand that its current position will prevent poll workers, the sole users of this feature, from having to search for the function via the screen-based interface.
• I would have liked to examine the JBC's screen-based interface more - I am slightly concerned over the use of particular syntax and abbreviations as well as the consistency of time and date displays among multiple devices within the Hart Voting System. I do not know how internationalizable the JBC is, or how pressing an issue that may be. In particular, one should be able to specify a 12- or 24-hour time format.

I was guided through the beginning of the voting process and assigned a voter's access code so I could begin voting at an eSlate station.

• Spanish was printed on the access code receipt, although the State of Hawaii does not officially support Spanish.
• Faded ink on the receipts makes inverse text difficult to read.
• The thick black bar provides a visual affordance that makes the receipt recognizable, but is not necessarily an efficient use of ink.

• Ensure that localization is performed throughout all parts of the system via a centralized method to ease such efforts and ensure that all parts of the system are synchronized in regards to same.
• Instead of inverse text, use bold text for the receipt title. If extra languages are needed, place them on separate lines underneath the title.
• Separate the access code with thick solid lines and equal space above and below to make it easily separable from other content.
• Use full dates, 12-hour time formats (if specified in the localization process), and do not abbreviate "Precinct".

In general, abbreviations in the system should not be used, as noted in the Federal Election Commission's Voting System Standards (Volume 1, Appendix C: "Usability", link here). Although the standard in question applies to ballots, it should be equally applicable throughout the system to allow for maximum legibility and to avoid errors.

I entered my access code into the eSlate into order to begin the ballot entry process.

• Hart is to be commended for the design of the eSlate - it is rugged, simple, and safe.
• All of the buttons are of different shapes and are well designed in accordance to their function. Each are unique and instantly memorable in appearance, minimizing confusion regarding which button to push.
• The buttons and the selection wheel have a satisfying feel - the feel of the contacts in the wheel give appropriate tactile feedback that something is being done.
• When the text of the buttons is mirrored in on-screen instructions, the button text exactly mirrors that of the button labels (text is in a sans-serif font, all capitals).
• Screens that do not deal with the voting process directly have a consistent blue background. This makes it very clear when one is or is not in "voting" mode.

• Among data entry screens, color functionality, and labeling is not consistent (refer to the above figure).
• In the code entry screen, instructions are spaced far apart, scattering them and visually grouping them with other content, making them difficult to pick out quickly.
• Entry field labels ("Access Code", "Candidate Name") differ greatly in size.
• The color red, normally used for highlighting errors and important information, is used for empty box outlines as well as non-critical battery information.
• The text "Clear Last" is used to erase a character in the code entry screen, but the text "Back" is used to erase a character in other entry screens.

• Throughout all eSlate screens, use a common layout style, particularly for processes that do not involve voting. Use page titles consistently, in a bold/large font of the same size, either all centered or left-justified at the top of screens.
• After page titles, place instructions grouped together with adequate margins to separate them from other content. Instructions should be in a consistent font style, weight, size, and location. After instructions are shown for an entry method once, there is no need to display them again (unless usability testing shows otherwise).
• Ensure that the help information sentence is consistently at the bottom of each screen, in the same font, size, style, weight, and location.
• Ensure that the color red is only used for errors and to highlight important information that the user must know. Do not use red to outline empty content or to display non-critical information that the user does not need to be aware of.
• Boxes can be outlined once filled, but ensure that more than one space in a row cannot be entered, do not allow the user to begin entries with a space, and trim entries of trailing spaces.
• Use a consistently labeled button to erase entered characters. "Delete" may be a usable possibility.
• There is no need for voters to know whether or not an eSlate is battery powered - this label can be removed. If the battery is low, red "Battery Low" text can appear and the JBC alerted via the appropriate LED.

To Hart's credit, the use of color throughout the system is minimal, functional, and generally appropriate, much more so than other voting systems. The spare design allows for high contrast, less ambiguity, and ease of use by color-blind and color-impaired users.

The ability for legislatures to design the ballot is apparent in these three different eSlate ballot screens. However, since this is the most important process in the system from a voter's point of view, it is imperative that the design process:

• Be as easy to learn and use as possible
• Only allow for usable ballot designs that are visually and functionally consistent with the rest of the system as well as compliant with established federal and industry standards
• Be clear about design variations that are required by law in different locations versus those that are not
• Include consultation/review by one or more parties with usability expertise
• Allow for WYSIWYG editing, or at a minimum easy round-trip previewing. I understand such features were added to BOSS (Ballot Origination Software System) as part of Hart's Voting System 3.0, but noted that the system running the JBC was 2.3.x. Are these versions consistent?
• BOSS previews, aside from being printable, should also be exportable to PDF and/or other image formats so they may be emailed or otherwise made available to those performing content, legal, and usability reviews, as well as media.

Example 2 ("Sample County, USA") violates the IEEE P1582 Usability and Accessibility Standards (link here) by not showing where one is in the ballot process - this may be page one, but of how many pages? This label varies from design to design, reading "Page 1 of 2" in one layout and "Page 1 / 2" in another, where "/" is an abbreviation of "of", also arguably a violation of federal standards.

Precinct information and dates are in very different locations, fonts sizes, styles, and weights. Instructions vary in length. Some information (Example 2, "Write In") is aligned with the checkbox differently, a space-wasting and ugly way to imply different functionality. Some information is abbreviated ("REP", "DEM") in Example 2, again arguably a standards violation.

It was noted that in some screens where groups were disabled (for instance, if I voted for a Democratic candidate, Republican areas would be grayed out), the title of the grayed-out group could still be selected (highlighted in blue with the selection wheel). It is a fundamental usability tenet that if something cannot be acted upon, it should not be selectable.

• Hart should provide a minimum number of standards- and system-compliant ballot templates for legislatures that are consistent and preferably only customizable to the extent required by local law.
• Hart should enforce the use of a standard set of ballot widgets and labels (for instance, always specifying "Page X of Y") for clarity and consistency.
• Days in dates should not show leading zeros.
• Ideally there should be consistent areas for date, time, page, precinct, page title, and location information. The page title style should follow that of the rest of the system screens.
• Spacing between groups of information should be unambiguous and consistent, as in Example 1.
• Text alignment should be consistent.
• Leading and double spaces in content should not be allowed to be entered.
• There should not be any abbreviations for party names.
• Disabled (grayed out) information could stand to be in a slightly lighter shade of gray to provide better contrast - it appears too close to black (pending usability testing).
• Do not allow anything to be selected in blue with the selection wheel unless it can directly be acted upon by the user. Note that there is a difference between highlighting an area that one will be voting in (a red outline) versus selecting a thing to be voted or acted upon (a blue highlight). Example: when first displaying a ballot, outline the instructions in red, with nothing highlighted in blue. One more wheel click highlights the first candidate in blue and outlines the first ballot section in red. A blue highlight always means "if I press ENTER here, this will do something".
• Adopt the convention of putting "Write In" in parenthesis "(Write In)" so it can easily be distinguished from the names of actual candidates. Also, the phrase should be used consistently throughout the system ("Write In" versus "Write-In"). One may also add selection hints such as "(Write In: Select to Edit)".
• An exploration of less ambiguous methods of separating ballot sections (Example 1, "STATE", "COUNTY OF ORANGE") and subsections (Example 1, "Governor", "Attorney General") is encouraged.
• Ballot sections should be consistently formatted, such as in all capital letters, and subsections should should be consistently formatted, such as in all mixed-case letters.
• Exploration of alternatives to text in all capital letters is encouraged.
• Ensure that ballot navigation methods and labeling is consistent (refer to the user comment here).

As an example of how other systems handle some of these issues well, refer to the above figure, the ballot from the VoteHere Platinum system.

• Because the screen has a higher resolution and fonts are antialiased, a higher quality of information can be imparted.
• Candidate names and parties are fully spelled out, consistently aligned and formatted, and are easily visually separated.
• The paging widget at the top of the screen unambiguously shows where one is in the ballot.

As an example of how other systems handle some of these issues poorly, refer to the above figure, the ballot from the Diebold AccuVote system.

• Labels are chopped off and inconsistently spaced.
• The use of bevels, colors, and widget sizes is inconsistent and confusing.
• Scrollbar widgets are too close to the "Cast Ballot" button, inviting problems. This design error is reflected in the instructions! This is also a potential issue in the design of the VoteHere ballot.
• Superfluous bevels, coloration, and election total data appear at the top of the ballot. The user has no supporting context regarding the election's subject or date.

To their credit, Hart avoided putting a "Cast Ballot" label on the ballot screens, instead treating the summary as the last page of the ballot. This avoids a problem - in other systems, selecting "Cast Ballot" does not actually cast the ballot - rather, it allows the user to preview the ballot. Here, Hart follows another usability guideline - a button's label should reflect exactly what happens when the button is selected.

• Text is concisely summarized, allowing one to review a long ballot easily.
• The "Cast Button" image is shown next to the instructions, making it clear which button should be pressed to continue the process.
• The instructions are simple and ambiguous.
• Button labels mentioned in the instructions are in a style consistent with the style of the labels on the buttons themselves (serif font, all capitals).

• Not all of the instructions are in full sentences.
• The page title is inconsistent with page titles in the rest of the system and is easily looked over, as the style is too close to that of the style used to denote instructions and is grouped too closely to the instructions.
• There is no unambiguous indication that ballot casting is final; rather, it is implied.
• One cannot see the full names of the candidates.
• It is arguable whether the contest labels should be in all capitals. For some, all capitals appears as shouting; capital letters in proportional-width fonts also take up more space.

• Ensure that all instructions throughout the system are in full sentences. In this case, "Press PREV for the previous page."
• Experiment with slightly smaller font sizes and layouts so that the candidates' full names can be seen; at least increase the width of the "Selected" column. Discourage ballot designs that display candidate names last name first and/or in all capitals.
• Ensure that the "Ballot Summary Page" page title is in bold and/or a larger font and/or a style similar to that of other page titles in the system and that it is dissimilar enough from instructional text.
• Add text to ensure that the user is clear that the ballot casting process is final.
• Use mixed case and/or bold text for contest labels, pending usability tests.
• Exploration of alternatives to using all capital letters for contest names is encouraged.
• Visually separate the column headers from the content via better use of spacing and/or font style, weight, and size.
• If a race is empty and only one selection can be chosen for it, the text "No selection" should be shown (versus "No selections", plural). Better yet, use wording that does not require such a distinction, such as "Not selected".
• Emphasize ballot finality with wording such as "To finish voting and cast your ballot, press CAST BALLOT." This text may be shown in red if it improves usability.

Candidate naming - I noticed that the Hawaii ballot listed candidates last name first and in all capitals. Not only did it make the candidate names harder to read on the summary page, but I note again that the practice is in violation of federal eballot design standards. Hart should consider other methods that allow full names to be displayed while allowing the listing to be concise and easily reviewed.

Page titling - it must be very clear that the voter is in "ballot review" mode versus "ballot voting" mode - this is akin to how chapter names versus chapter content in books are usually denoted in very different styles - one type of information serves as a summary to the other. Hart should ensure that its "chapter names" are clearly and consistently delineated. Perform the "squint test" - one sign of a usable design is if you can squint at the screen (making everything blurry) and tell which content is more important than others, which content describes other content, and which content can be acted upon. (Personally I find that much Impressionist art looks better this way.)

Ballot (transaction) finality - Evoting systems have the look and feel of online and desktop software, and thus they may be used with a different set of expectations than traditional voting systems. In the online world, as in the process of shopping baskets, financial transactions, etc., users are typically given confirmations and notices that particular actions are unambiguously final. This expectation must translate to this system. To simply say "To complete your voting and cast your ballot..." is not enough, for multiple reasons:

• The user, unfamiliar with evoting, may assume that the electronic process is different from the physical process and thus can be undone. The physical process of dropping paper into a box is unambiguous and final, while all software normally used by people typically has an "undo" or "back" button or feature. Over time this use becomes ingrained into the subconscious, unlike the process of voting, which is only performed once or twice a year. It is reasonable to assume that a voter may unconsciously feel that the action of pressing a software-related button can be undone.
• The system depends on the user's understanding of what "casting a ballot" means in this context - there is no guarantee that translations will be unambiguous. Does it mean that the vote was recorded physically? In the digital world, what does "cast" mean? What does "finality" or the possibility of undoing or erasing records mean, when all records are placed on easily erasable media?
• Users may have a legal recourse and say that "I didn't know (or forgot) the process was final".
• Adding an unambiguous finality notice will help lessen user complaints.

It is strongly recommended that (large, red, centered) text be added above or otherwise near the instructions at the bottom of the summary screen (or closer to one's center of vision if possible), saying to effect, "The ballot casting process is final and cannot be undone."

If nothing, it is at least worth testing, as it is only an additional label within the interface. What is there to lose? As this is a new social process, it behooves designers to ease people into it initially.

• The visual separation of system and help screens (via the blue background) makes the separation between "help/system" and "voting" modes unambiguous.
• Button images are used in some areas alongside instructions.
• When a voter requests help from a poll worker, the screen goes blue (and includes appropriate text) to prevent ballot viewing, and the appropriate LED on the JBC lights up, not unlike the light for signaling airline flight attendants. This solution is elegant, silent, and maintains privacy.

• Use consistent, polished button images next to instructions where there is enough space, and where appropriate, as in the example above. Whether or not these button images should have gray (mirroring the hardware exactly), blue, (denoting system functions and providing color contrast), or no background (leveraging the unique shapes of the buttons) could be examined in usability testing.
• Use the same font size and line height for all instructional text ("reference" information) and ensure it is grouped and spaced adequately so to be visually separate from "working" information.

Although at least two voting system usability standards exists - the IEEE P1582 Voting Equipment Standard and the Federal Elections Commission Voting System Standards - neither address:

• Using relative font styles and sizes to group information, denote hierarchical relationships among information, or mark certain information as important.
• The application of such standards to other parts of the voting system, such as printed matter, ballot design software, system configuration/administration, voting tabulation, and reporting software. The lack of attention to usability in these areas has been the root cause of repeated failures in past elections.

The voting process is only one aspect of voting systems; the author hopes that efforts to improve usability within these other areas will be looked at by standards bodies.

The most important usability recommendations to Hart include:

• Centralize the method of specifying and applying localization and internationalization preferences, and ensure such preferences are propagated appropriately to all parts of the system - BOSS, JBC, eSlate, TALLY, etc. This includes date and time formats, language data and preferences, and legally-driven localizations (such as ballot design).
• Ensure that labels, phrases, fonts, line heights, colors, object sizes, alignment and spacing, and screen layouts (instructions, page titles) are visually and functionally consistent throughout the system.
• Make use of templates, WYSIWYG editing, design constraints, and usability expertise to ensure that ballots are easy to create, consistent, and in line with federal and local usability standards and laws.
• Investigate usability testing methods as outlined in "A Proposed Approach to Testing the IEEE Usability/Accessibility Standards (April 3, 2003)". This and other usability papers on voting systems can be found here.

"A Proposed Approach to Testing the IEEE Usability/Accessibility Standards" (April 3, 2003)
http://www.upassoc.org/upa_projects/voting_and_usability/critical_readings.html

Direct Recording Electronic (DRE) Technical Security Assessment Report
Prepared for the Ohio Secretary of State by Compuware, November 21, 2003
http://vevo.verifiedvoting.org/vendors/studies/20031121.compuware.pdf

"Electronic Voting System Usability Issues"
Bederson, Lee, Sherman, Herrnson, Niemi
http://www.cs.umd.edu/~bederson/voting
http://www.upassoc.org/upa_projects/voting_and_usability/
workshop2004/2003%20-%20chi%20-%20voting.pdf

"Established Vendors of Computerized Vote Tabulation Systems"
http://vevo.verifiedvoting.org/vendors/#infosheets

Federal Election Commission, Voting System Standards (April 30, 2002)
http://www.fec.gov/pages/vssfinal/vss.html

IEEE P1583 (Voting Equipment Standard)
http://grouper.ieee.org/groups/scc38/1583/
http://grouper.ieee.org/groups/scc38/1583/documents_-_p1583/
Sections%205.3%20Usability-Accessibility%20(March%2016,%202003).DOC

Figures 9 and 10 were taken from "Electronic Voting System Usability Issues" (Bederson, Lee, Sherman, Herrnson, Niemi).

All other figures are composed wholly or partially of images found in public Hart Intercivic materials.