I’ve probably said it before, and will say it again, and I’m also sure that I’m not the first, or the last to make this point, but I have yet to see an example of an open source design process that has worked.
Indeed, I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.
Call me elitist in this one aspect, but with all due respect to code artistes, it’s quite clear whether a function computes or not; the same quantifiable measures simply do not exist for design and that critical lack of objective review means that design is a form of Art, and its execution should be treated as such.
What’s got my panties in a bunch? Well, this screenshot depicts the new WordPress Admin Dashboard coming in the forthcoming release, version 2.4, which you can check out from the WordPress SVN repository. From Mr Mullenweg’s own admission, it’s only about 10-20% complete, but you wouldn’t know that from the feedback this work-in-progress is already generating.
Coming from CivicSpace, where we had a beautiful website before we had working code, to working on Flock, where the mockups never quite matched the software that was released, I feel like I’ve seen enough of these fruitless cycles to take for granted that design and open source development are simply incompatible, or, to be clear: the expectations that one has with open source software development cannot be the same expectations that one has for open source interface/interaction design.
From my experience, what can I say about constructive open source UI/UX design?
- Set expectations. As a designer, I’m trained to take feedback and to accept as given that people will shred my work in the interest of improving it. But I also know that there are plenty of folks who do care but simply don’t know how to provide useful feedback. It’s my job to make it clear what kind of feedback I’m looking for and what feedback I don’t need. It’s also up to me to communicate that I reserve the right to reject any feedback given. It’s up to the feedback-giver to not take it personally.
- Set deadlines. This one follows the previous point, but if you’re doing any kind of design review, it’s pretty important to put some temporal boundaries on how long the window is open to be given feedback and how long it will likely take to implement it. Nothing’s worse than unrequited design feedback, even if it’s feedback that isn’t useful.
- Know where you’re at. My more naive self would rebel against what I’m about to propose, but there’s no way around it. If you’re acting as a designer, it’s up to you to “own” the design process and to only ask for feedback when you’re clear on the kind of feedback you’re looking for. Open source shouldn’t be about ultimate compromise or mamby-pamby democratic ideals where everyone has a say. Curiosity kills plenty of cats, but consensus is goddamn plague on most projects so get it in your head that open source is about public demonstrations of repeated meritocratic value creation and not about listening to every Tom, Dick and Harry that has something to spew. And anyone who hasn’t proven themselves by previously being raked over the coals of public criticism and critique should be treated accordingly. Remember, opinions are like assholes and vegetarians are still in the minority.
- Use productive and appropriate tools. The most aggravating aspect of participating in the Mozilla community has been their reliance on Bugzilla, one of the worst possible tools for design review and discussion. Can you believe that they still do design in ASCII art? Me neither. Look, when you’re doing interactive design, you should try to get as close as possible to the target environment as possible when working and designing. Can you remember the last time you used an application whose interface was made of pipes, ellipses and clever uses of brackets? Neither can I. Therefore interfaces should be presented using tools that support constructive dialogue and feedback. Flickr is actually a great tool for this purpose, with its Notes feature. ConceptShare is another one, developed specifically with this use case in mind. More and more Skitch and Jing are other tools that serve this purpose, as are screen capture applications like iShowU and even Leopard’s built-in Screen Sharing application.
- Be clear about the problem you’re solving. Nothing spells disaster for a design process more than fishtailing. If you don’t know what problems you’re trying to solve and you don’t have razor-sharp focus on it, chances are you’ll be open to whatever feedback you can get your hands on, grasping for some notion of what the hell you should be working on. This is not design, this is horseshoes and hand grenades.
Look, it’s okay to not have everything figured out when you embark on a project, and it’s even okay to admit that and to embrace it. It’s wholly another thing to pretend to know what you’re doing and then go about asking for feedback. By its design and nature feedback is intended to raise deltas between the perceived reality and the potential reality. For feedback to be useful and productive, you, as the designer, have to stayed trained on the ultimate endpoint that you’re driving towards and systematically exhaust all possible combinations presented by the feedback that will lead you to non-ideal solutions. This is how you use feedback to whittle away at an opportunity until you finally arrive at a satisfying outcome.
To put it another way, existential deviation on a theme is certainly okay and to be encouraged; experimentation is where a lot creative ideas will come from. But in the context open source feedback flows, this is absolutely NOT where you want to fluctuate. Trust me, this is where design hijack takes over, and where you’ll lose your control and leverage over the direction of a project. If you hold the reigns tight, an open feedback process can be extremely rewarding; let slip and you’re likely to be overwhelmed in a sea of confusing and confounding false opportunities.
- Be focused. This tip is twofold and builds on the last. You should be focused on the feedback you need, and rather than going for blanket advice, narrow in on specific user flows or tasks. On top of that, the less certain you are about the approach you want to take or about the appropriate solution to pursue, the smaller the pool of respondents you should consult should be. This is what I mean by “be focused”: the more uncertainly in the project, the fewer external voices you should consult, especially en masse; the further along in the project you are, and the more certainty you have, the more you can open it up for general feedback. Note too that people will bring their own preferences, assumptions and beliefs with them, so choose your early critics wisely.
- Care deeply and sacrifice nothing. This one’s probably the hardest of all, and really can only be learned/earned over time. The role of the designer is, against all odds, to synthesize and to make sense of ambiguous circumstances, poor or changing problem descriptions, to weigh the individual needs of project sponsors, of product users, or subjective tastes and of sating the hunger of one’s own ego to produce something better than you thought yourself capable of. And it’s nearly impossible to fake it. But the best approach seems to be to do your homework and care deeply about the work that you’re doing and to identify with the problem that you’re trying to solve. Sacrifice nothing in the way of arriving at a solution that meets your highest personal criteria. It helps when you’re your own worst (best) critic, but it’s all the more essential when you’re putting yourself out there for public scrutiny. If you know that you’re not going to let yourself get away with anything, you should be able to face whatever slings and arrows the outside world will heave your way, all as part of.
And so we return to the case of the WordPress 2.4 Admin Dashboard. It’s unclear who owns this project or the feedback coming in (I don’t remember seeing a public call for comments, so this must just be unsolicited feedback), but I sure as heck hope that whoever it is takes this current round of feedback with less than a grain of salt. As far as I’m concerned (and as much as I’d like to affect the design process myself) WordPress deserves more time to make its case for the new design, and to implement closer to 70-80% of the design before people start pontificating about how things should be different (or remain the same) (not like any such plea will stem the onslaught).
With open source development, the cat is always out of the bag. As such, it keeps you honest and focused on issues that people care about, even if they’re occasionally peripheral to the main issues you set out to solve.
So the problem with open source design is not the feedback (designers et al should be grateful when it comes) but with the ego issues that are wrapped up in how feedback is delivered and how it’s received. And these are ultimately social issues. The points I outlined above have as much to do with clear communication, acknowledgement and a Buddhist-esque equanimity as with any kind of formal design training. If open source design is to advance, and to become a dominant force in the creation of exquisite software experiences and interfaces, I say we start here.
Factory Joe 
Some of the best software I’ve used often comes from a single individual’s vision. In open source, with distributed development, a single vision can be difficult to achieve. Quite often nobody really “owns” the look and feel and consequently things tend to develop into a hodge podge of different standards. Open source software is also often cross platform which makes the problem even more difficult.
Happy Cog seems to be in charge of this undertaking and I don’t know if any of them have worked on applicaiton UI ever. They are a great micro site company where there are only a couple of pages. I don’t think any of them understand application flow, but they might not be doing that. This is only 10%, I will hold judgment until it is 80%.
Just a quick follow up on the WP stuff: Matt chimed in with what I think is the right decision today:
http://comox.textdrive.com/pipermail/wp-hackers/2008-January/016993.html
excellent post.
A wonderful and thoughtful post. BTW, I’d hanker that Happy Cog does indeed know alot about functional design. It’s hard designing any interface that is used by thousands or even millions of users and a singular vision that can drive and motivate design is important (and it doesn’t need to be absolute). When I look at what it perhaps the pinnacle of design practice that community-based development can draw inspriation from I always come back to film-making. The director ‘owns’ the vision but the final output is always a collaborative effort.
Chris Bernard,
User Experience Evangelist, Microsoft
@Brian We do indeed have experience in app UI, it’s just not what we do most of these days.
Nice post, Chris. Like everyone has been saying, we’re only seeing a fraction of what this will look like, and more importantly, function like. There’s little point in commenting too much about it yet, because we’d be commenting on an unfinished application. I can however say that we did a lot of work on the planning and research end of things in tandem with interviewing many WP users. Some things are definitely going to change, and like any change, it’s going to take some time for people to accept it.
Open Source is more than a group of people working together towards a singular product. The term refers to any production made with “open” and free (libre) access to the code/source.
You seem to be talking more specifically about community, or democratic design. Where-in a group of contributors work towards a singular goal/product. Which has rarely been very awe-inspiring in Architecture (my field) or community planning, for sure, and probably won’t get much better in graphic or interface design.
What you describe does use open source, allowing everybody access to how the design is made, however its only an application of open source, for the purpose of collaborative design.
Open Source (open access to code) can result in infinite iterations, from which excellent or terrible productions can be gleaned.