Menu Search
Jump to the content X X
Smashing Conf San Francisco

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

The Case For Open-Source Design: Can Design By Committee Work?

In celebrating the merits of free software and the excitement over this radical networked production method, an important truth is left unspoken. Networked collaboration shines in the low levels of network protocols, server software and memory allocation, but user interface has consistently been a point of failure. How come the networked collaboration that transformed code production and encyclopedia-writing fails to translate to graphic and interface design?

The following is an investigation into the difficulties of extending the open-source collaboration model from coding to its next logical step: interface design. While we’ll dive deep into the practical difference between these two professional fields, the article might also serve as a note of caution to think before rushing to declare the rise of “open-source architecture,” “open-source university,” “open-source democracy” and so on.


The Challenges Link

Scratching an Itch Link

By going open-source, coders are fulfilling a need to change software, to make it their own. They might have different motivations, but if you’re already modifying something for yourself, answering the “Why share?” question is really easy with “Why not?” By the time the code executes correctly, the immediate users of the software—that is, the coders themselves—are already familiar with the software and can operate it even without a delicately crafted user interface.

Therefore, the motivation to take an extra step and invest in a usable interface that would extend the user base beyond the original geek-pool is not obvious. The interface already works for me, so what itch am I scratching by working hard to make it usable for others who can’t help me code it?

For the designers themselves, what is their incentive to make the design process more collaborative? Will others make my design better? Will they be able to communicate my ideas better than I can?

Beyond that, open-source interface design suffers from a chicken-and-egg problem: most designers don’t use open-source tools, and so it doesn’t occur to them that they could make the software better. As a result, open-source software suffers from an inferior interface that makes designers shy away from it and stick to their proprietary tools. The cycle repeats…

Granularity Link

Both software and wikis are made of granular building blocks, namely characters. This makes every typo an invitation to collaborate. My first Wikipedia edit was a typo correction, my second was adding a reference link, my third was writing a whole paragraph, and that led me to more substantial contributions, like adding a whole new article and so on.

Each granular step gets you closer to the next granular step. This ladder of participation makes each successive step easier. It also allows you to compare changes easily, giving you transparency, accountability, moderation and an open license to try and possibly fail, knowing you can always revert to the previous version.

You don’t get that with design, because the changes are not granular and are not as easily traceable. The first step is steep, and a ladder is nowhere to be found.

Encoding/Decoding Link


In his 1980 article “Encoding/Decoding,” cultural theorist Stuart Hall defines communication in terms of code. To describe it briefly, let’s imagine a spoken conversation between Alice and Bob. Alice encodes her framework of knowledge into the communicable medium of speech. Assuming Bob can hear the sounds and understand the spoken language, he then decodes the sounds into a framework of knowledge.

Both encoding and decoding are creative processes. Ideas are transformed into messages that are then transformed into ideas again. The code that Alice uses for encoding is different than the one Bob uses for decoding. Alice could never telepathically upload ideas into Bob’s brain. (We can all agree that that is a good thing.)

Let’s entertain Hall’s ideas of encoding and decoding in software. Alice is an open-source hacker, and Bob is collaborating with her as a designer. Alice is writing software code; she knows when it executes and when it doesn’t because the program communicates that through error messages. When she is happy with the result, she uploads the code to an online repository.

Bob then downloads the code to his computer, and because it has executed on Alice’s computer, it also executes on his. When Alice and Bob collaborate through a programming language, they are literally using the same code for encoding and decoding.


Alice always chooses one of her three favorite programming languages. Being a designer, to communicate a message visually Bob starts by defining a visual language—graphics, color, layout, animation, interaction… If Alice or any other developer had to reinvent a new programming language on every single project we would not be speaking about FLOSS now.

Bob needs to define a graphic language, a standard for the collaboration. Doing that is already a major part, possibly the most important part of the creative work. Whoever works with Bob will need to accept and follow these standards, relinquish control and conform to Bob’s predefined graphic language. These artificial constraints are harder to learn and conform to than the constraints of a programming language. While constraints and standards in technology are the mother of creativity, in design they can often feel artificial and oppressive.

Beyond that, within a collaboration, when Bob tries to argue for the merits of his design, unlike in the case of Alice’s code he cannot prove that it executes flawlessly, or that it is faster or more resource efficient. The metrics are not as clear.

It is important to remember, in collaboration on code Alice and Bob have a third collaborator, one that cannot be reasoned with – the computer. This collaborator will simply not execute anything that doesn’t fit its way of work. On the other hand, as long as it is syntactically correct and satisfies the inflexible collaborator even “ugly code” executes and muddles through.  And so, the different voices expressed in code are flattened into a single coherent executed application.

For better or worse, we lack this inflexible collaborator in design. It doesn’t care about our communicative message and it doesn’t level the playing field for communicative collaboration. And so, the different voices in design simply spell inconsistent multiplicity that dilutes the communicative message.

