design by committee vs design by community (things we learned from the Drupal.org project)

Posted on by Leisa Reichelt

Recently I presented a casestudy of things that we learned about designing with a community, the Drupal community, at the Interaction09 Conference in Vancouver. (I’m still trying to get my slides down to a reasonable size to post on Slideshare!) It was a short presentation so I thought I’d take some time to flesh out some of the ‘things we learned’ here for anyone who is interested. It certainly was an interesting, challenging and fairly unique project, and we’ll be doing more like this in the future, perhaps you will be too! This is the first post in a series of our learnings.

Often when I talk to other designers about the Drupal.org redesign project they can’t stop themselves from shuddering at the thought of having so many people involved in their design process.

It’s an understandable reaction – after all, how many of us have suffered design by committee, which is really it’s own special circle of hell, in which a group of somewhere between 3-12 (usually) stakeholders with various levels of authority (actual or effective) provide copious and detailed feedback to your designs – feedback that often conflicts either with itself, or with the objectives of the project, or just with the principles of good design. Usually these people are the people who are responsible for paying your salary or invoice. They can’t be ignored. As Whitney Hess tweeted and then blogged, they have itches that need to be scratched.

So, it seems logical that having thousands of people involved in the design process should be even worse right? Design by committee on steroids? Well, you might think so but, happily, you’d be wrong. It’s really a whole different beast with it’s own challenges and opportunities and – I’m happy to report – there is much more good than bad about design by community and it’s an approach that I’d encourage you to consider. (Unlike design by committee, which should be avoided at all costs.)

The main reason for the different experience is scale. Surprisingly, scale is your friend.

When you’re dealing with feedback from hundreds of people you don’t need to address every single issue raised. You’d be mad if you did and have no time for getting the design work done. Rather, what you’re looking for three things:

  1. emergent trends: what are the issues that multiple people are mentioning or agreeing/disagreeing with. If half a dozen people mention it, it’s probably worth looking at.
  2. unexpected comments: every now and then you’ll see something that takes you by surprise. (This doesn’t include comments like ‘your design sucks’ which you will get no matter how wonderful your design is – you have to learn to not be surprised by these!). When you get that ‘surprise’ feeling (you know the one) – pay attention, even if just one person mentions it.
  3. obvious pickups: – with a few thousand fresh sets of eyes, obvious mistakes, things you’ve just left off or misspelled for example, will get picked up quickly. Acknowledge those as quickly as you can so that they don’t turn into big (and often dramatic) conversations.

The absolute best way to a respond to an issue is in your design, rather than in responding to comments on a blog, messageboard, flickr posting, tweet or wherever you’re gathering your feedback (and I’d encourage you to keep it fairly messy and don’t just do it in one place – more on that in a later post!). You should stay in touch with the conversation and respond when appropriate (again, that’s a whole other post!), but the ratio of your responses to comments should be at least 1:10, if not closer to 1:50

This is quite a departure for most of us who are used to consolidated feedback lists and having to respond to every piece of feedback we receive, to begin with it almost feels a little naughty (at least, it did for me!) – but it is a really necessary approach if you want to maintain your integrity and not reliquish your responsibilities as the designer.

Remember – just because you’re working with a community doesn’t make this a democratic process. Design should never be democratic. We’re not voting on interface elements here, we’re working with a community to let them help us the best way they can – by telling us about their community and their product, in this case the drupal.org website and what they use it for, and drupal itself of course. Communities aren’t designers – they can give you a lot of GREAT information to help you design well for them, but that’s the crux of the issue – you need to find ways to work with them so you can get from them what they do and know best, and so you can do what you do best – design great experiences.

A big part of your role on a project like this is facilitation and communication, but don’t let those roles waylay you from your most important responsibility, which is to do good design.

It’s a terrifying but exhilarating experience, this community design caper. If you have an appropriate project, I’d really encourage you to give it a try. I’ll be sharing more of what we learned soon!

16 thoughts on “design by committee vs design by community (things we learned from the Drupal.org project)”

  1. Very interesting approach and article :)

    Would love to see some more about how you presented work and how you facilitated feedback.

    User input and feed back rocks :D

  2. Hi Leisa, I’m interested in your statement “Design should never be democratic.”

    Could it be? Or at least closer? And how to do that?

    What about presenting multiple versions of design, and going with the most popular one/s, and iterating. Could that work? Are there other approaches?

  3. hi Keith, you can definitely be democratic if you want to, but in my experience, it’s not a recipe for good design. Inclusive design is good – including people in the design process, listening to them and showing them how you’ve incorporated their needs/wishes etc. into the design.

    I tend to think that the idea of democratic design is not a good one – I’ll write more about this soon, but it is actually really difficult to judge whether a design is good or not just by looking at it – the most popular design is more than often not going to be the design that actually works best for the people who will use it in the future. As designers, we are better at evaluating this, and we should help ensure that the best decisions, not the most popular ones, are made.

    that’s what I’m thinking anyways – would be interested in other perspectives :)

  4. As an example, Mozilla is keen to bring the community into design much earlier on.
    http://www.azarask.in/blog/post/new-ubiquity-logo-semi-final-round/

    One problem I see with this is that design gets defined by the community that responds (which may not be all the geeks) and might not match your real user base. However, it seems a valid thing to do, and I would love to hear any other innovative ideas you might have on how to better incorporate the community into design.

  9. I think part of what made/makes “design by community/crowdsource” so compelling is that it doesn’t separate stakeholders from users. In traditional design you have the designer, a small number of expert stakeholders, maybe a focus group or two to represent users, and then a big amorphous blob of users you don’t talk to directly.

    With a community/crowdsourced approach, the stakeholders, focus group, and users all collapse into one group. That removes layers of indirection and gives the designer direct access to the full user base, or at least the vocal parts of it. :-)

  10. thanks very much for sharing this leisa, having watched the process from the out I was wondering how it was feeling on the inside. interestingly the process you describe sounded similar to me to analysing user research generally i.e looking for themes, gems that stick out, and at first feeling a little naughty for not taking it all on or responding to all bits :) – the similarity makes sense too given Larry’s comment above
    thanks again
    penny

  13. Bit late on from the original post, apologies, but following the Drupal.org process has been a massive help in my developing career. If there’s any way to learn how to begin to approach a community project without the overhead of that process yourself, this is surely one of the best examples out there – transparent and communicative throughout and it’s moved my (and the agency that I work for!) forward in our thinking. Really appreciate it Leisa and Mark B.

    K

  16. Design by committee and democratic design is no way to get a project where it needs to be. You need to know when to respectfully decline. Design by community however is an entirely different thing. In some form you do this all the time. I love the article thanks!

Comments are closed.