Difference between revisions of "Codesign resources for human rights documentation"

From Responsible Data Wiki
Jump to: navigation, search
m
Line 6: Line 6:
 
Bringing people places is expensive. (But is it more or less expensive than building a tool which doesn't fit?)
 
Bringing people places is expensive. (But is it more or less expensive than building a tool which doesn't fit?)
 
===Commercial sector approach===
 
===Commercial sector approach===
[[File:UserInteractiveTesting.jpg]]
+
[[File:UserInteractiveTesting.jpg|600px]]
 
In the commercial sector, market research, A/B testing, etc is considered standard. It doesn't guarantee success, but it does increase the likelihood. Money, views/clicks. Besides getting people to the application, but like Amazon with a cart and things to buy, you break out the process into buckets and see what happens in each bucket, and what is preventing people from doing what we want in each bucket?
 
In the commercial sector, market research, A/B testing, etc is considered standard. It doesn't guarantee success, but it does increase the likelihood. Money, views/clicks. Besides getting people to the application, but like Amazon with a cart and things to buy, you break out the process into buckets and see what happens in each bucket, and what is preventing people from doing what we want in each bucket?
 
* Are people even coming to the website?
 
* Are people even coming to the website?

Revision as of 23:32, 29 March 2016

This page is for you if you've ever thought "We're wondering why our tools aren't being used, or we're about to build one and we want to increase the likelihood that it will be useful to the end users."

Problem: Tool builders don't know how to speak to users, users don't know how to speak to developers.

Costs and benefits

Bringing people places is expensive. (But is it more or less expensive than building a tool which doesn't fit?)

Commercial sector approach

UserInteractiveTesting.jpg In the commercial sector, market research, A/B testing, etc is considered standard. It doesn't guarantee success, but it does increase the likelihood. Money, views/clicks. Besides getting people to the application, but like Amazon with a cart and things to buy, you break out the process into buckets and see what happens in each bucket, and what is preventing people from doing what we want in each bucket?

  • Are people even coming to the website?
  • If people are putting things into the shopping cart, but not purchasing, is there something ugly about that process we need to fix?
  • Each bucket needs a metric and a baseline.
    • Can make a funnel for each of those buckets, dive down deeper
  • A/B testing is just about testing things with hundreds of users
  • User groups is about asking people to go through a process and then asking them how they felt about it, what stood out, etc
  • Paper prototyping works for both groups

This assumes LOTS of users, computational power, resources.

Responsible data

This doesn't work when we care about privacy (we're not using cookies). We also care about consent. We also tend to not think of our problems as tractable. What if we can't assume we know what people want (in a new field or with a new population), nor do we want to impose our view on them. We are working for overall justice and equality. We tend to care more about people being empowered more than us being right. Metrics for us are more difficult. It's not just about clicks or money. Impact is so nebulous and difficult to measure. Outcomes track impact. Outputs are tangible things (workshops, downloads, etc) but (hopefully) lead to outcomes.

Who owns the tool and process? In codesign, it's the end users who feel obligation and passion in seeing it succeed. Also creators should be making ourselves obsolete.

External resources

Practitioners

For Hire

  • Aspiration :  : how to create common language and clear expectations across discipline backgrounds through participant guidelines at events.
  • Blue Fin Labs : working with at-risk user groups to broker interactions with developers for design sessions
  • OpenIDEO :
  • [http:// Frogg Design] :
  • [http:// Second Muse] :
  • [http:// Climate Centre] :

To Learn From

  • Codesign Studio at MIT : class projects with community partners, reflections of materials
  • [http:// Luma Institute] :
  • US Department of Arts and Culture : active engagement frameworks for hyper-local groups around what creative acts they want happening in their communities.
  • Random Hacks of Kindness in some places : brings in "subject matter experts" (aka "end users") to help developers and designers think through what to build related to disaster and humanitarian response.
  • Digital Democracy : works with local communities to discover their needs, primarily around environmental justice, and then to deliver tech systems to solve those needs in a way which is locally held
  • Digital Communities Class : used codesign methodologies to work with local partners in Providence, RI on digital projects.
  • [http:// Museo Areo Solar] :

Gaps

Been able to compensate people before, been able to colocate with people. Difference between a survey and codesign is that.

There are some resources out there, but people get phds in this, so it's difficult to make it happen on your own.

Current interaction methods often don't consider informed consent.

How to first find your groups to work with

Core misunderstandings about what is true in a place (and that people don't know what to tell you about, because it's their lived experience).

How much time you have -- if you have an hour-long workshop, the first 45 minutes will be installing a thing

Have to close feedback loops -- respond to feedback, let people know they're heard, why something was dropped. "What did you expect?" ... "Instead, what happened?"

Do people have time to give you feedback? Build in time to iterate with people, workshop trainings as bug hunting as well. Then have people you've worked to train, train someone else.

Case Studies

Documenting some use cases and making a meta documentation. Format -- PDFs don't do well (but can be so pretty!)

  • Fab riders
  • IDEO