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.
facilitating: emily & daniel
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
- 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.
- going from mockup to css with each rev isn't necessary. integrating the workflow is more efficient.
- 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.
- lots of different perspectives on what the site should look like, what copy should be used