Menu Search
Jump to the content X X
SmashingConf London Avatar

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. our upcoming SmashingConf London, dedicated to all things web performance.

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?

Further Reading on SmashingMag: Link

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 designers8 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 CSS10, 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 window11 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 text12 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 Futures14 is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License15. Based on a work at www.booki.cc16. 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
  10. 10
  11. 11
  12. 12 #looks-like-it-should-link-to-something
  13. 13
  14. 14
  15. 15
  16. 16

↑ 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.

  21. 40

    Jack Repenning

    September 3, 2010 3:07 pm

    You have completely misunderstood how open-source software development works. This is excusable, since you came to this misunderstanding by believing what open-source software developers claim, but none the less … this ain’t in fact how it’s done. Fortunately enough, in inventing a “new” collaborative process that will work for design, you’ve stumbled onto the true way open-source software actually works … so good for you, your ideas will work, they’re tested and confirmed by open-source software experience.

    There are two ways in which you had to fight your way out of the deception.

    First, there’s the difference you claim in the “languages.” In fact, designers also work with a fixed language, and must express themselves in it: if you arbitrarily decide that mauve is the perfect color for a danger indicator, or that active controls should look like spilled coffee instead of buttons, you’ll have a rough time. Conversely, though you’re right that software development involves a perniciously unforgiving compiler element, this has little to do with any variations anyone cares about. There is substantial creativity in making software, including almost always many alternative ways to solve the problem; and there is a substantial amount of “style” and “art” and “taste” required–for functional reasons, as well as aesthetic, just like in design. What you failed to notice in open-source software process, and therefore had to “invent” for your design process, is collaborative development of, and allegiance to, standards of style and aesthetics. But this is characteristic of successful software projects, just as much so as design projects, and those projects that allow liberty in these produce unsatisfactory results, or none at all.

    Second, you fell for the “meritocracy” line. Open-source software teams really do self-organize on the basis of meritocracy, it’s true, but there’s also always a well-known opinion leader. Whether called “Benevolent Dictator For Life” or given no title at all, and occasionally represented by a very small subgroup, there’s some one , or some very few, to whom all look for direction in both style and substance. One of the tricky bits of meritocracy, though, is that the leader is nearly always self-effacing, and leads most effectively by recognizing and drawing attention to others whose ideas most advance the style, culture, and content of the project. Sometimes, it’s hard to spot the leader, but hang around in the group a while, and it’ll be come clear. Gentle, behind the scenes, but none the less effective leadership is the protection against the chaos of the committee.

  22. 41

    Mushon, this is a great article and so is the resulting discussion.

    As the user experience architect for the Openbravo open source project, I feel compelled to share my experiences here. In our project, Design-by-Committee works but only under specific constraints. Having said that, I prefer to use the term Collaborative Design rather than Design-by-Committee as it is associated with with diluted solutions or, as Sir Alec Issigonis once said: “A camel is a horse designed by committee.”

    Our constraints are:

    – The committee are all stakeholders and regardless of role, status or stake, members can share their opinion on existing ideas or propose new ideas. For me, our open source community (including my direct colleagues and boss) is the committee.
    – There needs to be one design authority that calls the shots. This person is held responsible for the vision and the delivery thereof. Without leadership, it is very hard to produce great design. Most open source companies pay for professional designers, either by employing them or using agencies. The reason why design leadership is needed is that designers are trained in creating holistic rather than partial (feature based) solutions. In large complex projects such as Openbravo ERP, only few people really have a clear picture of what makes a product great. I have talked with the community for two years now and I have heard a wide variety of requests that would “make the product great”. One user wants to have a minimalistic GUI with a responsive keyboard operated editable grid to allow for mass data entry, another business partner wants to have contextual in-page help to ease their training efforts with their end customers. Both requests are valid for them but not for all! It is the design lead who aggregates their requests and weighs them. This is sometimes done using quantitative research, sometimes just qualitative, sometimes just plain gut feeling. Even the choice for one of these three methods is a design decision in itself and the designer is the best person to make it.

    I agree with the remark pointed out earlier in this thread that having one design authority can be risky because only if the designer is great, you’ll have great design. But that´s not all, even a great designer working in a domain where her knowledge is very limited, she will need to be talking to the community at all times, to be fed with domain knowledge and to ensure that her decisions make sense. Designing a web shop for shoes does not require a whole lot of domain knowledge. We all buy shoes, and we all do on-line shopping. Here, great design can be reached in relative isolation. For more complex products and domains, a designer needs to excel in applying an appropriate design process, which always include stages of knowledge tapping from the subject matter experts and feeding the resulting design work back into the community. Open source communities do use meritocracy more than any other organizational entity so admitting lack of knowledge in a domain is the only way to survive as titles and hierarchical positions do no play an important role. As a design authority in an open source community you gain respect by being able to listen, convert other peoples ideas into solutions and tap into the community knowledge. Applying a solid design process is what sets you apart from the crowds and this is where you cannot falter.

    – In Openbravo we design hypothetically. Based on the community input I design solutions and throw them back at them to react. Hardly ever I receive (visual) design solutions. Initially I really tried hard to convince the community to create design work as well, even handing them over tools & methodologies to do so but it did not happen. Non-designers are just not used to convert their ideas (or pet peeves) into tangible design work. In the end I did not find this a problem at all. As a designer you are trained to visualize ideas much better and faster so why not do it yourself and ask the community “Is this what you mean?”. I hardly ever ask the community anymore what they want. To use another horse related quote: “If I had asked people what they wanted, they would have said faster horses.” – Henry Ford.

    – There needs to be full transparency in the design and design making process. I tell the community that I hear them but that does not always mean I am going to do what they say. In case I don´t do what they suggest, then I always try to tell them why not.

    – Do not aim to discuss everything. For the visual design of our upcoming release I have intentionally kept the community out of the discussion. The graphical designer I work with plus three colleagues whose opinion on design I highly respect were enough of a committee for me to make a decision on the final design.

    It is truly refreshing to work as a user experience designer in an open source environment because of the ease of access to stakeholders feedback. This is a great competitive advantage over proprietary software and I believe that on the long run open source software will outperform proprietary software just because of the power of collaborative design but only if managed well by professional designers.

  23. 42

    Michael Hansen

    September 5, 2010 5:44 pm

    A designer working with a designer in an open-source environment has, I think, a tougher skin than a designer working with a client. A designer is there to serve the client, but what if the client wants to change the background color to something that is, well, hideous to man and beast?

    Also, is it ever best to design by committee? Darwin, Newton, Edison… These people worked by themselves. I can’t imagine someone telling Edison, “Tom, use a yellow background.”

    • 43

      Mushon Zer-Aviv

      September 6, 2010 6:53 am

      Isaac Newton famously remarked in a letter to his rival Robert Hooke dated February 5, 1676 that:

      “What Descartes did was a good step. You have added much several ways, and especially in taking the colours of thin plates into philosophical consideration. If I have seen a little further it is by standing on the shoulders of Giants.”

      I had to…

  24. 44

    — in addition to the comment I posted yesterday, I forgot to share the link to our UX Lab Forum where design work is discussed with the community: and a blog where design work is announced

  25. 45

    Yes, but design by committee, only works with like minded individuals who have a unified goal and drive. Ideally this goal and its drivers are the goals and drivers of the group/company itself. If the members all have personal goals and drivers then the task of design by committee will always inevitably fail.

    The people at WordPress for example, have/had a unified vision as a group, I would be surprised if there was a sales directory pushing features for features sake to tick a unimportant sales sheet that they still believe is the most important thing to them, or if there was a designer desperate to put useless infographics in to make it look more exciting and all the other many pitfalls that come with development and it’s place within the bigger picture of a company.

  26. 46

    How can you have this article: literally 2 months before you have this article.

    Are you just writing stuff just to write these days?

  27. 47

    Hi Mushon, FLOSS projects really seem to be too fast to declare the buzzwords ‘design by committee’ as their leading light. The discussion your article triggered was an exciting read! Your article, on the other hand, was much less so. In the article ‘Can Design By Committee Work?’ the terms ‘design’ and ‘committee’ are certainly a fitting choice for a trendy title, but the serious reason for your decision to use them escapes me.
    -The ‘design’ you mentioned seems to be limited only to an individual design approach. A designer-as-a-craftsman approach. Omitting most of the valuable multidisciplinary insights design science, methodology and practice mustered to conclude in the last 50 years or so.
    -The ‘committee’ turns out to be really just a metaphor for a gang of vile engineers in need of help but do not acknowledge the fact? Or did I misread?
    In the end, the article seems to suggest and outline a method of ‘sucking-up’ as an approach to design in the open-source paradigm. It is an approach. Probably not the best one, but an approach, nevertheless.

    • 48

      Mushon Zer-Aviv

      November 16, 2010 10:10 am

      As I have acknowledged before, the choice of the title might have been a bit too sensationalist. I had issues with this choice before the publish date and I have issues with it now. You are correct to call me out on this.

      Beyond that, I am interested in your critique but would appreciate a bit more clarification on it. I focused on interface design because I feel that the celebration of collaboration on free software development is very lacking without it. I focused on web design because I see some progress there.

      This was never meant as a conclusive survey of “design” as a concept. I have explicitly mentioned that in the first paragraph.

      Either way, I’d love to understand more what do you mean by “method of ‘sucking-up’”. I really appreciate your comment and want to engage your critique, but I need to make sure I better understand it first.

  28. 49

↑ Back to top