Anyone wandering around the social media scene these days will have seen buzzwords like ‘participatory design’, ‘crowdsourcing’, ‘activity-centred design’, ‘co-design’, and the like. Here’s another: designing in the open (or public: your pick).
Basically, it’s the idea of letting the world see what you’re up to while you design a new app or site. It’s particularly suited to interaction design as you can get a global community of people trying your tests for real (say unlike product design where it’s only an approximation of a 3D product etc). I also like that it has the feel of getting feedback in an organic way, rather than rustling up participants and pushing them through a process. You can design in the open either for a new concept, or a redesign, as I’ll go into below. I’ll then give you some tips as to how to design in the open.
Born in the public eye: designing in the open from scratch
So let’s say you have a great app idea and you decide to put it up online. You might ask: doesn’t that risk someone nicking your ideas, Apple-Xerox ‘open the kimono’ style? Apparently not. In response to a post by Joshua Porter applauding how 37 Signals design in public, Garrett Dimon (the creator of bug and issue tracker Sifter) lists no less than 7 ways that designing in public helped his business:
- Transformed a ‘just for fun’ project into a commercial one
- Marketing was a very convenient side effect
- Sharing and communicating ideas is hard [but you learn]
- Leads to other work
- Teaching and sharing value
(See Porter’s blog entry for a full explanation of the 7 benefits).
The overarching theme is that being prepared to share often has benefits that reach far beyond the product itself. Allowing other people to be involved in your process can help create ‘buzz’,
Letting others help you change: designing with community input
Starting something from scratch is one thing. How about a redesign? If you’re lucky, you already have a number of committed and loyal users that would love to help improve it – in other words, a community. Which is where Mark Boulton – currently heading the drupal.org redesign – suggests the idea of “design by community”:
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.
Drupal is probably a model example of having a community to design with – as a freeware CMS, it attracts progressive web developers who understand that sharing time and resources can help it remain top-quality and free. By engaging with the community (through cardsorts, Twitter feeds and more), Boulton is actively championing their interests and meaning that they should be happy with the result (it’s commonly known that people don’t initially like change, even if it’s for the better – think of Facebook and the Microsoft Ribbon).
Another great example is the redesign of Digg – in his Web Directions South presentation, Creative Director Daniel Burka explains how after having some hits and misses in their initial redesign, they decided to build in a channel of community suggestions and feedback into their second attempt.
Boulton suggests that “design by community” is a more effective alternative to “design by committee”:
Design by committee does not work … 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 …. it will be difficult to reach common ground with a small amount of people.
I don’t think that’s quite correct. Desiging for community is far more grass-roots (I’m not sure how a committee would deal with ‘design by community’) and involves a level of passion and unified vision (for an example of a committee’s differing ideas for a concept, see the parody video “Redesigning the Stop Sign” ). However, trying to turn a committee into a community is maybe something a designer could aspire to with ‘design by community’.
How to design in the open
So, how could you go about designing in public?
Embrace the spirit of collaboration. If you’re going to ask for feedback, make sure you’re prepared to take it on board, even if it may involve a major overhaul of your concept. Even in the worst case scenario where someone points out that someone else has already done what you want to do, wouldn’t you rather find that out now rather than several months down the track? (if you want to see some of the hazards of designing in public, take a look at some of the responses to him posting news on the Planet Drupal forum about tweaking the Drupal logo).
Make it obvious that it’s beta. There’s nothing wrong with rolling something out that’s a bit rough around the edges – in fact, that way people know that it’s not finished and will be happier to give feedback. (Though it should’t crash their CPU!).
Make it easy for people to give feedback. It may sound obvious, but you can’t get feedback if you don’t provide a way to do it. Forums are best as other people can see what’s going on.
Keep communicating. Blog about your progress, set up RSS feeds, send out newsletters at regular intervals. The web world is littered with the corpses of dead projects, and if you disappear off the grid, people will assume that you’ve stopped working on it. If you stay visible, they’ll keep coming back. As Dimon also says, it will force you to get better in explaining what your work is about.
Invite-only is always an option. If you’re a bit queasy about having fully-open design beta, a lot of apps start with an invitation-only model – remember when Gmail was invite only?
If you’re doing a redesign, try to set up a feedback loop if possible. How do you feel when your politicians completely ignore public feedback? Don’t let it look like users’ feedback disappears into a black hole – acknowledge it, and if you have a reason to go against it, explain why. Boulton’s explanation to the Drupal community about the website changes are a great example of this.
Play it forward. If you’re creating free resources (like Drupal or Wikipedia), you’re doing it anyway. If you’re creating something that will eventually be sold, remember to help out other people with their demos (though if they’re any good, you probably want to do it anyway!)
Designing in public takes humility and courage – humility in valuing the input of others, and courage in being prepared to take it right throughout the design process. However, if you are prepared to take it, you can create successful work that you already know makes a lot of people happy. Good luck!