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!

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!

Progress continues apace on the Drupal.org redesign project – thanks to lots of help from you, we have now moved into the rapid prototyping phase.

In the spirit of this open redesign process, you’re more than welcome to take a look at the prototype as it evolves from its current, very sketchy state to … well, whatever it becomes. Hopefully a great home for the Drupal.org community and their product!

Now, be warned – it’s not pretty and it is far from complete. There are some things we kind of like and plenty we think may be a little dodgy, and some stuff that is just holding a place until we have more time to think on it (or to generate a little feedback in the meanwhile). The visual design (colours, fonts, etc.) of the prototype bears not resemblance to what we imagine the finished Drupal.org website will look like. Some of the content we kind of like, a lot of it is just holding text. It is very much a work in progress!

It’s really all about what’s on the page and what it’s called – lots of information architecture to look at really!

Anyway – enough with the disclaimers – why don’t you go take a look for yourself and, if you’re so inclined, leave any feedback or questions you have in the comments here and it will go into the mix for the next iteration. I’ll let you know when the next version is up for you to take a look, and we’ll continue like that for the next few weeks at least, as we gradually build in all the content and functionality and fine tune the content and interaction.

Drupal.org Prototype Development – Iteration 2

There is a design game that I like to play when I’m working face to face with my client (and when there aren’t thousands of stakeholders!) which involves everyone on the project sitting down together and individually sketching up some wireframes that then get shared back into the group.

Aside from being good fun, it is also a really great way to uncover good ideas, common themes, and a whole raft of information and assumptions that haven’t yet surfaced in the project but that are important to us getting the design and information architecture right.

I don’t see why we should let our ‘virtual workspace’ stop us from playing this game, so, let’s do it. Let’s do some wireframing together!

Here’s what I want you to do:

1. pick a page on Drupal.org – it could be the homepage, it could be your profile page, it could be a project page, it could be a page that doesn’t exist that you think *should* exist – just pick one that is important to you.
2. have a go at sketching out what you think might go on that page. What are the content and functional elements, and which ones are the most important.
3. post the page somewhere – if you’re using Flickr, you can post it to our Flickr Group, or perhaps you want to post it on your blog and put a link to your post in the comments here, or you can email it to me if you like and I’ll post it – whatever you prefer. You might want to add some notes as to why you’ve approached the page the way that you have or, if you’re like me, to decipher your handwriting.

You can use whatever you like to wireframe – I tend to use pen and paper to start with or sticky notes. Then I’ll use Omnigraffle a little later. You might prefer to sketch in code. Whatever works for you. As you can see from the example I’ve posted above, early wireframes are usually pretty rough (mine disintegrated into a list at the bottom!) and not so pretty. This is fine. It’s not about how they look or even whether they’re right. It’s about getting ideas down on paper – to paraphrase the old saying – a wireframe is worth a thousand words.

Don’t spend too long on it – try to spend no more than a few minutes on a wireframe. If you’re not happy with it (and you probably won’t be at first!) just put it to one side and start fresh. You don’t want to labour over them too much at this stage.

Don’t think you have to be a designer or a UX person to participate in this exercise – this is all hands on deck. Even if you’re not an experienced Drupal user and you were flummoxed by your experience of Drupal.org – what did you *want* to find on the homepage?

I know there have been lots of discussions over the years about various parts of Drupal.org – let’s roll up our sleeves and get stuck in! Yay!