One might turn to Wikipedia as a testament to successful non-code-based collaboration, but Wikipedia enforces very strict and rational guidelines. There is no room for poetry or subjectivity within its pages.

Is It Simply Impossible? Link

Not necessarily. If we step out of the technical construct of the open-source methodology, we can identify quite a few networked collaborations that are transforming and often improving on the design process.

Viewing free culture and the free sharing of media as evidence of collaboration is tempting, but the availability of work to be remixed and re-appropriated does not necessarily imply collaboration. Sharing is essential to collaboration but is not enough.


WordPress, the leading free blogging software, is an interesting example. Looking to redesign the WordPress administration interface, Automattic, the company leading the WordPress community, hired HappyCog, a prominent Web design firm. And in March 2008, WordPress 2.5 launched with a much improved interface. Through a traditional design process, HappyCog developed a strong direction for the admin interface. Eight months later, Automattic released another major revision to the design that relied on HappyCog’s initial foundation but that extended it far beyond.

One of the interesting methodologies that Automattic used to get the WordPress community involved in the design process was a call for icon designers5 to provide a new icon set for the interface. Within two weeks, the six leading icon sets were up for voting by the community.

But rather than just casting a blanket “Like” or “Dislike” vote, community members were invited to provide a detailed assessment of consistency, metaphor coherence and so on. Some icon designers in the running even acknowledged the superiority of other contributions and voted against their own sets. The icon set that was ultimately chosen, though, was a collaborative effort, because some of the icons changed based on inspiration from the other sets.


Another example is the evolution of grid systems for Web design. Half a century after the rise of Swiss-style graphic design, some design bloggers suggested that some of its principles might apply to Web design. Those suggestions evolved into best practices, and from there into Blueprint CSS7, an actual style sheet framework. The framework became popular and inspired other frameworks, such as

Similar processes happen in interaction design. One example is the pop-up window evolving into the elegant lightbox or modal window8 modules, and then changing and being modified again and again in open-source code libraries.

Other design-oriented experiments in free software, such as the ShiftSpace platform, challenge the Web interface power structure. ShiftSpace allows users to interact with a website on their own terms by renegotiating the interface and proposing different interactions on top of the page. Projects like ShiftSpace aim to expand the limited participatory paradigm of the Web beyond user-generated content to include user-generated interfaces.

Make It Happen! Link

There are ways to make open-source design work without falling into the traps often characterized as “design by committee.” We are already seeing designers scratching their own itch and contributing creative work to the commons.

Lecturing designers (or users) and demanding that they use bad tools for ideological reasons is counter-productive. Designers often use free tools (or use proprietary tools in unauthorized ways) only because they are free as in free beer. So, to win over new users, free software should be pitched on the full range of its merits rather than on ethics alone. While the ethics of “free as in free speech” are convincing to those who can “speak” code, the openness of the source to those who lack the skill to modify the code is a weaker selling point.

Free software tools have won on their broad merits many times, and not only on low-level system and network fronts. Wikis and blogging software (which are interaction and communication tools) that have been invented by the free software community have maintained a lead over proprietary competitors. Networking and collaboration are the bread and butter of free software, and the community should leverage these advantages.

Just as Wikipedia extends the free-software collaboration model by leveraging the granularity of characters, so can design. When possible, using code for design collaboration is preferable. Beyond that, collaborators should adopt distributed version control systems for both code and image files. Rather than trying to compete with proprietary software by creating open clones, the Free Software community can leverage its experience as an advantage and focus on new collaborative paradigms for version control and collaboration.

Finally, There are ways for us to better analyze the encoding and decoding of the communicated message. We can formalize processes of collaborative encoding. We can start by conducting networked design research using existing research tools; in this way, we might come up with design decisions collaboratively. We can define modular and extensible languages that embody design decisions but still allow for flexibility and special cases (like Cascading Style Sheets). We should also learn how to document our design decisions so that they serve other collaborators. Designers have been doing this for many years in more traditional and hierarchical design contexts when they have compiled documents such as branding books or design guides.

For the decoding part, we should realize that many design patterns are rational or standardized and can leverage common ground without compromising the creative output. For example, underlined text9 on the Web almost always implies a hyperlink. We could choose to indicate a link otherwise, but if we try to use this underline styling, say, for emphasis, we can expect users will try to click on it.

User experience research, technical aspects of design, best practices in typography, icon use, interaction paradigm—these are all aspects of design that can be researched and assessed according to measurable parameters. Thorough research of these can provide a basis for consensus for shared expectations of how a message will be interpreted. A lot of this work is already taking place on design blogs, which have published a lot of research on the subject over the past few years.

Finally, the substantial parts of design that still cannot be easily quantified or assessed on shared rational ground should be managed through trust and leadership. A resilient community of practice must be able to develop design leadership whose work and guidance is respected and appreciated even without the convenient meter of coding meritocracy.

Scaling Subjectivity Link

