Case Study · Government · Enterprise Desktop
Election Management
System (EMS)
Zero tolerance for data errors in a zero-margin environment. Replacing error-prone spreadsheet workflows with a real-time election command centre — and doing it in a way that an election official under 12 hours of sustained pressure can actually use.
01 — Overview
The context and the stakes.
Government election officials managed election-night data using spreadsheets and disconnected legacy tools — a high-pressure, error-prone process with no real-time result aggregation. There was no audit trail for data changes, inadequate reporting dashboards, and no mechanism for detecting anomalies in vote counts as they arrived from polling stations.
This was not a routine enterprise software project. An error in an election management system is a public trust issue. Every design decision needed to be defensible, documented, and auditable.
↓89%
Data entry error reduction
24
Heuristic violations fixed
100%
Audit trail coverage
AA
Gov WCAG 2.1 compliance
02 — My Role
What I was responsible for.
Lead UX Designer
End-to-end ownership from research to handoff.
Led all UX activities: on-site contextual research, heuristic evaluation of the legacy system, service blueprinting, persona development, IA design, wireframing, high-fidelity prototyping, usability testing under simulated election conditions, and developer handoff with full WCAG annotations.
- On-site election night observation
- Heuristic evaluation (24 violations)
- Service blueprint
- Persona development
- IA and wireframing
- Hi-fi design (Figma)
- Simulated usability testing
- Gov WCAG 2.1 AA compliance
03 — Problem Statement
The specific failure of the legacy system.
Election officials managed election-night data using 12 separate spreadsheet files for a single election night. Results were updated by manually re-entering vote counts from regional fax reports — under time pressure, late at night, with journalists and party observers watching every number change on a public results board.
A full heuristic evaluation of the existing system found 24 violations using Nielsen's 10 heuristics. The worst: no system status visibility during data upload (officials had no feedback on whether their entry was saving), no undo capability (a mistyped vote count required a support call), and error states communicated through colour only.
04 — Objective
What success looked like.
05 — Design Process
Six phases. Each one earning the next.
On-site Contextual Observation
Attended a real municipal by-election to observe officials working in genuine election-night conditions — time pressure, multiple simultaneous data streams, the moment a count seemed unusual and no tool existed to flag it. The gap between what the system was supposed to do and what officials actually did to cope became immediately visible.
Senior Official Interviews
In-depth contextual interviews with 6 senior election officials across 3 regional offices — exploring decision-making processes, highest-stress moments in the count process, and the trust requirements for electoral data. Officials needed to be able to explain every data change to a returning officer. The existing system made that impossible.
Heuristic Evaluation (24 violations)
Full Nielsen 10-heuristic evaluation of the existing system. 24 violations identified, each mapped to a specific operational risk. The worst: no system status during upload, no undo capability, error states communicated through colour only, and no contextual help requiring officials to leave the system mid-count to consult a PDF manual.
Service Blueprint
Full service blueprint of the election-night data collection process — from polling station closure through to final declaration. Every system touchpoint and human decision mapped, exposing the 4 moments where errors were most likely and the 2 points where the existing system offered no recovery path.
IA Design + Wireframing
Command-centre IA model built around a progressive drill-down: National Overview → Regional Breakdown → Polling Station Detail → Audit Log. Consistent layout and navigation patterns at every tier so officials can move between zoom levels without reorienting. Wireframes tested with officials before any visual design.
Simulated Election-night Testing
High-fidelity prototype tested with officials in simulated election-night conditions — time pressure, multiple simultaneous data streams, and anomaly scenario testing. The simulation exposed 3 interaction patterns that looked fine in calm testing but broke under pressure. All three were redesigned before final delivery.
06 — User Interviews
What officials told us.
Six senior election officials across three regional offices. In-depth interviews focused on the count process, system failures they'd experienced, and what "trustworthy electoral data" means in practice.
07 — Personas
Three roles. Three very different stress profiles.
Election Director
David Chen
Age 52 · Senior Electoral Services Manager
David needs to see the national picture in real time — total votes, turnout, party standings. He's accountable to the returning officer and needs to be able to answer questions about any data change instantly. He doesn't enter data himself but needs to trust every number on screen.
"If I can't explain a number to a journalist at midnight, the system has failed me."
Data Entry Operator
Priya Sharma
Age 29 · Electoral Services Officer (Temporary)
Priya is responsible for entering results from individual polling stations as they are reported. She's under constant time pressure and is often working with unfamiliar software for the first time. She needs to be protected from errors by the system — not just warned after the fact.
"The worst part is not knowing if what I typed actually saved. I just keep entering it and hoping."
08 — Empathy Map
What Priya thinks, feels, says, and does.
👁 Sees
- 12 spreadsheet tabs open simultaneously — one per region
- Journalists and party observers watching the results board live
- Colleagues making visible data entry errors under pressure
- A legacy system that looks like it was designed in 2003
👂 Hears
- "Can you re-enter that? I don't think it saved."
- "Just double-check the region 4 numbers — something looks off."
- "Don't worry, we've done this 12 times before. You'll get used to it."
- Notification sounds from multiple devices without context
💭 Thinks
- "I'm not sure if this saved. Do I enter it again?"
- "What if I made an error? I can't tell from looking at it."
- "I don't know which region this polling station belongs to."
- "This is so stressful. There has to be a better way."
😰 Feels
- Anxious about making an error that affects the official count
- Frustrated by the lack of feedback from the system
- Overwhelmed by the volume and pace of incoming results
- Isolated — no easy way to escalate concerns in real time
09 — Pain Points
Six pains from the legacy system.
No Undo
A mistyped vote count required an IT support call. No recovery path for simple human error in a high-pressure environment.
No System Status
No feedback on whether data entry was saving. Officials entered the same data multiple times as insurance.
12 Spreadsheets
12 separate files for one election night. Cross-file errors — entering data in the wrong constituency — were common and silent.
No Anomaly Detection
Unusual vote patterns went unnoticed. Officials had to manually compare numbers to identify suspicious counts.
Colour-only Errors
Error states communicated through colour only. Users with colour vision deficiency could miss critical validation failures.
No Role-based Access
All officials could edit all data. No separation between data entry operators, supervisors, and read-only auditors.
10 — Assumption Mapping
What we assumed. What we validated.
Assumed: Errors happen at data entry
We assumed most errors were made during initial vote count entry. Research revealed that many errors were actually made when copying data between spreadsheet tabs — a structural problem, not a user skill problem.
Assumed: Officials want more features
We assumed officials wanted more functionality. Research revealed they wanted fewer features that worked more reliably under pressure. Simplicity and error prevention, not feature richness.
Assumed: Keyboard shortcuts would be used
Validated — experienced operators needed power-user keyboard shortcuts. But for first-time operators (many are temp workers), the click-through flow needed to be self-explanatory without any training.
Assumed: Dashboard would be the most-used screen
Validated — but the Audit Log was the second most critical screen. Returning officers needed to be able to reconstruct every data change to answer challenges from party observers. This elevated the audit log to a primary design priority.
11 — Information Structure
Command-centre model. Four tiers.
12 — Integrating Design with Agile
How UX worked alongside sprint delivery.
Design ran one sprint ahead of development — validating concepts at lo-fi before engineers started building, and providing detailed annotated handoffs as each sprint closed.
Discovery Sprint
Research, heuristic evaluation, service blueprint, and problem definition. Output: validated problem statement and prioritised design backlog.
Architecture Sprint
IA design, wireframes, and lo-fi usability testing. Output: validated IA model and annotated wireframes for development Sprint 1.
Feature Sprints
One sprint ahead: hi-fi designs delivered the sprint before development. Accessibility annotations included in every handoff spec. Mid-sprint design reviews.
Validation Sprint
Simulated election-night testing. Three critical issues found and resolved. WCAG audit completed. Final handoff with Gov WCAG 2.1 AA certification checklist.
13 — Wireframing
Lo-fi validation before any visual design.
All four IA tiers were wireframed and tested with officials before any visual direction was committed. Wireframes focused on information density, navigation patterns, and error state clarity.
National Dashboard · Wireframe
National overview wireframe — four key metrics above the fold, live trend chart below. Labels and values positioned before any visual design decision.
Data Entry Form · Wireframe
Data entry wizard wireframe — step progress at top, form fields, and prev/continue navigation. All error states shown at wireframe stage.
Audit Log · Wireframe
Audit log wireframe — timestamp, user, change type, and values in a consistent table pattern. Keyboard navigable with sort and filter.
14 — Design Decisions by Screen
Key design choices for each module.
Login Screens
Role-based login with official ID authentication. Clear session timeout warnings. Two-factor authentication flow. Error messages describe the problem, not just the failure.
Dashboard Module
Dark command-centre theme for sustained night-time use. Colour-blind safe charts — party results communicated through colour AND label AND bar width. ARIA live regions for real-time updates.
Processing Screen
Stepped wizard with clear progress. Mandatory validation at each step — impossible values rejected with specific error messages. 60-second undo window after each submission.
Form Validation
Real-time validation against registered electorate. Error message explains the constraint and the correct action — not just that an error occurred. Error communicated through border, icon, AND text.
Results Table
WCAG-compliant results table — sortable, keyboard navigable, status communicated through colour AND icon AND text. Anomaly flag visible at a glance without relying on colour alone.
Event Scheduler
Election-night event timeline showing completed, active, and upcoming milestones. Status communicated through colour, icon, AND text. Critical path always visible to all roles.
15 — Final Design
The delivered system.
↓89%
Data entry errors
Live
Real-time aggregation
100%
Audit trail coverage
AA
Gov WCAG 2.1
16 — Figma Prototype
Interactive prototype.
EMS Full Prototype
Add your Figma prototype share link to embed the complete interactive EMS prototype here — covering all four IA tiers, data entry flows, audit log, and simulated election-night scenarios.
Open Figma Prototype →17 — Design Handoff
What was delivered to the development team.
Handoff Package
Annotated specs with WCAG criterion references on every component.
Every component in the Figma handoff included: sizing and spacing, interaction states (default, hover, focus, active, disabled, error), ARIA role and label requirements, keyboard navigation notes, and the specific WCAG criterion that governs that component's accessibility requirement.
What Made This Handoff Different
Accessibility as implementation instructions — not compliance notes.
WCAG annotations were written as implementation instructions: "When the vote count exceeds the registered electorate, show: (1) red border on the input, (2) ⚠ icon prefix, AND (3) the specific constraint in plain text below the field. Never only the red border." Developers could implement correct accessibility behaviour without interpretation.
18 — Takeaways
What this project taught me.
You cannot design for high-stakes environments without being in them.
No amount of stakeholder interviews replaces observing the actual event. The on-site election observation surfaced failure modes that were invisible in interview — the normalised workarounds, the midnight phone calls, the moment an anomaly surfaced and nobody had a tool to act on it.
Error prevention always outranks speed of entry in zero-tolerance environments.
Every election official I interviewed had been asked to prioritise speed at the expense of accuracy. The design deliberately slowed down the confirmation step. A 3-second confirmation dialog that prevents one wrong vote count is worth more than eliminating that 3 seconds from every correct entry.
Accessibility decisions in government products are public trust decisions.
Every WCAG criterion in this project was framed as a democratic requirement, not a compliance checkbox. An election system that an official with colour vision deficiency can't use accurately is a system that introduces error into the electoral count. Accessibility and data integrity are the same problem.
Pressure testing reveals what calm testing cannot.
The simulated election-night testing found 3 critical issues that had passed every calm testing session without triggering. Under time pressure, interaction patterns change. Users skip confirmation dialogs they read carefully in calm conditions. Designing for pressure requires testing under pressure.