design is no place for democracy (things we learned from the drupal.org project)

Continuing in the series of ‘Things we learned from the Drupal.org project‘, this post actually starts off in the comments of the last post (design by committee vs design by community) where Keith picked me up on the statement that design should never be democratic and asked ‘Could it be? Or at least closer? And how to do that?’

Ah, democracy. It is a beautiful theory, but only – as with so many things – when applied correctly. Democracy may be great for deciding on a government, it may be great for Pop Idol (hrm..?) there may be other places it is great and noble… but design just isn’t one of those places.

When designing with a community what you should be aiming for is participation not democracy. Make your design process as open as possible, but don’t be fooled into thinking that because people ‘voted’ for a particular design, that is is the best decision, or even a good one. It’s probably not.

There are two key reasons that I believe this to be true:

  1. Good user experience is hard to evaluate when not in use – when you give people a screengrab or even a prototype to evaluate, people will tend look at things from a visual design perspective (highly subjective), and often a ‘heuristic’ perspective (usability conventions, best practice, what ‘users’ do and like etc.).These perspectives are valid and interesting, up to a point – but they come nowhere near being as valuable as the observation of a designer, or actually observing someone performing tasks that they would do every day using your design and seeing how it works for them. I’d give that trumps over popular opinion any day.By putting a design out there and asking people for their feedback, you are actually giving them a really difficult task. It’s hard enough for those of us who do it professionally (and there’s plenty of research to show that our opinions can vary wildly) – it’s not really fair to expect your community to be able to make a good decision about whether or not a design will work well based on just taking a look or clicking through a prototype.
  2. Your community are domain experts, not design experts – the best thing your community can do for you is tell you what you need to know in order to design well for them. Most of the time, they are not designers. They don’t have design training. Why are we asking them to do design work?If I could find my copy of Bill Buxton’s Sketching User Experience (which I have conveniently misplaced on the day of London UX Bookclub, d’oh!) I’d find the part in it where he talks about how ‘reading’ design, interpreting sketches, is actually as much of a design skill as doing the design in the first place – it’s just one we don’t talk about and don’t place any value on. Part of the reason designers often snort at the feedback given to them by clients (or community members) is because of a lack of design literacy in their feedback. Well, of course. They’re not designers.

Your mission when designing with community is to facilitate the community to make good design decisions by working with the information and insight they provide to give them good design and help them understand the design strategy and how and why it works.

Giving the community a true and meaningful voice in the design process is so much more empowering and respectful of them than letting them vote for which design they like the best. Letting a community choose a design by popular vote is, in my opinion, relinquishing your responsibilities as designer.

Help make Drupal7 amazing – what we’re doing at Drupalcon

You may have heard the excellent and very exciting news that following on from our work on Drupal.org, Mark Boulton Design has been contracted to take a look at the User Experience for the upcoming Drupal 7, and I’m very happy to be working with him on this project as well.

Our last project, Drupal.org, kicked off at the Drupalcon in Szeged which was a fantastic way to begin the process of immersing ourselves in and communicating with the amazing Drupal community. Happily, this project will also kick off at a Drupalcon, this time in Washington DC and starting next week – if you’re going to be there we would love to meet you and I thought you might like to know of two of the activities we plan to kick of whilst at the conference.

1. Blue Sky Design Workshops

We’re going to be running 3 workshops during the conference that we’d love you to participate in, they’re going to be held on Wednesday 3-4pm, and Thursday 9-10am and 11.30-12.30pm.

We’re calling them ‘design’ workshops, but that doesn’t mean they’re meant for designers only. These workshops are made up of a few fun activities that will help us explore the boundaries of what Drupal 7 could be. We want people from all different backgrounds and areas of expertise, and all levels of experience with Drupal – the only thing you need to be passionate about Drupal and the desire to see the next version of Drupal have an amazing User Experience to come along.

If you’re interested in participating, signup for one of the workshops using one of the links below:

Wednesday 3-4pm
Thursday 9-10am
Thursday 11.30-12.30pm

There’s only space for 10 people per workshop, so get in quick!

(If you do try to register and all the workshops are booked out, there’s a waiting list here. Yes, we’re optimistic!)

2. Pimp My Admin

The second activity we’re launching at Drupalcon is a little activity we’re code-naming ‘Pimp My Admin’. This is how it works…

One of the great things about Drupal is that you can bend it to your will – get it to do just about anything you need it to do. Same goes for it’s administration interface (admin).

Before we get to redesigning the Drupal7 Admin, we’d love to see what you out there have done to make the Drupal Admin System do what you need it to do, or just to work better for you and your project.

Here’s how we want to do it – simply take a little screencast, see if you can make it shorter than five minutes – walk us through your admin system and show us what you’ve done, even if it’s just something tiny – to make Drupal work better for you. Then you can either send it to us or, better still, post it up to YouTube – we’re still working out the details of exactly how to share these screencasts, but stay tuned for details. Meanwhile, if you’re going to be at Drupalcon, come find us and we’d be more than happy to sit down and do a screencast with you!

Come find us!

Even if you’re not interested in either of those activities, if you’re at Drupalcon and you’re interested in the redesign, please do come and say hello. We’re hoping to be very conspicuous and easy to find and we’ll have our suggestion box out and our ears reading for bending. We’re looking forward to meeting you and learning lots!


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!