People-Powered Programs: How Pro-Social Projects are Harnessing Networks & Communities Of Practice To Get Things Done

From DevSummit
Revision as of 20:48, 17 November 2011 by Eads (talk | contribs) (Created page with "Intros Laney: Amazon background, tons of implicit data from tracking, how do you do this if you aren't? Sara: Tools for Occupy Marc: When shouldn't you listen? Caroline: Practic...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Laney: Amazon background, tons of implicit data from tracking, how do you do this if you aren't? Sara: Tools for Occupy Marc: When shouldn't you listen? Caroline: Practical development Kristine: How to develop software out of the work they're doing? Greg: OpenStreet Map – make UI better Ryan: Open source microfinance Adam: – dealing with millions of people! Getting feedback for Celine: Commercial experience in marketing, soon to lead social coding project Marc M: Techsoup, community engagement. Karl: N-ten.... how to build backends to support what communities want? Derek: Guardian project (privacy and security) – how to make security easy?


Getting people to tell you what they want Knowing when to listen Implicit vs. explicit

Laney: Do people find user input important? (Yes, all thumbs up!)

Implicit (inferring what people do) vs. explicit (tracking what people do)

Marc: Metrics are killing social/mobile games, because it becomes accounting.

Laney: In Amazon search, metrics would tell you Harry Potter should always be returned.

Ryan: Implicit is useful, but explicit has some value. Not only talking to your client to watching your client in action.

Darek: Implicit and explicit is not same as stated needs vs. observing behavior.

Celine: When you ask what they want, you need to ask what the problem is,

David: Is that because we're asking what you want.

Ryan: People come to you when they are frustrated and spend a little time thinking what would be a useful solution.

Celine: There's mismatch between expectations, needs, and deliverables.

Adam: MoveOn does tons of user testing, A/B testing. Listen to what users say, but testing/metric-driven culture strong as well. Tested questions themselves. Three major incoming channels, which are sometimes in conflict.

What are bad questions?

Adam: Open-ended (“how did obama do this week” vs. “did your opinion change positively or negatively about obama over past week”)

Laney: How does MoveOn test?

Adam: Read, categorize, feedback, repeat.

Darek: How much weight to put on solicited vs. testing data?

Adam: Look for trends, commonalities, etc. All email is read by volunteers and put into metric framework – possibility for metrics and human response.

Laney: NetSquared's survey vs. implicit data.

Marc M: Organizer survey, general community survey. Raised questions about engagement – what does it mean when people click? What kind of action results from those clicks? Is that kind of engagement meaningful? How do we know?

Caroline: Who responds to surveys, how do you make it work?

Laney: Do surveys capture most vocal users?

Marc: Problem – the people who aren't engaging are the people they need feedback from.

Kristine: Does n2 follow up?

Marc: Definitely, especially people who DIDN'T respond? But also, how much should you pester?

Laney: How do get explicit data, without pestering? What are tools you've used for user engagement?

  • Community boards (Darek): Exacerbated squeaky wheels problems but captured a lot of information about problems big and small. Leverage more engaged users to nurture and explain the product.
  • Identify barriers to participation: Finding useful channels: Forums, skype, open chat window.
 * Does community board/blog posts/etc help? 
 * Ryan: Whatever works for community
  • Polling
  • Twitter/Google+: Public conversation about product.
  • Ustream/Google+ hangout/video services: Real time chats
  • Framing and metaphors: Forums make sense in Africa because people know what that form means. Calling github "facebook for code" reduced barriers to entry w/o changing tool at all.
  • Wireframing and prototyping
  • Engaging thought leaders (Ryan): Darek -- cherry pick power users and give them extra rights/responsibilities. (Marc: "Deputizing your best users)
  • Less active users in community feel more comfortable complaining about
  • Kristine: taking people out for dinner or a drink on regular basis.
  • Kristine: Map out ideas from sessions, prioritize with sizes of circles, connect ideas and needs... put it into spreadsheet.

Marc: What do you do with this data once you've got it?

How do you scale Kristine's grassroots model? Identification, empowerment, and training of users.

Being in a space where people are: Twitter is a dialog and not a microphone, though people may not see it that way (Marc).

Laney: Built tiny Wordpress site with ideas they were considering -- reached out to thought leaders in community. And dead silence.

Adam: Surveys get awful response rates. So how can MoveOn integrate survey questions into other communications? Make a survey look like an action. Don't ask 100,000 10 questions, ask a million people one question. HOW do you ask? Answers are links in emails (everyone REALLY liked this).

Ryan asking Adam about workflows: Integrating campaigns and surveys: "Should we remove the tree on elm street?" both a survey question AND an action...

Karl: How do you increase engagement in online community? Hear feedback they want groups and features, but giving them what they want not very successful. Ignoring user input.

Ryan: UX design -- putting survey into workflow really helped response (though different workflow from moveon).

Marc: Balancing impact and cost.


  • Understanding what users are saying (exploration)
  • Understanding what users need (translation)
  • Knowing what you should do (implementation and prioritization)

What users are saying

What they need


Look at difficulty (Ryan)

Laney: Artifacts like wireframes and prototypes can be very helpful. But people focus on wrong things, or not don't have great idea of how to see it/discuss it.

Marc: Video prototypes really helpful.

Ryan: Customized demos; reduce barriers to creating custom data in prototypes.

Celine: Sharing artifacts with the right people, including expectation management.

Narrative artifacts? (Laney)

Adam: will test first few paragraphs of emails, then not the rest hardly at all. "Trusted memory experience"

Kristine: Maps and sketches / digitally photographed and available several places. Give to users to put on their wall and share ("like a trophy"). To the point where mind map is presented as art in some spaces.

Ryan: Publishing roadmap (already decided) deeply increased engagement, though ran into problems with long-term follow-through because of funding.

Celine: Doing regular followups is really crucial for keeping process successful. Found that calling 1,000 "middle class" users was very useful, people found themselves valued. Asked alternatives what people were using.

Marc: Would moveon publish roadmap? Adam: Which one? Software? Agenda? Problem: Maybe Moveon doesn't think that way, especially at the development level.