![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 3.234 10.567 L 0.598 10.567 L 0.044 0 L 3.788 0 Z M 0 14.267 C 0 13.588 0.185 13.115 0.554 12.849 C 0.923 12.569 1.374 12.428 1.905 12.428 C 2.422 12.428 2.865 12.569 3.234 12.849 C 3.604 13.115 3.788 13.588 3.788 14.267 C 3.788 14.917 3.604 15.39 3.234 15.685 C 2.865 15.966 2.422 16.106 1.905 16.106 C 1.374 16.106 0.923 15.966 0.554 15.685 C 0.185 15.39 0 14.917 0 14.267 Z" fill="rgb(255, 255, 255)" height="16.105846188517717px" id="d8ocSgdvf" transform="translate(20.148 3.872)" width="3.7883077087402377px"/><path d="M 3.146 2.171 L 0 2.171 L 0 0 L 3.146 0 Z M 3.079 14.156 L 0.066 14.156 L 0.066 3.655 L 3.079 3.655 Z" fill="rgb(255, 255, 255)" height="14.156313890536383px" id="Q86BCRZI9" transform="translate(14.648 5.534)" width="3.1458461538461666px"/><path d="M 11.897 13.292 L 8.706 13.292 L 8.706 8.108 L 3.19 8.108 L 3.19 13.292 L 0 13.292 L 0 0 L 3.19 0 L 3.19 5.25 L 8.706 5.25 L 8.706 0 L 11.897 0 Z" fill="rgb(255, 255, 255)" height="13.292307692307693px" id="gBNeo28SG" transform="translate(0.543 6.398)" width="11.896608000000015px"/></svg>)
MY ROLE
Lead Product Designer
DELIVERABLES
Wireframes
High Fidelity Screens
Responsive Design
Design System
Prototype — Interaction Design
Handoff Documentation
TEAM
Accurate Voting Services
Project Manager
Front-end & Back-end Developers
QA
YEAR
2024
What Was the Problem?
Accurate Voting Services (AVS) runs elections for Homeowners and Condominium Owners Associations — votes on board seats, special assessments, and amendments that are legally binding under state law. The entire operation ran on paper, and that created problems on both sides of the election:
It didn't scale. Every election meant printing, mailing, collecting, and hand-counting hundreds of ballots across dozens of associations.
Counting was error-prone. Cumulative voting, weighted by how many units an owner holds, is easy to miscount by hand — and a miscount can invalidate an entire election.
There was no visibility until the end. Administrators only knew whether quorum was reached once the envelopes were opened, too late to send reminders.
Owners had to be reachable by mail. Anyone away from the property effectively lost their vote.
The Challenge
The hard part was never the interface — it was that a ballot is a legal instrument. Its wording, structure, and counting rules are defined by statute and by each association's governing documents, so the platform couldn't simplify any of it. It had to reproduce it exactly, for administrators with no technical background and owners across a wide range of digital comfort.
Two constraints shaped almost every decision: secrecy and accountability had to coexist — the system records that someone voted, never how — and paper doesn't disappear, so mail-in ballots had to enter the same election without breaking the anonymity of the results.
Building a Ballot That Matches the Law
Every association votes differently, so a fixed template was never an option. I designed a ballot builder where administrators compose a ballot measure by measure, choosing the rule each one legally requires: multiple select with a vote cap, select one, text answer, cumulative voting weighted by unit count, and abstention.
The complexity lives in the setup, not in the voting — the system handles the multiplication by units and enforces the limits on the voter's side. Ballots can be saved as drafts, reused as templates, previewed, and exported as PDF for board approval before publishing.
The exported ballot isn't a screenshot of the digital one — print has different constraints, so I built a separate set of text styles sized in points and scaled for the page, alongside the screen styles used across the platform.
A Voting Experience That Reads Like the Legal Document It Is
I deliberately chose not to "app-ify" the ballot. Owners are used to receiving a formal document, and the digital version had to feel equally official to be trusted — so it keeps the structure, hierarchy, and language of the paper original.
Access is minimal: no account, no password. The owner receives a passcode by email, confirms the units they vote on behalf of, and votes. Vote limits are enforced live with a running counter, so a ballot can never be submitted in an invalid state, and a confirmation step summarizes every selection before the vote becomes irrevocable.
Anonymity and Accountability at the Same Time
This was the central design problem. Administrators need to know who has voted — to chase quorum, send reminders, revoke a vote when an ownership record is wrong. They must never know how anyone voted.
I resolved it by separating the two data sets everywhere they appear: one view lists who voted, with date, time, and whether the vote came online or by mail, and nothing about their choices; another shows totals per measure with no identity attached. Both export to PDF. Mail-in entries feed the same structure — flagged as mail-in for reporting, with the choices joining the anonymous pool immediately — and revocation removes a vote without ever revealing it.
Getting Messy Real-World Data Into the System
An election is only as good as its voter roll, and association records arrive as spreadsheets built by dozens of different property managers — duplicated emails, owners with multiple units, missing contacts. Instead of rejecting an imperfect file, the import flow compares the CSV against existing records and shows exactly which ones conflict before anything is written.
The same principle governs destructive actions: deletions that would take an active ballot down require typing a confirmation word, and the message spells out what will be lost.
Creating a System — and Making It Work on Every Screen
The platform had to work on desktop, tablet, and mobile for both administrators and voters, so the component library carried a lot of weight. I built a design system covering colors, text styles, and every recurring element — buttons, text inputs in all six states, toasts, modals, tables, dropdowns, ballot measures, headers and footers — with responsive behavior defined at the component level rather than re-decided screen by screen.
Modals are the clearest example: the same component appears centered on desktop and anchored to the bottom on mobile, with different dismiss gestures on each. Defining that once meant the mobile and tablet versions could be produced consistently and fast.
Developer Handoff Documentation
So much of this product's behavior is invisible in a static screen — vote limits, anonymity rules, dismiss gestures, error states — that the handoff had to carry as much of the design as the screens. I documented the platform feature by feature, plus a general page for everything that repeats.
Each page annotates screens with front-end notes: positioning and timing for toasts, the three ways a mobile modal can be dismissed, which input state applies when, what each error responds to. Every error identified during client interviews is documented at the point where it occurs, so developers never had to guess at intent.
Conclusion
I turned a legally binding paper process into a digital platform without softening any of the rules that make it valid. Administrators do a fraction of the manual work, owners can vote from anywhere, and every ballot stays as secret and as auditable as the law requires — with a design system and documentation that let AVS keep growing the product after launch.
Disclaimer: All data, names, and figures shown in the screenshots and mockups are purely fictional and used only for illustrative purposes. They do not represent real client information.