Design
Our final design for our interface had several key changes (the first column are screenshots from GR4, the second column are screenshots from GR5):
|
|
|
|
|
|
|
|
On the welcome page, we removed the busy background and restyled the page to make the information more salient and readable for our elderly user population. We modified the login page similarly (not shown).
On the main audit page, we kept the right side of the interface since that seemed to work well and changed the left sidebar. We made only the previous 3 selections visible, the user can scroll up to see the other selections for this ballot. Having only three selections allowed us to increase the size of the text, which should be easier for our user population to view.
On the fix mistake menu, we threw out nearly all parts of our GR4 design. The right panel was being used inefficiently in a distracting help menu and the button selections were too small on the left sidebar. Instead, we moved the ballot selections to the right, making them tabs, so the entire ballot can be viewed at once. The left panel only has a small amount of help text and a few essential buttons.
On the results menu, we added the overall results for the election and restyled the page to make it more clear.
In addition, we added a tutorial for the user when they enter the website. There is also a help link on all the pages, so the user can go back and view the tutorial.
User Testing
- User 1 (Election employee): Please note this test had to be done on Internet Explorer, which did not support all functionality. This is because the office had no access to wi-fi and we had to use her machine.** She was surprised that our program had glitches on Internet Explorer, since she mentioned all offices are set up with Internet Explorer.** Wanted to have the layout from the fix mistake menu to be the primary layout, she found the pie-chart confusing*** She said it would be faster to see things laid out in the same order as the ballot.
- Most other comments were specific to IE glitches and are hence not mentioned here because they are concerns we addressed in our actual project.
- User 2 (Town Clerk in Concord, MA): ** Didn’t seem to understand that the main screen tutorial followed into a “fix mistake menu” – she was going through the tutorials but didn’t enter the fix mistake menu. It might be helpful if we made it clearer that the tutorial continues on that page.** Despite going through the tutorial which states that Democratic Candidates are on the top, Republican on the bottom and others on the left, she was confused why some candidates ended up on the left.
- “Write-In, where do I do that?” She wanted a space to enter who the write-in candidate was.
- User 3 (Worker at the office of the Town Clerk in Concord, MA):** Accidentally skipped tutorial when she wanted to go through it
- Wasn’t quite sure how to fix a mistake – originally was going for “reset ballot” but figured out to click on a candidate name before actually selecting anything. So she figured it out, it just took a moment.
- Correctly walked through fix mistake menu without a tutorial** Though didn’t realize you press “ok” to reset.** Didn’t see the “cancel” button to go back
- To fix two ballots ago, didn’t think of restart audit. Didn’t see restart audit.** Would prefer just changing one, thought that was more likely than the off-by-one errors we were concerned about.** Restarting from somewhere on this ballot on the previous one is fine, not too much
- Actually very helpful for the elderly users.
- Button placement seemed random other than blank and write-in
- “If the system ever went down, this would be much nicer than doing the hand counts”
Reflection
We originally had considered two user classes: the auditor and the warden. In our subsequent GRs, we focused on the auditor's needs, but we haven't addressed the warden. The warden acts as an administrator and would have the ability to create/assign/view results. Without the warden account, our website just focuses on the input side of the election, not really the output, and isn't really meaningful in the context of an election. We've discussed the possibility of maybe just showing the results after the audit, but then our website is only relevant for the 2012 presidential election (the warden would have the ability to create new elections). In our work before GR4, we created a nearly complete computer prototype of the warden and then decided to focus on the auditor and throw that out. In re-doing this process, we should have identified the need to narrow our project down to just the auditor earlier and stuck to that.
In addition, in our first paper prototype, we focused a lot on the main audit page and added the fix mistake page as an afterthought. We should have spent more time refining that design before, so we could have arrived at our current GR5 implementation earlier.
In evaluating our results, it was difficult to anticipate the feedback that we got. Each auditor has their own personal process and it seemed like they were reluctant to switch from hand counting. This might be an aspect of our elderly user population, but if they were given time to learn the system, it seems much more efficient to use a website over tally sheets.