MAPLight.org site redesign: how we did it, what we learned

Facilitated by Dan Newman and Emily Calhoun, MAPLight

MAPLight.org, a data-driven website tracking money and politics, redesigned their site from top to bottom to improve usability and performance. In this session, MAPLight.org Research Director Emily Calhoun and Executive Director Daniel Newman will share the process we followed, what worked, what didn't, and what we learned.

Session Notes

facilitating: emily & daniel

attending:

macheas neal scott sarmeesha jeremy matt john arthur

maplight site uses massive databases, creates visualizations. goal is for people to dig into the data in different ways

initial objective of design: revisualizing, theming

Maplight uses 3 databases: money given to politicians votes made interest group support to politicians

launched 3 years ago for US Congress data

Daniel's sketches > Designer > Programming

Now: higher expectations from different constituencies

ML's redesign process:

- figure out what are people looking for using analytics
 - organize things around that.
  - showed mockups to audience. change was too incremental.
- second round of research

start with design or requirements

- agile works best but developers need access to everything (graphics, files, data). Constant changes are impossible without the access.
- agile appraoch to requirements gathering, version it to the requirements that go to developers
- stack overflow. easy to navigate.
- ongoing conversation with community. paper prototypes.

impossible to anticipate all problems. define requirements as much as possible knowing they'll change.

daily communication is essential. effective communication among team is difference between good and great

website is an organic process

- start with painpoints leading to the redesign
- gather stakeholders
- strategic plan
- developers/designers on board to match tactics to the strat plan

scope of what was being redesigned expanded - started with 2 pages, then moved on to rethinking everthing. slowed the process down but led to better end result

One goal:

- reduce the amt of reading to get to the interesting part
- copy needed updating
- customization was hidden
- make the site more effective for research (including internal research)

Tension between building high priority features right and allowing users to make any query

Tension between clean presentation to most visitors and deep functionality for media research

Goal of feature parity but the scope of the project expanded

suggestion: define the minimum feature set for release then schedule ongoing releases

Difficulty of matching agile project with development contracts.

ML went through many revs with designers because they had changes/improvements. Designers got frustrated

- solution: time-defined contracts instead of # revs.
- nonprofits get put at lower priority because of "nonprofit rate"

Frequent releases can be used for media stories.

Transparent product plan builds relationship with constituencies.

Workflow.

- going from mockup to css with each rev isn't necessary. integrating the workflow is more efficient.

Agile

- never assume you have all the requirements
- a subset of the requirements can be used for the first iteration
- constant testing and evaluation. agile allows feedback to be incorporated into next release.

Big issue was feature/scope creep. The discipline is in defining the product plan.

Internal decisionmaking/challenges

- lots of different perspectives on what the site should look like, what copy should be used