Written for DMI magazine — Summer 2014.

US elections technology—the infrastructure on which democracy depends—is proprietary, locking up public data; unlocking that data is a design challenge on many levels.

— Hugh Dubberly

In most countries, elections and voting are managed by the federal government. In the United States, elections are overseen by the secretaries of state of each of the 50 states, but ultimate responsibility resides with local elections officials (LEOs) in each of the more than 3,000 counties in the country. That means US elections are broadly decentralized and can vary widely from one location to the next. Under this system, elections technology—the critical infrastructure that supports our democracy—is also broadly decentralized and also varies widely from one location to the next. What is more, our elections technology is aging, even antiquated. Some estimates suggest almost all of it will need to be replaced in the next 10 years.

The result? US elections are fraught with problems, and the experience of many voters is far from ideal—often unpleasant, sometimes downright painful. Problems range from long lines and confusing ballots to equipment failure and voter disenfranchisement—and worse, to election results that many no longer trust.

The causes of this situation are many and complex, but the bottom line is that our political system and our market system have so far been incapable of solving the problem—much less innovating. We need an alternative—and that requires design.



Introducing the TrustTheVote Project and VoteStream

The mission of the TrustTheVote Project is to develop a set of elections technologies that are trustworthy, up-to-date, and complete, and to make the technologies available on an open- source basis (that is, for free) for adoption or adaptation by any election jurisdiction in the US.

The TrustTheVote Project is a not-for-profit effort headquartered in Silicon Valley and staffed by social entrepreneurs and seasoned technologists who are putting local elections officials at the center of their work. LEOs from across the country are sharing their views on requirements, collaborating to define specifications, and providing their feedback on prototypes. (The TrustTheVote Project is engaging LEOs using the same community process used to define and build the internet—the RFC (request for comments) process. The TrustTheVote community’s deliberations and resulting specifications are published online and available to anyone.)

One of the key things LEOs have said is that citizens need to be able to trust the elections process and the technologies that support them. That means the technologies must be:

  • Accurate—List all voters and only eligible voters on voter rolls. Count votes without errors, as they were cast.
  • Secure—Ensure voter privacy, data integrity, system reliability, and proper authentication and authorization for access.
  • Transparent—Allow verification of required accuracy. Log all changes to guarantee accountability.
  • Verifiable—Enable everything that matters about an election to be independently verified, including accuracy and security.

The TrustTheVote Project has seven main building blocks:

  1. Open data standards
  2. An election management system
  3. A voter registration system
  4. Components for creating ballots
  5. Casting ballots (voting)
  6. Counting ballots
  7. Reporting results

This last building block is where VoteStream lives. VoteStream is one of the first elements of the TrustTheVote framework to be built. It’s an election results reporting system, funded in part by a grant from the Knight Foundation.

VoteStream has three facets:

  1. A set of open data standards for election results and participation and performance data
  2. Open-source software written to those standards
  3. Services deploying the software

The goal of VoteStream is to make election results for every contest in every jurisdiction in the country-down to the precinct level—publicly accessible to all citizens, anywhere, in near-real time.



Open data

One of the key principles behind the TrustTheVote Project generally, and the VoteStream reporting system in particular, is that elections data should be open data. Open data is “the release of information by governments and [others]…to enable insights,” and, like big data, it’s a growing trend.

Unlocking elections data will lead to insights that will improve elections processes and strengthen democracy. American academic and political activist Larry Lessig made the point well: “The government could make its data available in a way that enables a wider range of people to help make the government function better.” VoteStream helps do just that for elections.

Elections data exists today, but it’s not readily accessible—due to proprietary systems, lack of standards, and limited opportunity for viewing.

Elections data today Open data
Proprietary systems Public by default
Proprietary formats Accessible format
Little metadata available Described
Reusable (if you can get it) Reusable
Partial or incomplete Complete
Release can be slow Timely
Users are on their own Managed post-release

errs_01-results-current Today, Ramsey county, Minnesota, reports election results in spreadsheets and PDFs–formats used by many jurisdictions.

errs_02 results new map Here’s what VoteStream looks like reporting results for Ramsey county.

Unfortunately, elections data rarely meet the definition of open data. Most elections reporting is limited to summary vote counts. Detailed reporting only comes much later, if at all—not because detailed data don’t exist, but because the data are locked away in proprietary systems that use proprietary data formats.

Current reporting methods and formats vary greatly by jurisdiction. The process is often manual, slow, and prone to error. In many cases, election officials must re-key results—by hand—to get them out of proprietary election management systems and into the public domain.

If we can legally unlock the data, we can turn elections results into open data.



Standards

One way to unlock data is to follow standards. The VoteStream election results reporting system is built on the Voting Information Project’s (VIP) data standard. The TrustTheVote Project is collaborating with VIP’s underwriter, Pew Charitable Trust, as well as with election officials, Google, and standards bodies (for example, IEEE and NIST), in an open, public process, to extend the VIP standard to include:

  • Contest and question data (for example, what’s on the ballot in each precinct)
  • Location data (for example, precinct and district geo-spatial data)
  • Results for each location and contest combination (in a form that’s accessible individually, in chunks, or in aggregate)
  • Performance and participation data (for example, numbers of ballots cast and rejected) In order for VoteStream to work with existing election management systems, the project team has written connectors—applications that translate from existing formats into the extended VIP data standard. Connectors are a type of application programming interface (API).



Software and services

VoteStream includes a data store, back-end logic to manage the system, and feeds for near-real- time delivery of data to subscribers. The back- end software also answers API calls—requests for data that follow defined rules. That means anyone who follows the rules can access the data—anytime, from anywhere. People are free to create their own tools and republish the data or do their own analysis.

