The EveryElection app was born out of realization that American elections--the bedrock of our republic-- are being hindered by misinformation, disinformation, and general ignorance. It's common knowledge that a voter cannot wisely select a representative without being well informed, but the information needed by the voter is simply too difficult to find. When voters cannot find clearly reliable sources of information, they turn to what they have around them. This opens the door to nefarious sources who seek to manipulate the ballot in favor of self-serving interests.
EveryElection seeks to change all of this by doing the hard work for the voter. By partnering with various data suppliers (with our primary partner being BallotReady), we were able to compile a database of information on 300,000 of the 519,000 rolling elections in the United States). That equates approximately 60% of all elections. While that number may sound small, it's important to remember that U.S. elections are managed locally. This means that, there is no central source of election information. To collect information on each local election, our suppliers need to manually call the city that manages the election. If the city doesn't have the information (this happens more often than it should), we can (in some circumstances) call the county and get the data from them. And if the county doesn't have it, we may be able to call the state. For particularly small or poorly managed cities, however, the data simply isn't available. Either nobody answers the phone, responds to emails, or simply knows where to find the information. To say the least, it's pretty clear why voters often don't even know when a local election is upcoming.
My role in this process was threefold: (1) to design mobile and web applications that would be appealing to voters; (2) product and project manage the implementation of my designs; and (3) to build the front-end frameworks for the web applcation.
My process is a little less traditional than other designers. I think best when I work at my computer, so my first step is always to roughly sketch out a user flow in Balsamiq, Illustrator, or Sketch (depending on my mood).
Througout the ideation / design phase, this user flow is simplified and streamlilned until it is as intuitive as possible without sacrificing necessary functionality.
After finalizing the user flow, I move on to the user interface. I begin roughly wireframing the the layout of each element, paying minimal attention to aesthetic.
In the user flow above, you can see that I mapped out various paths (including basic error handling) that asked each user to register through Facebook, Gmail, or email, import their contacts from various sources, and provide their personal address before gaining access to the app's services. We wanted access to each user's contacts so that we could map elections around their contacts, allowing the tool to be used for GOTV (get out the vote) efforts. We wanted access to each user's residential addresss so that we could map elections that they were personally eligible to vote in (which was the core functionality of the app).
Although not yet featured in the above user flow, and although critical to the app's core features, every step after registration was optional. This approach was taken to increase early user trial and conversion rates. After conducting basic user research, I began to fear that, for every required step, there would be a large dropoff in the conversion funnel. For example, users may not want to create an account or share Facebook access without knowing if they'll even enjoy the app. Or maybe they don't want to share their personal, sensitive information (i.e., contacts and address) with a third party until they are sure that the services are worth the privacy encroachment.
While we didn't have the resources to conduct extensive user research, we were able to interview dozens of people within our target demographic. In talking with various activists looking for a tool to help them get out the vote, and with various voters who just wanted a way to enhance their own political participation, we found the number one concern was security. Most people did not want to share any information with us if it was stored remotely (which is one reason we, at first, stored all personal information locally). People were concerned with Russian and Republican hackers, grimmey corporate advertisers, and any ulterior motives we may secretly possess.
If it was entirely up to me, I would have also made registration optional. The stakeholders that be, however, wanted to ensure that we at least had access to an email address so, if a user fell off the conversion funnel, we could reach back out. Nonetheless, the optional approach alongside storing data locally on a user's phone or computer immediately calmed users' nerves and managed to increase conversion rates by promoting trial.
We achieved this positive twist on an apparently limiting situation by displaying a list of random elections to users who didn't provide their information to us. While we couldn't show them accurate data about their own elections or the elections of their friends and family, we could show them how the app would look if they chose to provide the requisite data. User's that didn't enter their address would see a list of ten random elections from around the country. We found that user's were substantially more likely to provide sensitive data if they were informed of its purpose and could directly tie it to a relevant and immediate need.
After confirming with my development team about the practicality of technical impementation, and after getting signoff from the stake holders on the flow and layout, I moved onto designing high fidelity mockups. This step is occasionally unnecessary, as hi-fi mockups are time consuming and don't help you practical limitations of your design. If possible, I prefer to have an actual framework built in place of hi-fi mockups. These frameworks are often just as easy to iterate on, draw attention to design limitations, allow stake holders to preview the final product, and build towards the end product (killing several birds with one stone).
On the topic of design limitations, notice also that my designs do not completely adhere to either Apple's Human Interface Guidelines nor Android's Material Design guidelines. Though I'm sure this is a controversial decision, my intention was to preserve our resources by designing once and implementing twice (on both Android and iOS). This approach also lowers maintenance costs going forward.
Additionally, the modular design, which separates each election into self-contained "cards", also caters to a mobile-first, responsive web design strategy. I was able to easily apply the core of the mobile styles to the web application.
I'm also the first to admit that the above mockups are far from perfect. I did not put much time into assuring that all of the elements were properly aligned or that the sizing was just right. This was not a mistake, but a matter of practical execution. I am a firm believer that a startup needs "good enough" over "perfect" in order to survive the rough terrain commonly associated with the first years of its life. In order to provide stakeholders with rapid turnaround times that are necessary to show results to donors/investors, and in order to facilitate an agile iteration process, my mockups are solely focused on effectively communicating my intentions to team members and customers.
My philosophy on practical execution lends itself well to my product management style. Rapid, agile, and decisive action is crticial to an early stage startup. Sometimes that means making a mistake--but if done right, an agile team should be able to quickly remedy the error and correct course.
Another key element of my product management philosophy is direct communication. As the product manager, I am responsible for ensuring that all parties (1) know what they are supposed to do; (2) have the resources to do it; and (3) have all roadblocks cleared. I have seen several product managers interpret this role as a sort of interpreter: they would meet with a coworker, discuss any roadblocks or other issues, and then communicate on their behalf to other relevant parties. This is like a game of telephone, and it can cause severe inefficiencies. Instead of speaking on behalf of each party, I prefer to connect them directly when possible. I see myself as responsible for keeping track of all moving parts, and ensuring that they are all in regular communication. If I know that a developer and designer disagree on the implementation of a feature, I connect the two to discuss rather than discussing on their behalf. If necessary, I step in as a thought-translator when necessary. This approach allowed my team to work rapidly through complex issues, often fitting several weeks worth of sprints into only a few days.
This ability to rapidly develop made it a little easier when dealing with several different data vendors and third-party partners. Development occured on top of a constantly changing landscape, so it was not uncommon for critical requirements to come to light on a moments notice. Since we could work quickly, we were able to keep sprints as small as one week, so that limiting the risk mid-sprint disruption.
As we approached the final release deadline, we needed to ensure that we could deliver on what we promised to public relations. To do this, we kept a releasable iteration ready at all times. If we had to, we could release a stripped down version of the application reminiscent of an MVP.
Finally, for those interested, my go-to product management tool for this project, though slightly controversial, was Trello. While Trello doesn't scale well, it mimics a scrum board for a small team very well. Our development team consisted of two senior iOS developers who worked on contract, plus a senior backend developer who was doubling as our CTO. I used Trello to setup a standard scrum board that consisted of eight lanes: backlog, current sprint, in development, dev complete, in test, bugged, ready for release, and released. I also created a board that stored all released cards from previous sprints (each sprint had its own lane).
I built all the HTML/CSS frameworks for NewFounders, including our marketing website, conference website, and unreleased EveryElection web application. For the EveryElection application, I used the Jekyll static site generator and the flexboxgrid grid framework.
I definitely stretched the usefulness of Jekyll in this context, but it's basic use of partials and liquid templating made it extremely simple for me to implement my web design framework (seen above). The flexboxgrid was perfect for implementing a grid without all of the bloated design and extra functionality that goes with larger, more common frameworks like Foundation (my usual go-to) and Bootstrap. I also appreciated its use of flexbox's in place of inline-block elements.
This project is still in development. As the web version is not a priority, we plan to release in within the next few months.