It comes down to the deep paradox at the heart of design (whether for interface, architecture, product, etc.). We are trying to create a subjective experience that scales—a single personal scenario that can be multiplied repeatedly to fit a wide array of changing needs by a vast majority of users. The thing is, subjectivity cannot be scaled—that’s what makes it subjective—therefore, the attempts to create a one-size-fits-all solution are bound to fail, along with the attempts to customize the solution to each individual user in each individual use case.


Chris Messina gives a great example for this paradox by comparing Apple’s Magic Mouse to the OpenOffice mouse. While Apple’s solution is a slick, clean one-button device, the OOMouse has “18 programmable mouse buttons with double-click functionality; analog Xbox 360-style joystick with optional 4-, 8- and 16-key command modes; 63 on-mouse application profiles with hardware, software and autoswitching capability…” and more. While the Magic Mouse embodies Apple’s commitment to design leadership at the price of user choice, the OOMouse embodies the free software community’s preference for openness and customization over unified leadership.

Successful open-source projects have always benefited from a mix of the two approaches, a combination of openness and leadership. Finding a similarly nuanced approach in other fields is required if we ever hope to extend the open-source model beyond code. We cannot sprinkle the pixie dust of open source on everything and expect wonders. The same goes for design. Hopefully, though, we can make some progress by demystifying the process and by collaborating wisely when it makes sense and coming up with new ways when it doesn’t.

“Can Design By Committee Work?” by Collaborative Futures11 is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License12. Based on a work at www.booki.cc13. This essay is also featured in the Collaborative Futures book, written collaboratively, published for free and released under the CC-BY-SA license.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9 #looks-like-it-should-link-to-something
  10. 10
  11. 11
  12. 12
  13. 13

↑ Back to top Tweet itShare on Facebook


