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.

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 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?

Benjamin Mako Hill has tried to get more rigorous, at least from the retrospective perspective.  He did a fascinating presentation at the Berkman Center last year (well worth an hour to watch it) on eight “almost wikipedias”, in which he asks the question: why did Wikipedia succeed, in ways that the other collaborative encyclopedias that were started at roughly the same time as Wikipedia did not? Through qualitative and quantitative analysis, Hill identifies four principles that he believes led to Wikipedia’s relative success:

P1: Contributors struggled with goals that diverged even slightly from tradition.

When an encyclopedia wasn’t a plain-old Brittanica-style effort, people had trouble figuring out exactly what to do with it.  The project needed to fit within existing conceptual frames.

P2: Substantive focus on content, not technology.

Whereas some other projects focused on building the best tool, Wikipedia took pre-existing wiki software, and focused on writing articles.

P3: [The wiki model] lowered transaction costs.

Some early encyclopedias required editing HTML, which was too difficult; or requiring confirmation as an approved editor, which was too high a barrier.

P4: Wikipedia succeeded because it “hid” authorship from editors.

To the extent that these principles are explanatory for the relative success of Wikipedia, the next obvious question is: how repeatable is this?  Do the principles say anything about other design efforts – could they be predictive?  For an early encyclopedia project this would be tricky: the delicate balance between a focus on content over technology versus a tech-enabled reduction in transaction costs is one of the major difficulties in establishing a design.  And who could have predicted the aggregate effects of hiding authorship?  We could easily imagine an alternate universe in which P4 read “preserve authorship by rewarding participation with attribution, to motivate participation.”

Consensus Project: possible failures

With that in mind, here are the results of the  5 minute brainstorm on post-its for the consensus project.  We grouped the results roughly into the following categories:

• Digital Divide
• Scope
• Framing
• Codesign
• Tech
• General

To some extent, these possible failures are highly consonant with the general palette of design anxieties that I already have going into a project like this.  As is to be expected in a 5-minute brainstorm, some of the points raised aren’t too useful (some “General” failures amount to little more than “it doesn’t work”; some of the “Tech” failures amount to “you wrote shitty code”).

Getting beyond the “you didn’t do quality work” level fails, I think the the 5 themes that seemed most worth digging in are: digital divide, scope, framing, prior art, and codesign.  To address this, we’ve taken each category and the spread of possible failures in them, and tried to pull out a few actionable principles to consider in design which, if fulfilled properly, might guard against those failures.  We can come back to these principles periodically during the design process in order to check whether we might be headed down a dangerous path.  This by no means assures success; but it at least allows us to check whether designs end up matching our prior intuitions.

Digital Divide

The digital divide question for our project is one of the more central to its design.  At its root, our goal is to improve the way groups can use consensus processes.  But if a group adopts a tool which structurally excludes some members of the group, this is a huge fail.  The other side of the coin is that digital technology could enable more participation – limiting consensus process to in-person meetings can structurally exclude people who don’t have the time or money to travel to a meeting.

The more insidious difficulty is if a tool is unevenly adopted: a tech-savvy subset of a community begins to use it heavily, and thus structurally excludes just one set of participants.

Some principles to address these concerns:

• Using the tools, participation should increase or remain constant.
• Levels of participation should be visible to users of the tools. Participants should notice if some members of their community are not using it.
• Control of the tools should be accessible to all participants, regardless of their degree of technical sophistication.

Scope

Scope questions are hard.  Is it better to build something that is highly suited to a particular purpose, or something that is more general?  Software developers are frequently warned against “premature generalization”; at the same time, inadequate generalization leads to lower utility and adaptability.

• Don’t be an island: The tool should integrate with existing systems.
• Don’t build facebook: The tool should not attempt to replace any existing functionality, without a very good reason for doing so.
• Don’t be everything to everyone.  If the needs of different potential users are too different to reconcile, pick one.  Do one thing well rather than many things poorly.

Framing

The framing failures are related to scope failures, but focus more on the problem statement than the proposed solution.  The existence of such a large number of tools for online democratic decision making – most of which have failed to gain traction and user acceptance – certainly gives me pause: Is this actually something there is a need for?  To this, I think the best we can do is to pull a principle from Mako’s analysis of the eight almost Wikipedias:

• Ground the design in existing practice.  Preference what people actually do (and how they think about what they actually do) over what we might imagine is better.

For consensus design, this means looking at how people actually use consensus – including all the emotional and non-verbal communication, group understanding, tense arguments, structured facilitation, and education.  We can’t just pick some component out like a voting mechanic and expect it to function as the whole.

Prior art

While this category only captured a couple of notes, I felt that it was worth highlighting carefully.  In addition to the existing tools for democratic deliberation, there are already very sophisticated tools for general online communication and collaboration (etherpads, google docs, mailing lists, facebook, twitter, etc).  Are we building something worthwhile?

The principles we might come up with here are fairly similar to the scope principles.  I’ll reiterate with this one:

• Develop a theory for why something failed, and address the reasons, before building something similar.

Codesign

In some sense, the failures listed here are similar to some of the Tech failures that amount to “don’t do crappy work”, but there are some more specific points worth considering.  The biggest is that this project lacks a singular, specific community partner for its duration; rather, there are a larger number of more diffuse participants with less individual involvement.  I think this principle captures the worry:

• Don’t build anything without a clear target user, who is participating in the design.

Conclusion

So in the end, we have 9 actionable principles that we might consider as “ways to avoid failure”, or at least, ways we imagine right now that we might avoid the failures we can imagine right now.

• Using the tools, participation should increase or remain constant.
• Levels of participation should be visible to users of the tools. Participants should notice if some members of their community are not using it.
• Control of the tools should be accessible to all participants, regardless of their degree of technical sophistication.
• Don’t be an island: The tool should integrate with existing systems.
• Don’t build facebook: The tool should not attempt to replace any existing functionality, without a very good reason for doing so.
• Don’t be everything to everyone.  If the needs of different potential users are too different to reconcile, pick one.  Do one thing well rather than many things poorly.
  
• Ground the design in existing practice.  Preference what people actually do (and how they think about what they actually do) over what we might imagine is better.
  
• Develop a theory for why something failed, and address the reasons, before building something similar.
• Don’t build anything without a clear target user, who is participating in the design.

I think a next step for us might be vetting these principles with our community partners, and modifying them or crafting new ones accordingly.

Here’s a writeup of the first design workshop for the consensus project, which we ran last Saturday.  Many thanks to all who participated.

• 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.

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.

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?