About cfd

Twitter: @cdetar

On groups and tasks

Last week, I had the opportunity to present our work on consensus codesign to sponsors as part of the MIT Media Lab’s semi-annual member meeting.  As part of the presentation, I collected some of the background research into groups and meeting process in this presentation.

Two of the important organizing principles that I’ve found the most useful to talk about are both taken from McGrath’s 1984 book “Groups: Interaction and Performance” — meeting structure, and task types.

Meeting structure

Here is McGrath’s model of the structure of a meeting, attempting to map out the major contributors and influences to a meeting process (these graphics are my own adaptations and simplifications of McGrath’s):

Influences of a meeting: Individuals, group structures, tasks, and technologies.

The model identifies 4 major components that contribute to the function of a meeting:

  • Individual considerations: What are the skills, dispositions, interests, and agendas, and communication styles that individual participants have?
  • Group structure: is it a rigid hierarchy, or an explicit non-hierarchy? Is there a facilitator? Are there expected patterns of behavior or rituals that the group brings? These all contribute to the group structure.
  • Task/situation: What is the group trying to accomplish? More on this below.
  • Physical setting / technology: Are you on a street corner, or in a board room? Do you have computers, whiteboards, smart phones, projectors, post-it notes, or any other meeting aids?

I find this model useful mostly in thinking about just how limited a purely technological solution or meeting aid will be.  All of the other considerations need to be taken into account — it may be necessary for the group to engage in more nuanced trainings to inform their meeting process or group structure in order to make effective use of any particular technology.  This is where games like Moon Talk or Flame War come in.

Task types

This is a complicated, but surprisingly insightful model of the different sort of tasks a group might engage in:

This model posits four main quadrants of different types of tasks a group might engage in:

  1. Generative tasks: brainstorming, coming up with new ideas.  The point is to generate and expand a set of possibilities.
  2. Choosing tasks: deciding, selecting, figuring.  The point is to contract the set of possibilities and choose something.
  3. Negotiating tasks: the difference between this and choosing is that negotiating tasks involve power dynamics or personal conflict.  It’s not just a matter of selecting the “correct” answer; it’s about building trust and understanding, and potentially making concessions.
  4. Execute: getting things done — building things, organizing things, documenting things.  This could involve stuffing envelopes, writing code, or doing tasks in a project.

In addition to the four main quadrants, there are the two additional axes: on the vertical, the range between cooperative and conflict oriented tasks; and on the horizontal, the range between conceptual and behavioral tasks.

  • Generative tasks are inherently cooperative; negotiating tasks are inherently conflict oriented; choosing or executing can be a mix of the two.
  • Choosing tasks are inherently conceptual; executing tasks are inherently behavioral; negotiating or generating can be a mix of the two.

These divisions and quadrants, I find, are super useful in trying to figure out what sort of affordances a tool might need if it’s going to support a process of a particular type.

The takeaway

I find these models to be incredibly useful in building understanding of just what’s going on with a meeting process, and also laying out the field of possible places in which to build either process-based or technology-based interventions.  Like any model, these aren’t definitive declarations of how the world works, and they’re wrong a lot of the time.  But they’re useful ways to decompose and think about a complex issue, and to come up with new ideas.

10 points, Dotstorm with the class

Last Friday, Eric and I had the opportunity to present to the class and discuss our work so far, as well as to try out a couple of tools we’ve developed.

Originally, we’d planned to try running a game of Moon Talk with the class, but decided against that based on our experience that the game is best with 10 or more people (the game is too easy with a small number).  Instead, we discussed the background research in groups and decision making processes, our prototyping with community partners, and tried using the 10 Points and Dotstorm tools.

10 points

