Designing Political Web Apps for MoveOn.org

Uses MoveOn.org’s get-out-the-vote web applications, and other apps, as examples of how to design for political campaigns.

MoveOn mixes political and development teams, as well as volunteers, end-user support staff, and others who are usually outsiders to the development process. As a result, there’s a strong bias towards incremental, pragmatic improvements to tools rather than large monolithic projects, and a focus on usability and task completion rates (response rates). Changes are often made on short timetables in response to changes in the political situation or logistical needs.

Usability has a special importance for MoveOn’s applications; many of our users are older and not technically savvy, and all users are volunteers who are free to leave if they find an application is less than a joy to use. As a result, MoveOn seeks to gather as much feedback as it can on the usability of early prototypes, and uses emprical testing and feedback from end users to further refine the applications.

Several factors force MoveOn to eliminate, or at least hide, complexity in its applications. Even for get-out-the-vote efforts that involve complex targeting, our applications seek to hide complexity and difficult choices from the user, and make the flow as simple, short, and clear as possible, even when it has significant costs in developer time. Conversely, because our applications often have to handle sudden spikes in load—such as thousands of phone calls made per minute—we design and even spec applications to ensure that key parts of the backend are simple and can be tuned for maximum performance.