VoteStream also includes a visual scoreboard, a web front-end, to enable local elections officials to easily share their data with the public. The scoreboard displays results for each precinct in a county for each contest as both tables and maps. The maps are generated with underlying data from the Google Maps API, with overlays for precinct and district geo-spatial data. Users can toggle to Satellite View, zoom in and pan—and reset. Mousing over a precinct pops up detailed information.

Users can scroll through contests, or filter data to quickly find specific content. Users can also search by keyword, such as entering the name of a candidate. For journalists and researchers, there’s an advanced search feature, enabling queries on performance and participation data. And it provides a feature for exporting data files.

All this software is available free to anyone, under an open-source license. Local elections officials can download the software and set up their own systems, and third parties can build products and services based on the software.

The TrustTheVote team completed an alpha version of VoteStream in March and demoed it to the Knight Foundation and the public. Refinements are under way, as is work on the rest of the building blocks in the TrustTheVote Project.



Implications

VoteStream will enable researchers to look closely at elections. They will be able to compare rejected ballots with demographic data and determine, for example, if rejection rates are significantly higher for the elderly or other communities. That’s the kind of research that will help us find problems, fix them, and restore trust in voting—and ultimately help preserve democracy.

For more about the VoteStream elections results reporting system, visit votestream.trustthevote.org. For more information about the TrustTheVote project, visit www.trustthevote.org.



The role of design

Creating a better experience for voters—and enhancing the critical infrastructure that supports our democracy—is a complex nested set of design challenges. In the TrustTheVote Project and the VoteStream elections results reporting system, design plays a role on many levels.

Easiest to see is design’s role in giving form to ideas. VoteStream and other software applications in this family of elections technologies have to look like something. The visual form of interfaces, instructions, and communications materials must be designed and content must be developed. Perhaps more important, the process of prototyping—creating, testing, and iterating mock-ups—helps the development team and local elections officials clarify goals, understand possibilities, and chose between trade-offs. Prototypes are also important for usability testing.

Another level of design involves working out how voters and elections officials interact with each other and with technology to co-create elections. That means defining the possible voter registration journeys, the several voting paths, and the paths by which elections are defined and ballots are created, cast, counted, and reported. Each touchpoint must be effective and efficient, which requires interaction design. And these systems must work independently and together, which requires both service design and the design of software application architectures, data models, and data standards.

A complete set of elections technologies cannot be created by one person. The sheer amount of labor requires a development team. But while a team is necessary, it is not sufficient. In order to succeed, the team needs the trust and help of the community of elections officials. That is to say, standards are only meaningful if they are adopted, and even free software is not guaranteed to draw users. Drawing community support is not an accident. It requires the design of systems and processes that support conversation and engagement.

In addition, the development team needs resources and must interact with the market and with government entities. This requires another sort of design focused on business and organizational structures, facilitating operations, and social dynamics.

And, of course, elections technologies are embedded in our larger political system, which was itself designed and which we continue to evolve.

In practice, these levels are anything but clear and distinct. They connect and overlap (or fail to) in lots of messy ways. Bringing them all together in the right sequence, efficiently and with good humor, is a challenge in any project. It involves working together to create understanding and agreement—a process at the heart of design. And it demonstrates that all design is political in nature—not just the design of elections technologies.

Download PDF

View the VoteStream project and the TrustTheVote Election Technology Framework concept map.

1 Comment

  • Peter Duke

    Jul 14, 2014
    7:08 pm

    Mr. Dubberly,

    You once wrote that “The place to begin any design project is with the problem.”

    The actual problem that you identify is correct, in that voters are disenfranchised and do not trust elections, but the rationale, conclusion and proposed solution is specious and un-American, or at least un-American as defined by the Constitution.

    You use straw-men like “broadly decentralized and also varies widely from one location to the next” as if it’s a bug. I’ve got news for you, that’s a feature.

    Again, “Our political system and our market system have so far been incapable of solving the problem-much less innovating” is another straw-man… says who?

    Voting is “far from ideal—often unpleasant, sometimes downright painful” because of long lines and confusing ballots? You don’t really think that’s the problem, the un-met need, do you?

    The primary problem in our “Democracy” is not effortless voting with real-time counting and streaming multivariate views, but validating the voters. In every other civilized country in the world, either a Voter ID or a “purple finger” is required to guarantee the legitimacy of an election.

    The reason that there is voter disenfranchisement and no trust in election results, is because The People do not trust that the Voters are being properly managed. US Elections are so rife with fraud, it’s no wonder that this Republic is heading towards a Roman end at Internet speed.

    If the TrustTheVoteProject actually wants to come up with a helpful solution to the election integrity issue, they might do well to partner with one of the several groups in this country attempting to solve the voter-fraud issue… to assuage the potential for a “Lipstick on a pig” scenario that will be the ultimate outcome of this project and projects like it.

    Accurate, Secure, Transparent and Verifiable doesn’t amount to a hill of beans if the VOTERS are fraudulent and invalid. Voting software does not need to be Federated (regardless of it’s “open-source” sensibilities), it’s again a straw-man. The argument is counter to the founding principals of this country, after all we live in the “United States”, not the Republic of Washington D.C.

    Voter identification and validation is the real issue. The founders of this country trusted the “Several States” to come up with their own solutions in order to prevent a central power to dominate the status quo.

    Making fraudulent election results pretty, real-time and multivariate doesn’t do anyone any good, in fact it’s harmful by the nature of it’s apparent legitimacy… unless the actual idea is for fraud to appear more legitimate.

    GIGO

    I hold you and Matt Mullenweg in the highest esteem, please don’t allow yourselves to become knaves, crafting traps for fools.

    Insist on valid data, before you design anything, otherwise the work that you are doing is a disservice to both your craft and your countrymen.

    Thank you for all that you do,

    Peter Duke

Leave a Comment