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.


What’s It For?

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.

Image of sketchbook and patches.

Who’s it For?

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

My Role

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.

Keith provides a high level overview of the Americans Elect user experience and subsequent challenges to designing such a complex system at scale. (Youtube).

Organizational Breakdown

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.

3rd floor map of the LBi office in New York City. Americans Elect was located on-site at LBi HQ in NYC.
  • “(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

Image of three resonant waves.
Conway’s Participation Continuum: Keith’s graduate thesis model on how to grow sustainable online communities.


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.


Initial Requirements Gathering

Image of sketchbook and patches.
Initial brainstorm and requirements gathering session. This was the high level wishlist / raw materials list that would become the building blocks for the future phases.

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.

Image of sketchbook and patches.
Mapping out all the personas (key user groups) as well as their primary actions.

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.

Five Phase Journey

Image of three resonant waves.
User journey for a new delegate from joining the movement all the way through voting.

The UX effort for Americans Elect was a huge undertaking. It was like taking four startups and rolling them into one.

3rd floor map of the LBi office in New York City. Americans Elect was located on-site at LBi HQ in NYC.
  • 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.

Crossing the Chasm

Keith giving a high level walkthrough of the different phases of the adoption lifecycle and what it was for. (Youtube).

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.

Image of three resonant waves.
The technology adoption lifecycle curve demonstrates where different groups adopt new technology at different rates.
  • 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.

Image of sketchbook and patches.
Discussing the adoption rollout with Peter Ackerman, Founder and Chairman of Americans Elect.
  • 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.

Image of sketchbook and patches.
Close-up of the adoption lifecycle mapping design and development work to sprint cycles.

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.

Image of three resonant waves.
Close up of a sprint planning session with the technical project manager.

Sprint cycles were broken down into two week or ten business day sprints.

Image of three resonant waves.
Sprint cycles exploded with QA tickets and impromptu sketches to make decisions on the fly.

Features then got formally logged as tickets and officially planned across our sprint plan.


Production Pipeline Problems

Image of sketchbook and patches.
Sketch figuring out all the different interaction states to draft a candidate.

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.

Image of three resonant waves.
Exploded user profile map illustrating how your Colors feed into the rest of the site.
  • 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.

Communication Breakdown

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.

Magic Happens During Witching Hour

Image of sketchbook and patches.
2:30AM at LBi, finally finished installing the war room.

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.

Better Than Expected (Everyone Wins)

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.

Image of sketchbook and patches.
Big decisions being made after a moment of clarity, with concrete next steps being figured out.
  • 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.

Image of three resonant waves.
Lots of little Post-Its waiting to get scooped up for QA.
  • 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.

New & Improved Pipeline

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:

Image of three resonant waves.
Latest batch of design comps waiting to update all the corrections on the wall.
  • All design comp updates would get printed out and organized.

Image of three resonant waves.
Tearing up the comps and getting them ready to dry hang.
  • Each printout got torn with a ruler because it was fast and clean enough to cut everything down to it’s necessary part.

Image of three resonant waves.
Dry arranging all the components on the table in preparation for taping.
  • All the components would get organized and dry laid out on the table before they got transferred to the wall.

Image of three resonant waves.
Taping all the components from the latest batch of comps.
  • Taping up all corners of each different piece and getting them ready to hang.

Image of three resonant waves.
Hanging up the latest batch of comps.
  • Hanging up and organizing the latest revision on the wall.

Image of three resonant waves.
Rinse and repeat. More corrections waiting for a fresh batch of comps to be made.
  • The process starts over again as we make more progress on the total system.


Better than Bank Level Security

Image of sketchbook and patches.
Whiteboarding the broad security flow with the CTO and tech leads. Everything from secure login, to identity verification, voter registration, and delegate lockouts had to be accounted for.

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.

Keith giving a high level walkthrough of the different phases of the adoption lifecycle and what it was for. (Youtube).
  • 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

Complex Requirements

Image of sketchbook and patches.
The main security flow was printed out on a 48” wide plotter. This tablecloth size map outlined how users got registered, verified, voted, and reopened their accounts if they got locked out.

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.

Image of three resonant waves.
Updates were marked directly on the security flow map, and checked off in real time as corrections were made.

Log In and Sign Up

The LogIn and Sign Up flows were a little unconventional relative to how people were used to logging into other websites.

Image of three resonant waves.
The Log In & Sign Up page starts asking our delegates for their email addresses.

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.

Image of three resonant waves.
Create / Enter Your PIN Page.

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.

Image of three resonant waves.
Adaptive Auth High Risk Log In / Lock Out to One Time Password Reset Flow.

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.

Image of three resonant waves.
Enter your security question page.

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.

Account Overview

Image of sketchbook and patches.
Sketching out all the different states for identity verification.

Verifying your identity can be a complicated process, therefore we opted to have user’s walk through the process in steps.

Image of three resonant waves.
My Account Page: Verify Email Address.
  • Step 1: Verifying their email address, or resend a new verification email.

Image of three resonant waves.
My Account Page: Enter Security Questions.
  • 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.

Identity Verification

Image of three resonant waves.
RSA KBA Identity Verification Flow: Users were asked for a lot of information in order to verify their identity.
  • 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.

Image of three resonant waves.
RSA KBA Identity Verification Flow: Users were asked a series of questions to prove their identity.
  • 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.

Image of three resonant waves.
My Account Page: Identity Verification Complete.

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.

Image of sketchbook and patches.
Security flow exploded on the wall across from the voting flow wall (pictured above).
Image of sketchbook and patches.
Draft a candidate flow: whiteboard sketch working out all the possible permutations of how a drafted candidate eventually declares their intention to run.

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.

Image of three resonant waves.
Sketching out all the requirements to draft and declare a candidate.
  • Candidates could be drafted and declared (ie you declare yourself).

  • Each has specific steps and requirements that will be outlined below.

Image of three resonant waves.
Verify your identity before you draft a candidate page.
  • Before a delegate can draft a candidate, they have to go through all the identity verification requirements listed in the previous section.

Image of three resonant waves.
Draft a candidate page name and occupation page.

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 You Continue modal.

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.

Image of three resonant waves.
Draft a Candidate page.

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.

Declare A Candidate

Image of three resonant waves.
Declare Yourself A Candidate Page.

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.

Declare Yourself A Candidate Confirmation Modal.

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

Image of three resonant waves.
Candidate Profile Header.

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.

Image of three resonant waves.
Candidate Supporters Tab.

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.

Image of three resonant waves.
Candidate Colors Tab.

Under the Colors Tab, each of the candidates specific answers to their Color questions as well as their Color Priority ratio can be viewed.

Image of three resonant waves.
Candidate Bio Tab.

The candidate Bio Tab had a section for a longer more formally written biography.

Image of three resonant waves.
Candidate Platform Of Questions Tab.

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.

Image of three resonant waves.
Candidate Eligibility Tab.

The Candidate Eligibility Tab acted as a public facing accountability measure to ensure that each candidate met all the proper qualifications.

Caucus & Convention

Sketching out the Convention Landing Page.

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.

Convention Landing Page at time zero, before any voting has begun.
  • The convention Landing Page had to account for multiple rounds and states, while also clearly demonstrating where the platform was in the nomination process.

Image of three resonant waves.
Voting bracket while voting takes place.
  • While a round of voting was in progress, delegates could come directly to the bracket page, and begin voting for their candidate of choice.

Image of three resonant waves.
Voting bracket after voting has finished.
  • After a round of voting was completed, the delegates could click to see the current results.

Image of three resonant waves.
Three different voting header states.
  • 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.

Image of sketchbook and patches.
Voting flow accounting for all the possible permutations (numbers of candidates).

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.

Image of three resonant waves.
Different headers for multiple Caucuses.
  • 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.

Image of sketchbook and patches.
Image of sketchbook and patches.
Image of sketchbook and patches.
Voting bracket page illustrating how voting flow looked like as platform moved to the convention.


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.

Image of sketchbook and patches.
Aristotle voter registration flow.

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.

Image of three resonant waves.
Edge cases that we needed to account for to get into the Aristotle flow. In the end we built an instructions page with secure FTP to Aristotle.
  • 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.

Image of sketchbook and patches.
Voter flow during Caucus or Convention day.

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.

Image of three resonant waves.
Don’t bias your vote interstitial.
  • 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.

Image of three resonant waves.
Voting day how it works landing page.
  • After the bias prevention interstitial page, a general landing provided instructions on how the process worked.

Image of three resonant waves.
Animal CAPTCHA bot prevention page.
  • We used Animal CAPTCHA as the time to get around bot networks.

  • Delegates had to choose a specific animal that the system asked for.

Image of three resonant waves.
Choose Your Candidate Page.
  • After clearing Animal CAPTCHA, delegates could select the candidate of their choice, then click choose to go to the next step.

Image of three resonant waves.
Choose Your Ticket Page.
  • Variations for each bracket level had to be designed, built, and tested.

Image of three resonant waves.
Confirm Your Choice Page.
  • 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.

Image of three resonant waves.
Vote Confirmation Page.
  • 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.

Image of three resonant waves.
Downloadable Printable Voter Certificate.
  • Each vote certificate had a unique confirmation number that was auditable after voting closed.

Image of sketchbook and patches.
Image of sketchbook and patches.
Image of sketchbook and patches.
Convention Bracket Pages.
  • The voting process would repeat, until a final ticket was officially nominated.

Image of three resonant waves.
Winning Ticket Page.
  • At which point, the ticket would appear on all 50 ballots in the national presidential election in 2012.