During the 2012 election cycle, Americans Elect asked if billions of dollars are transacted across the web every day, why can’t we vote on the internet? What was created was a new way to nominate and elect a presidential ticket.
Americans Elect was the first ever nonpartisan, national online presidential primary.
The goal was to nominate a bipartisan ticket entirely on the internet, then place that winning ticket on the 2012 national ballot in all 50 states.
The core idea was that ballot access + technical innovation = direct nominating process.
In essence, AE was the digital transformation of the candidate nomination, voting, and convention process.
The fundamental premise was that the two party system is broken, and we were tasked to figure out how people could vote for a bipartisan “radical center” presidential candidate on the internet.
For voters: AE was designed for the disenfranchised people who were tired of “politics as usual”, and the constant gridlock in congress.
For candidates: a ticket like Mike Bloomberg and Colin Powell, or Chuck Hagel and David Patraeus were envisioned.
Trump even toyed with the idea to run on Americans Elect and was even mocked by The Daily Beast as a charismatic joke candidate.
If AE secured just 5% of the national ballot, then there would be a foundation for a future platform to build on - because that 5% threshold would automatically qualify AE to be on the ballot in 2016.
“If Americans Elect ticket got at least 5% of the vote in most states, that ballot line would exist in 2014 and 2016, creating the framework for a potential third party committed to political reform and combating hyperpartisanship”
- The Daily Beast
I was the User Experience Lead (and the sole User Experience Designer) on a team of 20-30 people in NYC.
My primary responsibility was to architect the overall end-to-end user experience and security for the system.
The goal was to identify all the unmet needs for our delegates and candidates, then design simple and secure solutions.
Americans Elect is a 501(c)(4) non profit organization, which meant the organization didn’t have to disclose who their donors were.
There was a lot of contention around this, especially because the first $20 million raised in donations would go to pay back the donors first.
This was part of the deal to secure a total of $30million in funding (the 2020 election cost $14 billion).
Operationally, AE was broken up into two main teams, a DC and a New York team.
Ballot Access was run from the DC team, who paired up with Ipsos for polling and Doug Shone for the signature drives.
When signatures were being gathered for ballot access, voters were asked “do you think there’s a better way to nominate a president?”
Most said “yes” and gave us their signature.
The New York team was a political tech startup, located and incubated inside an advertising agency LBi.
“(Americans Elect) looks naturally like a tech startup: T-shirted programmers sit in conference rooms with code written on the glass walls and website designs taped on every vertical surface. There are photocopied diagrams of Conway’s Participation Continuum ("Activate. Sustain. Retain.") and plans to use early adopters to propel a multistage website rollout.”
- The Daily Beast
We built and tested 80% of the system, but on May 15, 2012, Americans Elect announced that "no candidate has reached the national support threshold required" to compete in the online convention.
We were a $20MM startup fighting a two front war against a $2B adversary (the establishment parties had $1B dollar war chest each). A 20x difference in scale.
By the close of the process, AE gathered 2.6 million signatures securing ballot access in 29 states representing 275 electoral college votes.
Even though no candidate was produced, several other significant achievements were achieved.
We set up a tech stack that was tested to be robust enough to handle 20 million active users in 2012.
AWS and caching weren’t something you could just spin up at the time. DEVOPS was in its infancy at that point.
The CTO for LBi said that we were handling more infrastructure for that one project, than other agencies handled for all their clients combined.
Even though LBi was an advertising agency, it was groomed as a startup - ultimately succeeding in its goal to later get acquired by Publicis for $540mm.
The scope of this project was so vast, that we needed to start with a large-scale requirements gathering session.
There were requests from the DC team about the vision, and additional ideas that we came up with in New York.
Aside from nominating a candidate on the internet with a virtual convention, we were envisioning how to make party functions delegate functions.
For example, anyone could draft a candidate, propose and define the rules surrounding the party.
In parallel to gathering requirements, we honed in on who our target users were, and what sorts of actions they would take on the website.
The delegate and candidate were the most important personas, however volunteers, journalists, marketers, and donors also had key roles to fulfill in the cause.
The UX effort for Americans Elect was a huge undertaking. It was like taking four startups and rolling them into one.
The first phase was like a political dating site complete with a matching genome.
Second phase was a social network where people could ask questions where they would be voted up or down. The top ten questions would require video and written answers by each of the candidates.
Third phase was like starring in American Idol, where candidates began to get eliminated.
Fourth Phase was like super bowl live streaming debates, potentially around the world.
Fifth phase was secure voting with better than bank level security and counter ID fraud built in.
On top of all this, do this in less than a year, get AE $20 million in donations, and make it easy enough for the majority of the population to use.
Last, you’re designing for scale (millions of people) and security (don’t get hacked).
AWS and caching were prevalent in 2012, so a lot of the infrastructure and UX security patterns we developed ended up predating what are known best practices.
One of the biggest challenges by having such ambitious goals with intense time pressure, was figuring out what specifically to build and when to sequence it in the overall pipeline.
I ended up using the Crossing the Chasm framework as the model used to set up an initial plan.
I had to figure out at each level, what would motivate each group (based on differing values), while working backwards from voting to sequence the proper production efforts.
This helped us visualize the necessary feature set, and understand what to design/build and when.
We tied the Post-Its to Personas, then sprint requirements for development.
Features were broken down into two week or ten business day sprints cycles.
Yellow Post-Its were items to build out in development, green Post-its were items to sketch and design.
Sprint cycles were broken down into two week or ten business day sprints.
Features then got formally logged as tickets and officially planned across our sprint plan.
After a certain point of detail was reached, it became clear that even traditional development methodologies like Agile were reaching their limit.
We were trying to build so much so fast that the environment was too dynamic for everyone to keep up.
Between the DC and NYC teams, we were practically making daily pivots due to the speed, complexity, and political nature of the project.
We were a small and highly skilled team, but we lacked enough bodies to make constant changes in a digital production environment.
There were so many moving parts and random limitations (especially with security, voter registration, and working at scale) that we needed to have a better system to QA everything - all while also keeping up with changes from DC.
There wasn’t an appetite to sit down and make a plan, because there was this pervasive feeling of always working to catch up.
It got to a point where we needed to do something different, otherwise the project was going to totally come off the rails.
We had the initial front end framework set up, so there was no reason we couldn’t sketch, get approval with front and the DC liaisons, then go right to development.
We also needed a way that everyone could see what everyone was doing, without filling the day with unproductive 10+ person meetings.
I knew we needed a war room, but I wasn’t allowed to tape things to the wall because we just moved the agency into “a proper office”, and management didn’t want to mess up the fresh paint.
This wasn’t my first rodeo, and at this point - I had mastered how to use painters tape (non destructive adhesive) to explode projects on a wall.
Luckily, with AE - as the UX Lead, I had access to the CEO and acting CFO of LBi given this was such a high value project.
I met with management, pleaded my case, and followed up with the fact that I was trained by a PhD Art Historian who was the Chair of the Dept at SCAD, and that this would free us of our gridlock.
I also knew the agency was going to get sold even though this was a secret at the time, so I pitched the war room secondarily as a marketing tool.
Having the go ahead from the higher ups, I stayed until 2:30AM the following night not telling anyone what I was about to do, and to everyone’s surprise - the team arrived with a curated and polished war room.
All the sudden, everyone had a birds eye view of how the system looked and operated.
Because the website was carefully exploded on the wall, anyone could add post-its and participate.
I didn’t even have to instruct people with Post-Its, everyone just intuitively knew and went right to work to collectively sculpt a future vision in unison.
The war room added tons of value because someone who wasn’t technical could notice something wrong with the interface, make a Post-It - then our technical project manager could scoop up the bug, make the ticket, then prioritize and traffic the change to the appropriate party.
Last, the tension from working is so intensely under such chaotic conditions immediately released.
Everyone could see what was happening in near real time, so confidence in each other and the total vision began to grow.
After the team’s initial reaction to the war room there was no question now about how to move forward. The new flow worked like this:
All design comp updates would get printed out and organized.
Each printout got torn with a ruler because it was fast and clean enough to cut everything down to it’s necessary part.
All the components would get organized and dry laid out on the table before they got transferred to the wall.
Taping up all corners of each different piece and getting them ready to hang.
Hanging up and organizing the latest revision on the wall.
The process starts over again as we make more progress on the total system.
Voting on the internet had never been done before, so we had to combine a bunch of other off the shelf technologies, and sequence them together in a proprietary way.
We had to account for secure log-ins, identity verification, voter registration, account lockups and lockout, and balance all those constraints with the cost to manage the infrastructure.
We had the initial front end framework set up, so there was no reason we couldn’t sketch, get approval with front and the DC liaisons, then go right to development.
By the time everything was set up, one of our key vendors RSA said that our system was more secure than most of their ban customers
There is a delicate balance you need to achieve between making something secure enough, but also usable at the same time.
The more secure something is, the harder it is to use.
The main challenge was deciding how much information we asked users for in order to validate that they were who they said they were, and what safeguards we put in place to make sure their account log-ins and unlocks were secure.
This case covers the details of each step below.
The LogIn and Sign Up flows were a little unconventional relative to how people were used to logging into other websites.
We started by asking users for their email addresses.
On Log In, if an incorrect email was entered, we had to write the error messages in such a way not to identify a positive email address.
If a hacker could locate a user’s email that was used, they could begin trying to hack a user’s password or send phishing emails.
We asked users to click and enter an eight digit PIN, to counter keyloggers (malicious code that records keystrokes).
Each time a user saw the LogIn page, the order of the keys would change.
Once a PIN was created, we leveraged Green Armor which created a recognizable color block and word that would be automatically generated based on the email address and PIN.
This provided one extra recognizable cue that reassured users that they were actually logging into the proper website.
We asked users to click and enter an eight digit PIN, to counter keyloggers (malicious code that records keystrokes).
AA was a sort of black box that measured things like IP address, time of log in, browser, etc in order to build a risk profile of a given user.
If someone was deemed high risk, that person would have to answer two security questions (with three attempts) otherwise they would get locked out of their account.
Before AA could be properly set up, users had to select and answer security questions.
Questions were things like what was your first pet, or what is your mother’s maiden name.
Users had to create answers for four different questions.
When a high-risk flow was triggered, two out of four questions would get asked.
Verifying your identity can be a complicated process, therefore we opted to have user’s walk through the process in steps.
Step 1: Verifying their email address, or resend a new verification email.
Step 2: Update their PIN if they were early adopters (only four digit PINs were required at the time).
Step 3: Create four security questions so Adaptive Auth could activate.
Step 4: Verify your identity and either register to vote or confirm your voter registration (via Aristotle API).
Identity was verified using RSA’s KBA (Knowledge Based Authentication) API.
Users were asked for full name, address, date of birth, and last four digits of their social security number.
A series of questions were then posed to each user based on the information they provided.
Questions were aggregated from private data sources like leases signed, banks account registrations, and addresses where people lived.
We configured the flow at 2x successful answers to pass, three fails to quit - whichever happened first.
All of this information was securely handled by RSA - AE never saw or touched any of this information.
Each time the KBA flow was initiated, it cost AE $1.50.
At 20 million users, the projected identity verification bill alone would cost $30 million dollars.
When all four steps were completed, a visual lock went from “locked” to “unlocked” and enabled users to draft candidates, vote, and create or vote on debate questions.
Aside from the About Us and Who We Are Section, the most important interaction in the Learn Section is the Board Decisions Page.
After delegates became fully verified, they had the power to recommend and vote on party guidelines.
This was a novel political innovation at the time, as the two major parties don’t all for this kind of direct feedback.
As delegates started their Americans Elect journey, the first thing they did was to “pick their colors” by ranking the priorities of their value system.
The Colors step was essentially a political dating site complete with a matching genome that fed into the rest of the site.
Delegates would drag sliders left and right to define the priorities that matter to them most.
Once their Colors were defined, delegates would be asked to answer polling questions to help rank the priorities of the Platform of Questions (Debates).
Colors fed into all parts of the site including matching with others users and candidates.
The goal was to help people find others with similar value systems, so they could build a platform of questions to ask a candidate that reflected the same values as they did.
The purpose of Debates was to shape the debate that delegates wanted to see from candidates.
Each verified candidate would then be required to provide a pre-recorded one minute video answer which anyone could see on the candidate’s profile.
The idea was that anyone could pose a question to future candidates.
There were mechanisms in place to prevent the same question from being asked multiple times.
Questions would get voted up or down based on delegate participation, and the top ten questions would create a Platform of Questions.
If a question was deemed bad, we collected secondary data to ascertain if the question was genuinely not quality, or if it was spam or inappropriate.
Each question had its own question detail page where users could see how important this question was to the wider AE community, and compare their own profile Colors ranking to the question.
A vote up or down was required however in order to post a comment.
Drafting a candidate is a complicated process because that person has to pass all the constitutional and FEC (Federal Election Commission) requirements.
This is in addition to all the baseline identity and security requirements required by the platform.
Candidates could be drafted and declared (ie you declare yourself).
Each has specific steps and requirements that will be outlined below.
Before a delegate can draft a candidate, they have to go through all the identity verification requirements listed in the previous section.
When drafting a candidate, you are starting a draft committee.
Essentially you are electing yourself to manage a group that will campaign on behalf of your prospective candidate.
Aside from the name of the candidate, a “presidential” occupation is requested to help vet if the candidate will be qualified ot not.
Example occupations could include previous political or military management positions such as a general or governor would suffice.
Before a draft committee can be submitted, a modal pops up to reinforce the seriousness and responsibility in forming a committee.
Given that this is a nation wide electoral process, multiple draft committees can be formed to help the candidate extend their reach.
Drafted candidates need to meet all constitutional requirements, as well as a brief statement on why that person would make an excellent candidate.
At the end of the draft process, the person drafting the candidate must agree to the draft committee pledge reiterating the seriousness of the commitment.
If a candidate is declaring themselves, they must first complete all the security and platform requirements.
Progressive registration and feedback with green check marks follow the same mental model as the account creation flow.
A candidate who declares themself will likely be serious about the process and likely want to speak directly with the people running the platform.
This provides a personal human feedback loop to the predominantly digital process.
Candidate profiles had to account for multiple states identifying whether or not a candidate was drafted, declared, or disqualified (ie for joke candidates or for lack of supporting delegates).
If a candidate was not drafted, you could start a draft committee off their profile page.
If a candidate was drafted, you could add or remove support.
The profile header also displayed pertinent information such as how much of a particular candidate matched with your own value system (Colors), how much support they received (delegates who clicked support), and what their top priority was.
Under the profile header the first tab in the candidate Profile page was the Supporters Tab.
Candidates were required to amass 10,000 delegates from ten states.
Multiple draft committees could also be formed to help the candidate get the proper support and help build their own grassroots campaign.
Under the Colors Tab, each of the candidates specific answers to their Color questions as well as their Color Priority ratio can be viewed.
The candidate Bio Tab had a section for a longer more formally written biography.
The Platform of Questions Tab was one of the more important section in the Candidate Profile.
Each candidate was required to produce a one minute response to each questions voted up by the delegates.
There were multiple questions allowed for each Color Category, and each questions was required to have a one minute video.
The Candidate Eligibility Tab acted as a public facing accountability measure to ensure that each candidate met all the proper qualifications.
When sketching out the The Convention Landing Page, we came up with a concept of a bracket / leaderboard page that would display candidate progress as the platform moved towards the convention.
The convention Landing Page had to account for multiple rounds and states, while also clearly demonstrating where the platform was in the nomination process.
While a round of voting was in progress, delegates could come directly to the bracket page, and begin voting for their candidate of choice.
After a round of voting was completed, the delegates could click to see the current results.
For every round of voting, there were three states that had to be accounted for: voting in progress, voting closed with unofficial results, then final official results that had been audited.
Because we did not know how many candidates would be drafted / declared, we needed to plan for multiple permutations of Caucuses in case we had many or few candidates.
Each candidate was required to produce a one minute response to each questions voted up by the delegates.
All the different states of voting rounds combined with multiple Caucus and Convention states added to the complexity of the design system.
Before voting could begin, we had to make sure every delegate was registered to vote - and if the delegate wasn’t registered, we needed to have a path for them to do so.
Voter registration and records are different for each state, so we used Aristotle Political Data services to digitally register anyone who wanted to vote.
Before delegates could register to vote, they had to pass all the identity and security requirements of the platform.
Once those requirements were fulfilled, there was a secure manual process that a delegate could go through in order to register to vote.
This was necessary in order to register special edge cases such as first responders, federal agents, and young adults who were under 18 and could not pass the identity requirement.
When a voting round finally kicked off, we designed the process to be as secure as possible, while also balancing a seamless flow from end to end.
The first step was to prompt delegates with an interstitial page that asked them if they wanted to vote first, then see results - as not to bias their own vote.
After the bias prevention interstitial page, a general landing provided instructions on how the process worked.
We used Animal CAPTCHA as the time to get around bot networks.
Delegates had to choose a specific animal that the system asked for.
After clearing Animal CAPTCHA, delegates could select the candidate of their choice, then click choose to go to the next step.
Variations for each bracket level had to be designed, built, and tested.
After selecting a specific candidate or ticket depending on the bracket level, delegates had to physically check and confirm that this was their candidate / ticket of choice.
After a candidate / ticket was chosen, delegates could click to see the current tally or print out a receipt of their vote as a certificate.
Each vote certificate had a unique confirmation number that was auditable after voting closed.
The voting process would repeat, until a final ticket was officially nominated.
At which point, the ticket would appear on all 50 ballots in the national presidential election in 2012.