One of the interesting challenges of the redesign process for Drupal.org is managing the expectations of a community of over 200,000 registered users. Not only that, but a community of largely open source developers. I mention that specifically because of the culture that surrounds open source development. Leisa and I have been trying something that is, frankly, terrifying. We’re designing in the open.
When I graduated from university, I was asked to go before a panel of moderators and examiners three times to justify my work. For best part of an hour I argued, listened, seethed and nearly cried as my work was verbally torn apart by a committee of ‘learned’ professionals. On my way out of the room, utterly devastated by what just happened, my lecturer in typography took me to one side and said some words I’ll never forget: ‘Mark, a camel is a horse designed by committee.’ ‘Take what you can, and learn. But ultimately, stick to your guns and believe in yourself.’
He was of course implying that design by committee never works and nearly always results in a poor product. The egotistical designer in me agrees. However, the more pragmatic side of me disagrees. Maybe design by committee doesn’t work, but design by community could.
Asking the community for help
Leisa has been doing a fantastic job recently of opening up her process, thoughts and ideas with regards to the Drupal.org redesign. So far, we’ve had the following gems:
- Drupal.org - Help Overhaul the Information Architecture - participate in our online card sort!
- Drupal.org - One site or many?
- Drupal.org - come wireframe with me!
- Outsiders and Insiders - Understanding Drupal.org users
- DRAFT: Drupal.org Experience Strategy
- User research for Drupal.org redesign - what we’ve done, what we’re doing
By and large the community has responded well, offering valuable insight into some thorny issues. I thought this was something I could do with some of the branding work we’ve been doing.
Now, it may be the subject matter, or my phrasing. Perhaps it was too early in a process. But as you can probably see by the comments, it didn’t go so well. Actually, saying that, I think it did go well up to the point where the comments took a personal turn for the worse. I was talking with Leisa this morning, and we both agreed that it would be interesting to analyse the differences, and the huge difference in the tone of the comments provided.
Brave, Stupid, or Inspired?
This comes back to one of the initial points I made. Design by committee does not work. Why is that? Personally, I think it’s due to the relatively small size of a ‘committee’. Say you have a client, and there are 15 stakeholders. All of them have strong opinions, there are big egos flying around. In fact, I had a client like this a short while ago, and it was a prime example of how working in this environment does not work.
Generally, in that group, there will be one or two loud voices. Maybe an Alpha Male or two. The important thing to note is that this is a small group. It will be difficult to reach common ground with a small amount of people.
Designing by community I feel is different. There are a lot of people in the Drupal community. Many hundreds with a strong voice. Providing very early releases--in fact, opening up the process completely--draws reaction. Within that reaction, if there is enough of it, we can identify trends. And I think trends in feedback is the key to Designing By Community.
Leisa and I will continue to work as openly as we feel appropriate for the project. If it falls flat on its arse in the near future, well it will make a bloody good case study.