The “10 points” tool or “bill of rights” tool (found at http://billofrights.byconsens.us) is based on the meetings tool by May First/People Link.  The intention is to help groups to arrive at consensus on 10 principles, values, questions, rights, or some other kind of point that the group has in common.  Anyone can change one of the points, but if they do so, all “votes” for it are cleared, and people have to re-vote on them.  So after a point has gained some support, you have an incentive not to nit-pick on wording unless it’s a substantial change.

I had interest in using May First’s tool in some workshops, but it was broken when I tried, and wasn’t looking like it was going to get fixed any time soon.  So I threw together a version which is more etherpad-like in its design ethos: zero barrier to entry, everything editable by everyone, the minimum feature set that will work, real-time-collaborative-everything.

In class, we used this tool as an exercise to identify 10 principles for codesign (Sasha used this tool previously to identify 10 questions for transmedia).  Based on the feedback from the class, I went back and changed a bunch of things to improve the editing experience:

  • I removed the automatic sorting of points based on the number of votes they got, since that was confusing and interrupting if you were currently editing something.
  • I reduced the font sizes and whitespace to fit all the points on screen, and added better feedback for what you’ve voted on, and the total count of vote numbers.  I think this may solve the main desire behind the point sorting by vote — you can quickly see what the state of all the points are, without the jarring re-sorts.
  • I made the real-time updates more subtle, and fixed it so they don’t interrupt your typing if you’re working on a point.
  • If someone’s editing a point, everyone gets an indication that it’s being edited.

Another piece of feedback from the class was that after some certain amount of time working on the exercise, we all reached a point of fatigue.  I wonder if the updated interface that reduces the conceptual burden of seeing the state of all the points would help that — another alternative we discussed was to reduce the number of points (of course, a group could agree beforehand to only use 6 or 8 and leave the others blank).

This tool fits nicely into a toolbox of consensus tools to reach for, but it’s rather narrow in its focus.  I don’t imagine standing groups using it often; but it could be an interesting diversion where returning to a set of core organizing principles or points is important.

Dotstorm

Dotstorm is a brainstorming tool I’ve been developing based on the experience of doing brainstorming exercises with a few different groups (our class included!).  The tool is loosely based on the Nominal Group Technique, a brainstorming technique in which a group goes through five stages with a problem:

  1. Introducing the problem or topic, and explaining how the technique works.
  2. Brainstorming possible ideas/solutions/points that address the problem.  Each member of the group develops these on their own.
  3. Sharing the ideas with the group.  Each participant explains the ideas they’ve contributed.
  4. The group discusses the ideas, sorts them, collapses similar ideas, and contributes any new ideas that arose from discussion.
  5. The participants vote on or rank the ideas.  The top voted/ranked ideas are considered the outcome of the process.

A common variant of this process is to write ideas on post-it notes, which makes them easy to share and arrange publicly, as well as to draw pictures in addition to text, engaging other parts of folks’ creative brains.

Dotstorm is a tool which facilitates doing this process, but entirely online.  The intention is that groups using it will have a projector or other large shared screen, and that most (but not necessarily all) participants will have a smart phone, tablet, or computer.  Participants can add ideas to virtual post-it notes using their devices, and those who have camera-enabled devices can take pictures of any additional notes written out on paper to contribute them.  Ideas can be any mix of photo, drawing and text.  Once they’re entered, it should be possible (soon!) to easily archive, embed, share, and remix the ideas in flexible ways.  Right now, the tool just supports tagging, sorting, and grouping.  In class, we used the tool to brainstorm ways to communicate emotion online.

Like the 10 points tool, dotstorm is suited to a somewhat narrow task — brainstorming and sharing ideas around a topic.  It’s not really helpful for making complicated, nuanced decisions, or for negotiating issues within a community.  But like the 10 points tool, my hope is it will sit among a set of tools a group can reach for, expanding the group’s flexibility and effectiveness.

Reflections on FAIL

On Friday we had the great opportunity of reflecting on the opportunities for failure that our projects might face.  Everyone in the class took time to brainstorm ways in which we would predict that each others’ projects might succumb.

Reflections on reflections on failure

There is a rich history of failed projects for social good, and a great deal of gnashing around how useful it is to pay a lot of attention to failure.  (The #FailFare conference, started by MobileActive.org, comes down firmly on the side of amplifying failure).

The tricky aspect of all reflections on failure (or attempts to learn from success) is figuring out what the important variables are that distinguish failed projects from successes.  There are so many ways something can fail – everything from design, timing, poor community connections, or infinitely many other dimensions – it’s difficult to say with rigor which things did or didn’t lead to a particular project’s failure.  This difficulty is doubly compounded when it’s prospective: for a project that hasn’t failed yet, which are the things that could do it in?  Where are the actuarial tables for design projects?  Can we get more rigorous?

Continue reading

Consensus design schedule

Forward progress in the consensus design  project has been slow; getting started with one-on-one interviews has been stalled by the slow grind of research bureaucracy.  But here’s the tentative schedule we’re working on.  Eric will be heading up some workshops in the Providence area, and I’ll run some in Boston (and one in Texas, with one of our community partners).

  • Complete 1-on-1 interviews by March 17/18.  I have a list of 20 or so folks who are eager; just waiting on the paperwork to give a goahead for the protocol.  This may have to push back later depending on the speed of the bureaucracies.
  • First Boston/Providence workshops by March 17/18.
  • First testable prototype by March 31, with minimum testable functionality.
  • Workshop in Texas on March 31.
  • Second Boston/Providence workshops by April 15.
  • Second round of prototype iteration by April 31.
  • Documentation of this phase of design process by May 15.

So in total: interviews with 15-20 people, 4 workshops, and 2 prototype iterations.  It’s possibly ambitious, but I like that.

Participatory discord

A recent piece from Consumer Reports lauds Obama’s recently unveiled  “bill of rights for online privacy“, claiming that the administration “took a cue from Occupy Wall Street” by posing the initative as an “open, transparent, multi-stakeholder process.”  Let’s leave aside for a moment the absurdity of the claim that the process for decisions used by Occupy is the same as the process used by the IETF and W3C, and focus on the core observation:  the visibility and popularity of participatory deliberative processes is on the rise (and with it, uncritical conflation of disparate approaches to participation). To the extent that Occupy, the IETF, and Obama’s privacy initiative share a common ground, it lies in their deliberative orientation; an orientation which participatory design also shares.  This is the foundational stuff of “deliberative democracy”, which is based on the principle that given enough time, good will, and deliberation, any difference between stakeholders can be resolved in a solution that everyone can live with.

Not everyone agrees with this principle.  In “Deliberative Democracy or Agonistic Pluralism”, Chantal Mouffe argues that the basic premise of deliberative democracy — that democracy is best construed as diverse groups working together to arrive at a mutually acceptable compromise — is flawed.  Sometimes, different stakeholders will have fundamental premises that are mutually exclusive; if so, it becomes inevitable that some participants will be left dissatisfied with any outcome.  Consequently, an uncritical adherence to a purely deliberative frame may result in poor results — at best inaction, or at worst a process that pays lipservice to claims of participation and inclusion, but which ultimately alienates some stakeholders.   The Economist has raised this criticism with respect to Occupy Wall Street:

Because the participatory democracy of OWS is an ideological endeavour, it can avoid the hard problem of liberal society: the ineradicable diversity of moral belief and the impossibility of consensus. Consensus-based communes composed of individuals who opt in specifically because they already agree with the commune’s founding values can work precisely because the people who would make consensus impossible—people with very different opinions and values—stay away.

Mouffe argues that the solution to this is to model democracy not in terms of consensus, but in terms of ‘agonistic pluralism’: diverse interests engaged in oppositional struggle to win.  Rather than seeking kinder aspirations such as understanding and dialog en route to consensus, agonistic actors seek to advance their interests to the potential detriment of others’.  It’s immediately obvious that even Occupy Wall Street adheres to this strategy, when interests diverge enough: activists participate in civil disobedience, advocate political positions in opposition to Wall Street and corporate interests, and structurally exclude participation from those who disagree with basic principles of equity and direct democracy.  The “big tent” is not so big as to include those who oppose change.

This observation can help inform our participatory design practice.  When the design community in a participatory process is sufficiently small and both designers and community participants are sufficiently like-minded, a model of participatory deliberation can be successful.  But if the stakeholders in a design area become diverse enough, consensus may become impossible, and the participants may have to draw circles to identify which stakeholders are included, and which are excluded, from the design process.

In his dissertation Contestational Design, Tad Hirsch advocates exactly this position. Drawing on Mouffe’s democratic theory, Hirsch describes an agonistic design process where activists design in direct opposition to the interests of some stakeholders in a domain, not as client- or market-driven hired guns, but as partisans.  Hirsch’s analysis helps to make explicit an implicit undercurrent present in literature which advocates the social-justice potential of participatory design: conditions of injustice and oppression don’t exist in a vacuum, but rather because of oppressive interests which must be opposed.  Thus, a participatory design process oriented towards social justice will likely be operating in direct opposition to the interests of some stakeholders in the design domain.  Hirsch never explicitly says so, but despite the contestational orientation of his design work, it operates using a participatory and deliberative model at a smaller scale.  Agonism doesn’t cut all the way through.  Participants who share contestational goals are chosen for an inclusive participatory design process; but designs are ultimately oriented in opposition to the interests of stakeholders who don’t share the same goals.

So is Obama’s multi-stakeholder approach to online privacy policy design likely to succeed?  If one considers the contrasting interests of multi-national corporations that monetize private data, political activists engaged in direct action opposing government power, and governments interested in controlling and acquiring information, it seems hard to imagine that a consensus will emerge.  An advantage that groups like IETF and W3C have is that within the domain of standards design, it is practical to be anarchic: if one stakeholder disagrees with a technology standard or specification, they can implement their own alternative.  No coercive force commands them to implement a standard, other than its utility or ubiquity.  Regulation, by contrast, can compel conformance to a standard; and thus stakeholders have more invested — if they don’t get their way, they lose.

Another take on this same topic is this blog post from The Office of Urban Computing and Human Ecology, which contrasts Bjarke Ingels inclusive design theory with Tad Hirsch’s contestational design.

Don’t forget your self

In Freedom is an Endless Meeting, Francesca Polletta writes about how community organizers in the IAF in the 1960′s were able to get broad support for common definitions of the problems that communities faced, and what actions the community should take to address them.  Organizers would go door to door, engaging in deep one-on-one interviews, emphasizing each person’s self-interest and needs.  Then, the organizers would consolidate stories, relate them, and build a shared understanding of common problems.

Organizers say that what makes the consensus authentic – what prevents people from kowtowing to their pastors or to organizers – is the emphasis organizers place on self-interest. Self-interest rather than altruism or ideological principle is what motivates people to effective action, organizers maintain. (Freedom is an Endless Meeting, 2002)

The IAF organizers believed that even in a participatory community process, self-interest was the key to effective action.  But the discourse on codesign in seems to have little emphasis on the role of the designer as a self-interested actor. Among the many introductions, handbooks, toolkits and manifestos for participatory design methodologies are arguments and justifications for why participatory design is valuable – generally falling into the broad categories of pragmatic arguments (participatory design strategies lead to more successful results), or normative arguments (participatory design strategies are morally better).[1] But I have yet to find a justification within the PD literature which comments on the role of the designer as an actor with self-interest, emotions, and needs, operating within institutional constraints.

The designers themselves face institutional, social, and personal constraints that influence their work, and might limit their ability to use a participatory method. For example, an academic designer may face academic hurdles such as theses, dissertations, publishing, tenure reviews, and mentorship. An industry designer will have concerns of employment and promotion. Whatever the circumstance, there will be constraints that limit the designer’s capacity to do work within any given methodology. As I read case studies of successes and failures in participatory design practice, I find myself asking repeatedly: who was the designer?  What circumstance of their design practice led to failures in choice and execution of design methodology?

What’s your motivation?

The participatory design literature might benefit from greater reflection on designers’ interests. This is an area where literature and practice of participatory research in the social sciences may be taking the lead over similar research in design. Participatory Action Research (PAR) emphasizes the importance of incorporating the researcher’s self, emotion, and affect into the research process. The aims of PAR are very consonant with the aims of codesign – the main difference is just that PAR comes from the background of social science, rather than design:

Action research aims to solve pertinent problems in a given context through democratic inquiry in which professional researchers collaborate with local stakeholders to seek and enact solutions to problems of major importance to the stakeholders. (Greenwood & Levin, 2000)

However, it’s not always straight forward to integrate such practices with the expectations of academic institutions. Janet Moore writes in Living in the basement of the ivory tower: a graduate student’s perspective of participatory action research within academic institutions:

In a model of true participation, participants have more control over the outcomes and process of the research.

This emerging paradigm of research enables researchers to be engaged in collaborative knowledge production, but it does not fit within traditional academic models for writing, publishing or promotion. Collaborative inquiry challenges academic institutions to create a system that accepts (and even rewards) these alternative processes for research. As a graduate student I am attracted to the often promoted collaborative projects within academia; however, my success within the institution is more often related to my individual endeavours (grades, publications, presentations, etc.) (Janet Moore (2004))

Research is conceived as a process of mutual growth and liberation; but it may not follow the demands of an institution.  This is a positive feature insofar as it enables research trajectories which undermine racism, sexism, imperialism, and class barriers that operate within academic institutions.  But it can also limit the practical ability of researchers to engage in the practice.

Designer as another self

As students in this class embark on participatory design projects, I wonder whether we are being sufficiently mindful of the communities we will be working with, and sufficiently self-reflective about our own motivations and needs. Perhaps, as the organizers of IAF suggested, we should reconsider and reformulate our project plans in the language of self interest.

“A person’s self interest incorporates all of their concerns, values and desires, including the need for self-preservation, creativity, self-definition, power, money, love, and the meaning of life,” Cortes writes…. Common interests and agendas are not assumed; rather, they are arrived at through a process of negotiation. (Polletta, 2002, p183)

The responsible thing to do, it seems, is to share with community partners in any codesign process the details of our own needs and circumstances, including the uncomfortable details of professional constraint that might impact the collaboration, and to work towards a consensus that can meet both community and designer’s needs. To ignore this is to open the door to the moral hazard of an engaging in a research practice which uses the language of participation, but fails to deliver, instead extracting the energy and participation of the community partner for the benefit of academic classwork alone.

So here’s my worry: I’m couching my dissertation work within a nominally trans- or anti-disciplinary (but actually more technology-focused) academic program on a participatory process. What do I do if I find through the participatory process that the most appropriate designs don’t meet the needs of the academic hurdles I face?


[1]: These two broad justifications (pragmatic and normative) parallel the division in justifications used by the OSI and FSF for promoting free software – the OSI argues that open source software leads to better quality (pragmatism); the FSF emphasizes the moral imparative of freedom. Benjamin Mako Hill argues in When Free Software Isn’t Better that the fact that free software projects often fail is a threat to the pragmatic argument.  It would be interesting to pursue a similar line of argument with regard to participatory design. Does the moral imperative justify the methodology, even if the outcome is not always better?