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

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!

Drupal.org redesign – help usability test Iteration 6 next week!

As you may have read, we’ll be doing some usability testing on the 6th iteration of the Drupal.org prototype in London next week. It seems like a great time to also kick off some crowdsourced usability testing, as we’d talked about earlier, and for any of you who’d like to get involved to do so!

(UPDATED!) Iteration six is now live here. I’d like to encourage you to take part in our Crowdsourced Usability Testing Campaign by doing a few tests yourself, wherever you are in the world, and contributing your findings back to the project.

Here’s what you need to do:

  1. Find some participants to take part – we want a mix of people along the spectrum of Drupal involvement from those who don’t know much to those who know lots and are super involved. Some tips for recruiting can be found here (feel free to add any other tips you have to our wiki!)
  2. Take a look at the prototype and work out how you’re going to approach the interview – some interview tips and a sample script can be found here (again, feel free to add more!)
  3. Work out a way to record your interview – some ideas here. Personally, I’ve found remote testing more hassle than it’s worth and much prefer to do in person interviewing. My technology of choice is a MacBook with Silverback installed for audio and video recording (you can get a 30 day trial for free). 
  4. Do your interviews!
  5. Share your interviews and findings! I’ve been exporting and posting some interviews on Vimeo, which is my preferred video sharing site. You can put yours wherever you like, just link to them from the comments of this post once they’re posted (and/or add them to the wiki where mine are now) – if you have some time to write up what you’ve learned as a result of the testing that would be fantastic! (If not, don’t worry, we’ll take a look through the video ourselves!)

That’s it! Not so hard at all, is it!

If you have any questions at all, post them here (no matter how silly they may sound, chances are others have exactly the same question or it’s something I forgot to cover in this post or on the wiki!) – I or someone else helpful will get back to you ASAP.

This is a great opportunity to help out with the Drupal project and a great chance to get some usability testing experience under your belt – which is a really fantastic skill to have, whatever aspect of design or development you’re most into. I really encourage you to give it a try and look forward to seeing what you come up with! I’ll be sharing my videos as soon as I can export them after usability testing sessions on Monday 3/11

If you’re able to do some testing early next week and post your feedback mid-late next week that would be fantastic. If this schedule doesn’t work for you – don’t fret – more iterations are coming hot on the heels of this one and more testing will be required and welcomed! You can get involved in the next few weeks if that suits you better.

Good luck, thank you and yay!

Drupal.org – Crowdsourcing Usability Testing – Get Involved!

Another day, another way to be involved in the Drupal.org redesign project, and this one’s a little different – but I think it’s going to be great fun!

Here’s what we’re going to do.

I’m going to be doing some remote usability testing using screen sharing and screen recording software that I’ll share back with all of you and that will help guide the ongoing design of the prototype. In particular, I’m going to be doing research with ‘outsiders’.

If you have either experience or interest in helping in this research effort, then I invite you to help test the prototype, either by doing more online remote research, or – even better – by doing some ‘in person’ research with people near you – especially people who are Drupal insiders.

We can then all post the videos of our research together with our findings and recommendations in a central location, building an amazing resource to document the progress of the prototype and what has guided the decision making as it is designed.

We’ll be asking people to help out with testing for each iteration as it is released, so if you’re too busy (or nervous) now, then never fear, opportunities abound. In fact, there’s no reason why this should stop just because the redesign team are off the case.

This is a little more complicated than our original crowdsourcing effort (wireframing), so I’ve quickly thrown together the skeleton of a wiki where we can pull together a toolkit of need to know information for this project – technology to use, how to interview, how to analyse results, that kind of thing. If you have expertise in this area, please feel free to pitch in a few recommendations.

You can find the Crowd Sourcing Research Wiki here. (Be warned, it’s pretty ugly, but I’m too excited about this to spend time making it look pretty – anyone who wants to do so is more than welcome).

So, consider yourself invited. If you’d like to be involved in helping test the prototype then please get involved. If you’ve wanted to try your hand at usability testing but have never had the opportunity, here it is. Exciting, huh? :)

Why I care what you had for lunch

There is an excellent article, I’m So Totally, Digitally, Close To You, about ambient intimacy in the New York Times Magazine this weekend, and I’m honoured to have been able to contribute a few words via a fascinating chat with the author, Clive Thompson. (This is the second time I’ve gotten my name mentioned in the NYT can you believe! but this is the first time they’ve spelt it correctly).

Unsurprisingly, the comments to this article are scattered with the standard ‘who cares what you had for lunch’, ‘you guys are way too into yourselves’ and ‘you don’t pay enough attention to real life’ type responses. All of which, in their own way, are quite understandable and some of them (particularly the ‘you don’t pay proper attention to your real life’ can often be all too true).

I’ve been thinking quite a bit about why I think these ‘lunch’ type tweets are important. I’ve decided there are at least three reasons why I care what you had for lunch.

They are:

  1. I see your Tweet in my Twitter stream and I think of you. It keeps you present in my life. I like that.
  2. I feel like I’m more present in your life because I know more about the small details – like what you had for lunch – that I wouldn’t know if you didn’t share it with me. It makes me feel closer to you.
  3. I learn more about you (if I didn’t know you well before we started trading Tweets). Perhaps I learn that you’re a vegetarian, or I learn which restaurants are your favourites. I get to know you more.

Twitter means that I stay in a constant state of connectedness with you, in a constant handshake, constantly doing small talk… and this is actually incredibly valuable to me for reasons that go *way* beyond touchy feely.

How so?

Well, I am in the fortunate situation of being connected to quite a few very clever people on Twitter, and by staying in this perpetual handshake with them, it means that when I *need* something from them, I’m able to put out the question without having to do that small talk dance that we usually need to do.

You know when you need to ask for a favour? First you need to identify the right person to ask, then contact them, do some polite small talk and catching up, then finally, to the favour, which they may or may not be able to help you with.

Compare to Twitter – I have a question/problem I need solved – I put it out to my Twitter network, and – often within moments – I have answers, problems solved.

Similarly, I’ll answer questions and hopefully help solve problems for others as well.

Despite the fact that I’m listening (reading, really) what you and many others had for lunch, Twitter is still an incredibly efficient way to problem solve, it’s a remarkably rapid and rich resource. Far beyond anything I’ve experienced in the past. For example, as a freelancer, Twitter is now my IT help desk, and I’ve never had one better.

I do love the touchy feely ‘friendship’ side of Twitter – the ‘intimacy’ aspect is very valuable to me (although I do also love seeing my friends in real life whenever it is possible!), but the thing that continues to make my jaw drop with Twitter is the access that I have to distributed expertise and opinion. I use it regularly in my personal and professional life now and hope never to be without it.

Meanwhile. I’m off to have dinner. We’re having pizza tonight ;)