Is Collaboration the Best Way?

It has become a shibboleth of the UX and Agile communities that “collaborative design” is the best way of designing things. Or if not the best way, it is at least better than leaving people to come up with solutions on their own. Regular readers of Webtorque will know that if there’s one thing I like to do, it’s to question things that appear to be received wisdom. The usually unchallenged assertion that collaboration in design is always good is a prime example. So, let me set up a straw man and look at it from the perspective of my own experience.

Firstly, to define our terms a bit. The word “collaboration”, when used by most design practitioners, appears generally to mean the act of two or more people working together at the same time to help arrive at or near a final design solution. There are endless techniques, “best practices” and methods of optimising the way people collaborate, which usually fall to designers to facilitate or plan in some way. This book, for example, is a catalogue of what might be termed “deep” collaboration techniques aimed at getting as far as possible into a problem to arrive at a solution. There are also higher-level techniques such as paper-prototyping (you know something is big when it has its own website), RITE and “design charrettes“, advocated by designers around the world. The shibboleth is as broad as it is pervasive.

Yet the first thing you notice about collaboration is that people appear not to want to do it. Perhaps this is just fear of the unknown, or force of habit, culture or other factor that encourages people to act alone on problems and produce solutions without consulting others. I’ve seen this tendency among newly formed teams as well as those who have been working together for years. The prospect of presenting bad (or worse) “stupid” ideas in front of your work colleagues, even if you are all the same rank, is naturally off putting. Another way of interpreting this is that people just feel better thinking through problems alone until such time as they want to communicate with others. That is, after all, how most scientific method works, so why should it not be the case for design?

But perhaps there’s more to it than just inertia. The first thing you notice when conducting a collaborative design session is how difficult it can be to do. The anti-patterns you encounter are tremendous, defy forward planning, and require a great deal of skill to manage successfully. This is why there are so many “brainstorming” techniques out there. Consider also that the premise of brainstorming itself has not been shown to be any better in terms of coming up with better ideas compared to other ways of doing the same thing.* All this isn’t helped by often high expectations people bring to such sessions, which is an inevitable by-product of the buzz generated by the proponents of collaboration in design, many of whom of course just want to sell books and speaking engagements (nothing wrong with that really – but it’s a common feature in UX, and indeed most other disciplines).

In my own experience, even after I think I have successfully navigated the rocks in the sea of collaborative sessions, I am often left with the nagging doubt that what we’ve just done is come up with a design by committee. After all, isn’t that a cliché in the definition of bad design? How does collaboration really avoid this without the iron fist of the “genius designer” to determine what, and what is not, the best solution? Perhaps that’s the wrong question to ask. Perhaps whatever you get is the best you’re going to get, because there is no better alternative.

But what about the role of the benign dictator? At this point, the obvious thing to mention is Apple, where, it is rumoured, Steve Jobs is the iron fist. You get the impression that regardless of the amount of collaborative design being done at Cupertino, if it’s not part of Steve’s vision for the product, the product won’t be shipping. Apple gives a clue to the riddle though, because, on those occasions I have been able to perform the role of the iron fist, collaborative sessions then become high-level (looking at specific interactions, handing edge cases, etc.). Others then work a lot better in determining how the details should work. Instantly, subject matter experts can concentrate on specifics, technologists can advise on feasibility, and things just become more comfortable overall.

None of this proves that collaboration is bad, I’m setting up a straw man here after all. But I do think it deserves examination. Of course, it’s next to impossible to compare the difference between one design technique and another in anything like a controlled manner. Nevertheless, my suspicion is that collaboration works best when you have a lead designer or architect on a project who issues the broad brush strokes. They can then give the details to a cross-disciplined team who will work well together on the that. This is better than trying (as Agile often does) to let everyone be a designer from scratch from day one. I’m a designer, and if I find that prospect scary, what are those who aren’t paid to think in those terms going to do? Good design is hard, and very few people can do it consistently well. Bad design is easy (though perhaps no less painful), and everyone can do it pretty much all the time. It’s all further complicated by the fact that bad design isn’t usually apparent until it’s too late. So I think collaboration needs to happen with these things in mind if it’s going to help rather than hinder.

* Rickards, T., (1999) Brainstorming, M Runco & S Pritzker, Eds, Encyclopedia of Creativity, San Diego: Academic Press Vol 1 219-228