Mushon Zer-Aviv is a designer, an educator and a media activist from Tel-Aviv, based in NY. He is a founding partner at Shual design studio, he teaches new media research at NYU and Open Source design at Parsons the New School of Design. He also blogs at

  1. 1

    Andrey Shipilov

    September 1, 2010 5:30 am

    Designers are so “creative” that they’re not satisfied just with copyright mentioning in a collaborative product — they need it in their portfolio (of course bulk of them don’t). So the answer is “No”. Designers just cannot design by committee.

    • 2

      I recently bumped in this issue and I have to agree with you. Designers cannot design by committee.

      • 3

        There’s a reason for that. ;)

        “Group intelligence is multiplicative when idiots are involved – combining a half-wit with another half-wit does not result in a full-witted person, it results in a quarter-witted person (1/2 x 1/2 = 1/4). Combining a full-witted individual with a half-wit still only yields a half-wit. The more of these “wrong kinds of people” you have involved in the process, the worse things get.”


        /begin rant

        That SEOmoz post is a harsh way of delivering a point, but there’s often too many different conflicting interests for committees to work. (I.e. Designer wants to create a readable layout, as this will be pleasant for the user, marketing guy wants to fill every whitespace with ads, CEO likes hot pink and kittens, project leader pressures designer to obey, and the design fails.)

        I have no problem using good ideas, but you would be surprised with the number of people wanting to put their “mark” on a project just to feel like they have earned their money. Even stupid asinine ideas, that ruins the flow of a site, get kicked in late and forced through in a almost complete design. Just because.

        /end rant

        • 4

          Mushon Zer-Aviv

          September 1, 2010 5:34 pm

          Boy… we wanted to provoke you guys with the title, but we didn’t expect so much frustration to come out… :)

          I basically agree with you. Collaboration in design is hard, but like the post you linked to shows, it is also a reality. We collaborate in the design process anyway, and that collaboration is often painful.

          Now we’re seeing emerging collaborative paradigms especially in the open source world and they seem to succeed. Can we learn from them to extend them beyond code? I believe we can. I believe we must, otherwise our work will be a nightmare. When it was all print, no matter how hard the process was at least at some point it was printed and done. For better or worse that’s not the case in interaction design and we have to learn to lead better collaborations.

          I chose to publish this essay here because I think Smashing Magazine is exactly one of these places where we see the emergence of collaborative design practices and standards. If its best practices for web typography, review and analysis of design patterns or even sharing of interaction modules in the form of code.

          If you can move beyond the provocative title I think you will find we both identified the same problem, but I’m trying to argue we should both also work to do a better job at dealing with it. Whether it’s within networked collaborations like Open Source software or even in client projects.

          Time for new collaborative models in design, because the ones we ARE using fail.

          • 5

            I actually agree with you. Sorry that it didn’t come across that way.

            My rant was targeted at the comment I replied to (and the comment before), that implied that the primadonna diva designer is the problem, not your article, which was great.

            More often than not I think that there’s more focus on the “fun” of coming with change/add requests, than the resulting feature bloat and what the user actually needs to use the end product. Your mouse analogy is the perfect example.

            Good article. :)

      • 6

        If everyone in the committee is a designer, then yes it’s possible!

    • 9

      Tachyon Feathertail

      September 1, 2010 10:14 am

      This comment should be deleted.

  2. 10

    Great article. I think the web design/development fields are in general a great way of seeing how design trends can develop in an ‘open source’ way. Everyone is feeding off everyone else, improving, changing and developing ideas. This is one of of the the things that drew me into web-development over traditional graphic design. Graphic designers are much more guarded about their inspiration/ideas and development.

  3. 11

    Design should not be done by committee.

    I’m a fan of dictated design. Assuming the designers have done their job properly, they’ve done all the research and can then create a single design that serves the needs of their users. I’ve seen this work and it works well…Apple is good example. This method isn’t perfect and there will be unhappy people, but that’s okay.

    Interface design is always user-centered. If your audience wants a 36-key programmable mouse, albeit ugly, then that’s what you give them. If your target wants fewer “thinking” options, then that’s what you give them.

    Designing by committee usually means the needle moves closer and closer to the middle over time, which is often not a good place to be. Designs need to focus on specific needs and be tailored, and designing by group doesn’t make that easy.

  4. 12

    Interesting article.. as a designer it gives me some things to think about for future projects :-)

  5. 13

    Christopher Anderton

    September 1, 2010 7:47 am

    My shots as a GUI designer at a OS project-

    – Wrap up pretty GUI
    – Demo why and how the UI and GUI works. What to think of when you are creating user interfaces.
    – Users mailing and calling me to get the GUI/UI out in the wild.


    – The coders went ahead with their own GUI/UI (that looked like a IRIX UI from 1991) and was getting angry with me because the users liked my stuff more than theirs.
    – The project was cancelled. And nobody picked the project up.

    So, you could run in to lot of problems. But on the other hand you could find a project that needs you, and where people are doing the things they are most suited for.

  6. 14

    OMG! – A real article! with substance!
    /steve weeps tears of sheer joy!

    I have a few problems with the article however (much as I appreciate its appearance and the fact that it is not another “list of”.)
    The problem is, as a scientific, fact based article, it is not very scientific or fact based, and much of the assertions are just plain unsupported by facts, research or even the article itself. There is also a “straw man” type of narrative which just ‘says things’ and goes on to build on the statements (which themselves are not fact based)

    “Each granular step gets you closer to the next granular step. This ladder of participation makes each successive step easier. It also allows you to compare changes easily, giving you transparency, accountability, moderation and an open license to try and possibly fail, knowing you can always revert to the previous version.
    **You don’t get that with design, because the changes are not granular and are not as easily traceable. The first step is steep, and a ladder is nowhere to be found**”

    That is simply not true. The assertion that you do not get granularity and markup transparency in the design realm can be observed to not be by any inherent limitation in the framework, but more directly attributed to practices and behaviors.
    The other thing that we have to look at (when speaking of behaviors) is that the design collaborative process does not necessarily involve OTHER DESIGNERS, per se, but the content consumers of the design product! – IE the Marketing team, the project managers etc. If they are (for example) PhotoShop savvy, they can use the inbuilt “granularity/markup tools ” in Photoshop (layers, and toggled layer opacity/visibility) to track changes to the product as it evolves.
    Using desktop sharing software, time-encoded whiteboards and online chat, you CAN have, in a design sense, the exact collaborative ‘groupthink’ approach as you have described.

    Consider also, that the collaboration does not have to be -and likely will benefit from not being in “real time”

    A FORUM even such as these comment areas, could collaboratively and incrementally build on a design, each successive post suggesting a tweak or enhancement

    • 15

      Mushon Zer-Aviv

      September 1, 2010 6:00 pm

      Hi Steve, thank you for your comment and for challenging some of my ideas. Let me respond to some of your critiques:

      “The problem is, as a scientific, fact based article, it is not very scientific or fact based”

      That’s true, this is not a scientific or fact based article. It is based on my experience and analysis in design and Open Source and media theory for quite some time now. But it does not involve any tests on lab rats or mass analysis of statistical data. I hope it doesn’t take to much from the article’s credibility or from its relevance to the debate.

      The assertion that you do not get granularity and markup transparency in the design realm can be observed to not be by any inherent limitation in the framework, but more directly attributed to practices and behaviors.

      Well, I actually explicitly argued that the use of markup code extends the granularity of the design. So I am not sure we’re in any disagreement here. I will argue however that the majority of our work is often not very granular, especially in comparison to code. Not only because of the technology but largely because of the cognitive task of reading the interface. It is a single mind that deciphers the design, not a multithreaded processor that levels everything down into a binary execute/doesn’t-execute. These design decisions therefore are much more top down and much less easy to collaborate on. I hope this helps explain this better.

      If they are (for example) PhotoShop savvy, they can use the inbuilt “granularity/markup tools ” in Photoshop (layers, and toggled layer opacity/visibility) to track changes to the product as it evolves.

      I think Photoshop is a great tool, but it is really horrible for collaboration. I am actually working with some interesting people on finding ways to implement some interaction patterns from the Open Source world into the design process (like version control). Our tools today (both open and proprietary) are not making the collaborative design process much smoother.

      Consider also, that the collaboration does not have to be -and likely will benefit from not being in “real time”

      Agreed! I would say however that we can and should analyze what works, what fails and why in networked collaboration (in design and beyond) and experiment in new tools and methodologies to get it right. It will take some time. Coders are reinventing the way they work together constantly (see the rise of GIT in the past few years) I argue that so should we.

  7. 16

    If you ever want the wrong answer, get 20 people in a room and ask the same question. Committees lead to watered down design. Everyone wants to be heard weather its the right answer or not. Individuals egos are too easily bruised. Could it work possibly in a very rare case, but it is not something to bank on.

  8. 17

    Nikos Stylianou

    September 1, 2010 8:34 am

    In a word, no! Nothing works well by committee, e.g WHATWG doesn’t work by committee and they get things done, W3C works by committee and it takes ages for things to get done.

    • 18

      Tachyon Feathertail

      September 1, 2010 10:16 am

      This comment should be deleted.

      • 19

        Nikos Stylianou

        December 3, 2010 4:55 am

        Why’s that then Tachyon? Even if my comment is deleted I know what I know about design by committee. I’m currently working for a large organisation that designs by committee and have worked previously with another large organisation that used design by committee, so that would be nearly 5 years of experience with design by committee, so you’re wondering why put up with it for 5 years if I don’t agree with it, and the simple answer is I get paid too well to not really care, so like I said, even if my comment is deleted I’m not going to be that bothered, and if you want my comment deleted how about giving a reason, or do you need to discuss that by committee before you give me a reason ;-)

  9. 20

    By commite? Try it several times, experiment with design by commite… and very quick you will say: “No, please. Let me do my work.”

  10. 22

    Design by committee is possible if everyone on the committee is knowledgeable about both design and the product being designed. And, if everyone’s ideas carry equal weight.

    But here’s the problem — those two criteria are never met. Most of the time, there are one or two people on the committee that outrank everyone else. To make things worse, high ranking people tend to know very little about design. They dominate decision making processes and impose their irrelevant opinions about design on all others that might actually be “taste-makers.”

    It’s important to get feedback from a lot of different sources, or even a committee, but the design vision should come from a single lead designer or a small creative team. It is absolutely impossible for a committee to share a vision without a leader. The resulting design will reflect this. It can be good, but it can never be great.

    Now here’s the flipside. There’s a very good reason to design by committee. Letting a single designer lead the vision is a risk. If the designer is talented, you’ll have a great design. But the catch is this: there aren’t that many talented designers out there. That’s the reality. There’s a lot more crap portfolios out there than stunning ones. Most designers could not handle the responsibility of carrying a vision. And even if it does look pretty, it might not make much business sense.

    So, unless you have a talented designer with good business sense, you’re better off with an average design created by a committee.

  11. 23

    Rob - Limeworks

    September 1, 2010 5:47 pm

    While committee can work in various instances, i don’t believe design is one of those.

    The wordpress example is powerful, however if they had hired the same people to do the grunt work, but simply made the decisions without consultation of a committee, then i think the advance in the GUI would still have been the same, albeit likely a little different.

    Same goes for Marketing by Committee. Focus groups are a perfect example of a system where the results can be totally off. There’s more than a few documented examples of focus groups leading in the wrong direction.

    Bold actions by a few will often provide a stronger result (it may not be the correct one, but will likely be more powerful one way or another) than using the wisdom of crowds.

  12. 24

    I am somewhat surprised by the lack of depth of this article, although understandable for this audience the title isn’t actually covered in the article. Having been involved in a opensource project as designer for the last two years, I do not share many of the experiences in this article. Taking WordPress as a leading example, is somewhat wierd – because that is essentially very much designed by Automattic staff (they are doing an awesome job). Where as other projects like Ubunutu, Drupal, Fluid Project and even Openframeworks/Processing are far better examples of where design flourishes because of the open nature and collaboration happens on large scale in terms of user experience work.

    It hardly ever is true design by committee, it is far more common for community thought leaders to make the direction in terms of design – depending on the community its maturity this will be a designer.

    Your article goes into collaboration, but provides very few real world examples – this saddens me somewhat, there are plenty! (steve42 facts question, should really be about this – not scientific facts) You don’t touch on a very important part which is the exploratory nature of design which is very much catered after in Opensource, its rare that you get one solution, one direction – almost always are there several proposals and prototypes to go from. Also you definitely train communicating your ideas in opensource, a strong UX argument is very likely to prevail if you are able to communicate it effectively – sadly many designers are pretty bad at doing this.

    I found your Make It Happen! part great and somewhat touched on modularity which is at heart of many opensource projects.

    Either way I think this article missed a great opportunity telling about the stories in opensource and instead focused on vague principles, like the inflexible collaborator which quite frankly is the end-user of the project.

    • 25

      Mushon Zer-Aviv

      September 2, 2010 11:29 am

      Thanks for your comment Bojhan,

      Where as other projects like Ubunutu, Drupal, Fluid Project and even Openframeworks/Processing are far better examples of where design flourishes because of the open nature and collaboration happens on large scale in terms of user experience work.

      Either way I think this article missed a great opportunity telling about the stories in opensource and instead focused on vague principles, like the inflexible collaborator which quite frankly is the end-user of the project.

      I did not mean for this to be a survey of existing methodologies, even though I do agree with you that that might make a good article. Drupal is going through a very interesting process right now, but it would be premature to write about it before the next release is out. Maybe you should write a survey post and link to it here or even offer it to SM. I’ll be very interested to learn both from your perspective and from your experience.

      I do think WordPress IS a good example, because they work really hard to balance Automattic’s leadership and the community input. True, it is not like their process is completely structureless, but I wasn’t arguing for a second that it should be. I used them as an example of a successful result (we can bring up many examples of bad results) that does involve the community either for feedback or for actual design patches as you can read about in Jane Wells’ comment below.

      As for the inflexible collaborator, what is unique about the computer as a collaborator is that it is unique and absolute. We have many users. with many standards and many concerns, not always something we can predict or decide that we have to agree on. In code all the human collaborators HAVE TO satisfy the machine collaborator. It levels to a large degree both their contributions and their disagreements.

      I hope this better explains my vagueness… ;)

    • 26

      In support of the Author, I would point out that his article was more a treatise on opensource type collaboration in the DESIGN field specifically, i.e. Graphical and Web User Interface design – not necessarily software design, opensource and collaboration (though of course, the boundaries are necessarily blurred)

      True, the examples that were more of software collab projects did somewhat confuse,but I guess there are not many directly identifiable examples of group collaborative opensource activity with design…..wracking my brain, the Tango icon project and some Gnome work does come to mind however.

      Also, many projects that are choosing a logo and expose the request to their member base will find in their forums an excellent example of collaborative design.

      What makes it work in that case, is a clearly defined SPECIFICATION of what the logo is supposed to contain, represent and evoke. Guided (and restricted) within those parameters, the community can let loose and put forward their own ideas which may be mashups of the previous entries.

      (see also, “photoshop tennis”)

  13. 27

    Much of your argument is based on the idea that Happy Cog as a design firm did WP 2.5, and it was good. But then Automattic got WordPress users to redesign the Happy Cog’s work in WP 2.7, and that was much better. That somehow the users did a much better job overhauling WP than a professional design company ever could.

    You have your facts completely backwards.

    WP2.5 was what Automattic asked Happy Cog to make. I guessing that Happy Cog had a much better idea of what to design, based on their years of experience as professional designers — but the client thought they knew what they wanted, and they didn’t want what the professional designers were suggesting. So they shipped WP2.5 with a “redesign” that was basically a visual refresh of what WordPress already had, plus a several IA tweaks. It was an improvement over all the previous versions of WP, but in many ways, it was the same.

    Then, after WP2.5 shipped, Happy Cog took their more significant redesign (code-named “Crazyhorse”) and tested it against WP2.5. And Crazyhorse won. It beat the pants off of WP2.5. When Automattic saw the results of the user testing, they were convinced that the new design was better. And after a bunch more work by Happy Cog, and yes, some input from the community, they shipped it in WP 2.7.

    This is a tale of how professional designers getting to do what they do best leads to the best result. WordPress 2.7 was the opposite of design by committee, not the result of it.

    This is also a tale of the importance of user testing, not users-get-to-design. Designers took the results of the user testing, and incorporated what they learned into making the design better. WordPress 2.7 was not designed by users. It was designed by professional designers who took into consideration lots of different kinds of input from the community.

    • 28

      You make a valid point/counter argument (and well supported with corroborating links)


      Are we now splitting hairs as to what constitutes a committee?

      If we define the ‘committee’ as being the requesting user, the end users who provide testing feedback and the implementers/designers (HappyCog) who iteratively incorporated the feedback from the end users… isnt that an example of successful committee development.

      Why couldnt HappyCog have produced the ‘winning version’ from day one?

      Is it because Automaticc dominated the design process earlier, forcing a sheepish and shy HappyCog to retreat into their shell and produce an admittedly mediocre design? Then, once ‘freed from their shackles’ ( a common mantra among designers) they were able to let loose and create something truly magical?

      The facts that you have linked to (in support of your argument) belie your words.
      The facts as shown, indicate that significant SCIENTIFIC and OBJECTIVE METHODOLOGIES (as opposed to artistic and subjective) were introduced to capture, analyze and QUANTIFY the effects of changes, moving past subjective perception “It looks great!” moving towards true objective observation “Tasks that took 4 minutes now take 30 seconds!”

      The issue is in my mind, not “do committees work” but.. “How do I establish a committee that leverages our common intelligence to work efficiently?”

      Airlines have reduced chances for error by introducing specific behaviors into the process (i.e. Pre-flight checklists)
      To answer known human interface deficiencies (i.e. A junior co-pilot is hesitant to point out an error being made by his Captain for fear it ‘angers the Captain’ or ‘make him look stupid) the airlines teach and preach CRM (Crew Resource Management).
      Jr officers are trained to be assertive when pointing out safety issues, and Captains are trained to not be threatened but appreciative when safety problems are caught.

      Similarly, there are techniques that can be used effectively in social situations and collaborative environments…BUT THEY HAVE TO BE USED.
      Properly implemented, a committee is an ideal manner of representing the various stakeholders in a design production (or any production), BUT A WELL PLANNED METHODOLOGY IS ESSENTIAL.
      Have you ever chaired a meeting with no agenda, no timeline, and nobody taking notes?
      Did you expect it to be effective?
      Have any of you ever assembled a jigsaw puzzle by tossing the pieces in a bag like a salad…and expecting it all to come together?

    • 29

      Hi Jen. I’m the UX person for WordPress, so I’d like to set the record straight, since you accuse Mushon of having his facts wrong. Actually, it looks like you have some of the details/timelines/attributions mixed up (based on the statements in your comment), so here’s the exact progression of WordPress 2.5 to 2.7. WordPress 2.5 was designed by Happy Cog.

      The usability testing on 2.5 wasn’t done by Happy Cog, it was done by me and several colleagues under the aegis of the Ball State University Center for Media Design, a usability testing and prototyping lab that I was leading at the time in New York. WordPress 2.5 got a very vocal and mixed response from the WordPress community, and I offered Matt (Mullenweg, leader of the WordPress project and founder of Automattic, which had recently come into some cash via investors) a project slot in the lab at a reduced rate when we had an unexpected opening due to a cancellation from a TV network. Liz Danzico, who had been part of the Happy Cog team during the 2.5 work, met with us to give us background on the intentions of the 2.5 design and observed some of the tests, but she was not a participant in the testing process itself. She was also acting as an independent consultant at that time to Automattic, not a Happy Cog rep.

      When my Ball State team (me + two researchers from Indiana) produced the testing results on 2.5 and a test version with a handful of usability fixes, we talked with Matt and decided on the scope of the prototype design. It was recommended by me that we experiment with an entirely new navigational metaphor, as the 2.5 navigation was a serious stumbling block for many users. Matt asked me to design the new prototype. Since Liz was working as a freelance UX consultant for Automattic, we decided to work together, so that further work after the testing project ended could be continued by her. Liz and I designed the Crazyhorse prototype together as independent consultants, not Happy Cog. We have lots of scribbled storyboards to prove it. :)

      To prevent possible bias, I removed myself from the second round of testing moderation and my Indiana colleagues conducted the tests (including eye-tracking) and final analysis.

      Liz and I presented the results together at WordCamp SF 2008. You link to, which are the slides from that joint presentation. You also link to, but that is my document, not Happy Cog’s. Notably, I wrote that specific report after I joined Automattic so that the community could get an inside view into the testing and the reasons behind the design change.

      At WordCamp SF 2008, Matt convinced me to come work for Automattic and take the lead on UX for WordPress, which I’ve been doing for the past two years now. At that point Liz started working on other projects, and I worked with the development team to turn Crazyhorse into 2.7 in terms of functionality and structure, and then Matt Thomas gave it the visual style. You are right that WordPress 2.7 was designed by professionals with user input and not directly by users, but it was not by Happy Cog. Also, I don’t think Mushon said 2.7 was designed by users. He referenced our icon design contest, which was open to all, and was very successful. The success of that experiment, intended to harness the potential contributions of designers in our community as much as those of developers, led to the creation of our volunteer UI group, which includes professional designers such as John O’Nolan, who runs the weekly IRC meetings.

      We don’t go for design by committee (or least we try to avoid it, but the fact is that every design decision is publicly debated by the dev community), but WordPress has opened up the design process significantly in the last couple of years, allowing contributing designers to submit mockups and write css patches rather than it all falling on one person’s shoulders. That collaboration makes us better and stronger, and we hope to increase the openness of our design process moving forward.

      • 30

        thank you VERY much for correcting the record and adding to the history and documentation of that fine product.
        Due to your efforts and others, we have a product that all can enjoy (and now, use more easily!)

        a fine post. kudos!

  14. 31

    I think RepRap and Zoybar are good examples of collaborative hardware design projects:

    Both projects made their production files free to download
    and it seems that each member / “designer” has a lot of creative freedom:

    this is something that is already happening, not just in theory.

  15. 32

    We can think about the approach that Ubuntu have taken, where pre-“Lucid Lynx” the design of the UI and branding was very much open and collaborative. This all changed in the run up to Lucid Lynx when a formal design team was assigned and the design process was cut off to just this team. This resulted in a complete rebranding implementation and totally new UI look, which revitalised, modernised and “professionalised” the distro. However, an aspect of the Ubuntu design process that remains open is the encouragement of involving the community in providing feedback and, therefore, data, which is invaluable.

  16. 33

    Lots of previous commenters seem to have grabbed onto the word “committee” as a point of contention. It’s a strong word, but maybe not necessarily the right one when it comes to collaborative design. There’s a commonly used metaphor about committee syndrome, painting the bike shed. It goes like this:

    “just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.”

    (The whole, instructive story of painting the bike shed is here:

    The extreme response here might be to the very traditional idea that those handing out the briefs, paying for the work and ultimately wanting to help paint the bike shed often know little about design and become a hindrance in the process. And sure, that’s often a problem with clients. But if I think about my time in design school, the majority of my projects were collaborative. We were expected not only to work to briefs but to be able to collaborate well, if not always harmoniously, with others not of our choosing. Some of those collaborations were wonderful, some less so. Different people with different styles, skills and personalities don’t always work happily together. If we’re lucky, we get to pick and choose the people we work with, tailoring for complementary styles and preferences. If we’re unlucky, we wind up with a lot of horror stories to tell about death by committee.

    Now, I’ve found, working both in and with F/LOSS (Free/Libre Open Source Software) design, it’s not much different from the traditional stuff. As in any endeavour involving people, some groups are compatible and some aren’t. One key difference, though, is that many F/LOSS communities have built up their own cultures around conflict resolution. That’s something not always extant in more traditional work environments. Not only that, but bike shed painting is a known threat that people are conscious of. This means that, unlike with a clueless client, the others working on the project can be reminded that a certain degree of sensitivity is involved in design work and that chipping in on the colour of the shed isn’t always a good idea.

    With distribution of labour and responsibility (another thing the F/LOSS world knows very well), sensitivity towards different skill sets and good conflict resolution procedures, design in the F/LOSS world can often be less painful than more traditional methods. With different stakeholder roles than the traditional master and (skilled) slave relationship, there’s actually room for substantial discussion, not just grumbling after the fact about lousy clients who know nothing about design. That alone is a major improvement.

    • 34

      Mushon Zer-Aviv

      September 3, 2010 12:46 pm

      Good point Ginger,
      Actually in the publication of this article in the Collaborative Futures book “bikeshedding” is added as a glossary item within the article itself: :) Bikeshedding is indeed very relevant to the issues I raise here, it is exactly the phenomenon of design by committee within open source projects—when the standardized & rational meters are absent consensus can become much harder to achieve, even if the actual consequences of the decision are not too grave.

      In the design process too many of the decisions can fall into this classic bikeshedding phenomenon. That’s why it is important to structure the decisions in a way that would create standards and rational meters to the collaborative decision making process. And beyond that, to realize the recurring pitfalls of a collaboration and make sure the arguments are constructive rather then… ahm… bikeshedding.

  17. 35

    Tyler Mulligan

    September 2, 2010 5:03 pm

    It used to be PSDs back and forth by E-maill but recently, a few friends and I have been using Inkscape together with git for “tossing the pigskin” in Ubuntu Linux environments.

    SVG is an XML format, so it’s readable or better yet, understandable. In diffs, using good naming techniques in your XML gives you a plain English explanation of what you’re looking at. The ease in the work-flow (minus Inkscape’s shortcomings, (I still love you Inkscape)), is so convenient and powerful.

    Open-source isn’t perfect, Inkscape isn’t perfect. However, as graphic artists or creators of any sort, we can collaborate together in such beautiful ways that words simply cannot. Actually sharing the structure to review and mold, direction can be shown rather than told. Where words fail to communicate.


    • 36

      Mushon Zer-Aviv

      September 3, 2010 6:52 am

      Very interesting Tyler,
      any chance you might want to publish a post, or even better a screencast about it? I think this can be a great example of how version control tools can leverage collaborative work beyond code. If you can avoid command line (which is the point where many non-coder users might tune off) and present a streamlined user friendly process, I think it could serve as a strong argument for Open Source design.
      Thanks for your comment, hoping to see your next one soon ;)

  18. 37

    Design by comittee will work if you’ll have a dedicated team and if your working with the same goal.

  19. 38

    Design by committee will assure you that a product will be produced within deadlines – After all, the job gets sliced (+ the thinking as well). Committees work well with coding (especially when assigning who does what well). Trying to fit a committee into a design is synonymous to using the wrong tool for the job – you mess things up.

  20. 39

    While I commend Mushon for his compelling argument, I do not think open-source design would work. Being a creative myself, I know that passion, stubbornness, and subjectivity just come with the territory. These traits do not bode well when trying to achieve a unified goal.


↑ Back to top