Collaborative Prototyping, Groupthink and Design by Committee

Collaboration stinks. At least it was my first thought when I read the following statement in the New York Times article ‘The Rise of the New Groupthink’: “..decades of research show that individuals almost always perform better than groups in both quality and quantity, and group performance gets worse as group size increases.”

Collaboration for UX

Software development is a collaborative discipline, and a good UX team is the focal point of collaboration in a software development organization. In this series Andrew Mottaz explores these collaborations.

See all posts

Related posts:

This presented a slight problem, as I’m all about collaboration. I am CTO at Site9, and our product, ProtoShare, is built on the premise that collaboration is a powerful process that will revolutionize your UX, design and development experiences.

And as I read the article, I found myself agreeing with much of it. Who hasn’t had the experience of seeing their ideas butchered by a committee? ( See ‘Why Design by Commitee Should Die‘ and ‘Team Collaboration: Identifying the Warning Signs of Failure & Getting to Success‘)

Brainstorming, in particular, is singled out in the article, and for good reason. The author states: “People in groups tend to sit back and let others do the work; they instinctively mimic others’ opinions and lose sight of their own; and, often succumb to peer pressure.” I really agree with these statements. This is why meetings can be so unproductive or worse. ( See also ‘Meetings Where Work Goes to Die‘ and ‘Making Meetings Productive‘).

Another point in the article I completely agree with is that privacy and solitude improve creativity and productivity. I love working alone. Some of my most inspired moments come from ruminating, researching, experimenting and working alone.

I believe in collaborative methods

And yet, I’m still a strident advocate for collaborative methods. I see collaboration as an incredible breakthrough that radically increases productivity. The first time I used a Google Doc spreadsheet, I thought “Here is a somewhat clunky, slower, less powerful version of Excel. But I love it!” Why did I love it? Because I could invite the board chairman in to look at and work on the spreadsheet. I could send it to all my board members and executives when I was finished to get their feedback, all in one place.

So I love collaboration. The key difference is what kind of collaboration. Sometimes I want to collaborate because I’m feeling lazy and I want someone else to do the work. “Brainstorming,” defined as: get a bunch of people in a room to spit out the first thing that comes to mind, might count as collaboration, but its not where you’ll get your massive productivity gains. My version of collaboration does not result in the collaborators getting out of the hard work of thinking, stewing, experimenting and generally making an effort. If you know anything about diffusion of responsibility, you’ll understand why collaboration can have negative effects.

So what do I mean by collaboration? To me it means getting other people to look at, understand and engage with what I’ve done (or engage with something someone else has done). When I’ve written a draft, come up with a solution or solved a problem, that’s when I want to harness the power of collaboration. “Here’s my idea — what am I missing?” People have an amazing ability to see issues that I missed, or even ignored, and to force me back to look at my work with fresh eyes. And what’s more, when I propose something concrete, the people giving feedback are more engaged and creative. That’s why collaborative prototyping is such a powerful means of collaboration. By definition I am presenting something visual and concrete. It’s easy for a huge range of stakeholders to engage with a prototype.

The beginning is important

I tell everyone presenting ideas in meetings to start with: “Here is what I am proposing and why I think it will work,” and then to ask for feedback. Compare this to going into a meeting saying: “I want to accomplish X. Does anyone have any ideas on how we could do this?” For me, the difference is stark. When I present a concrete solution, people get engaged. They can quickly sense the contours of the problem. They pick up subtle information based on my approach and reasoning. And they will see things that I missed.

One example of this, something that happened to me a few weeks ago, involved a product feature that had been on our roadmap for a long time. The implementation path was unclear. The feature had the potential to spiral out of control into an endless list of features. I’d done some thinking, and I thought that I had a strategy for an easy-to-implement, lightweight solution that would provide at least some progress toward solving the underlying problem.

I created a prototype to illustrate these ideas, and I presented them to the CEO and the engineers in charge of implementing a solution. There was pushback. (Have you ever had a conversation with engineers without pushback?) The solution wasn’t complete enough. It didn’t satisfy this use case or that use case. Yes, I said, but my solution is doable. It accomplishes objective A, even if it doesn’t solve B, C and D. It gets us moving toward a solution.

The meeting concluded that the engineers would spend a little time thinking about my solution and possible modifications. I would complete the task of fleshing out the user stories and prototypes so that my idea would be concrete enough to develop.

So…progress made, right? I didn’t love my solution, but it made progress. It was the best I could come up with, and it was a solid idea.

The next day, one of the engineers approached me to discuss the issue. He’d taken my idea, and it had spurred him to think of a slightly modified approach. It would require a small amount of engineering, but it would get us B, C and D. In addition, the benefit of this small shift would also spill over into several other areas of the application as well as open many interesting future possibilities. In short, his idea was perfect and brilliant.

Would either of us have gotten there on our own? I doubt that I would have. He might have, but the fact that I did some hard work and private thinking provided a scaffolding for him to use to complete his ideas.

This is the power of collaboration that I see over and over again. An individual makes the effort to solve a problem. This is a private process. The results are concrete. This is why collaborative prototyping is so powerful, in my opinion. The prototype makes the ideas concrete. This gets your stakeholders more engaged and requires more structured thinking and effort on the part of the individual before collaboration happens.

Brainstorming is great too

In fact, I think brainstorming is a great idea too. But not brainstorming as in getting people together to contemplate a solution to a novel question. For me brainstorming means: “I know you’ve all thought a lot about this particular issue. I want you to share your ideas in a nonjudgmental setting.” It’s the preparation that matters. When people collaborate on ideas that they care about, that they’ve spent mental energy contemplating, and that they understand, the results are phenomenal.

I did some research for an article about creativity. Part of the research was looking at models that academics use to model creativity. One thing they all had in common: preparation. You have to plow the field before you plant. The term we use is engagement: have I spent time understanding the issues? And I will state, unequivocally, that engagement is something only an individual can do.

UX is all about communication

Collaboration in UX is more important than in other fields. Why? UX is all about communication. The dangers of insular thinking in UX are that other people can’t relate to our ideas, even if they are good. When people say “an engineer designed this,” it’s not because engineers are stupid or haven’t thought the problem through. It’s because their values (consistency, supportability, development costs) are not the same as the values of the user (easy, intuitive, powerful).

Another feature of UX design is that I’m almost always working on solving someone else’s problem. When we build software, it has to satisfy the customers’ needs and wants. If I don’t bring them in on it, I can spin off endlessly. Feedback allows me to make course corrections instead of starting over. If I’m implementing someone else’s vision, I still need to work in solitude, but collaboration becomes even more vital.

The aforementioned New York Times article does say the following about electronic collaboration: “The one important exception to this dismal record is electronic brainstorming, where large groups outperform individuals; and the larger the group the better. The protection of the screen mitigates many problems of group work.” I agree with the point that the screen shields individuals from some of the drawbacks of social behaviors. But I also think that most internet collaboration requires an individual to be the driver (at least initially), to do the hard creative work that gets the ball rolling. Collaboration allows you to pass the baton between players, cross-pollinate ideas, stimulate thinking and get multiple points of view. Still, progress is made by individuals. Individual progress is improved with collaboration by engaged stakeholders at the right times. (See ‘Lean UX: Getting Out of the Deliverables Business‘ and ‘Our Blind Spot: Creating a Shared Vision‘.)

Andrew Mottaz

Andrew Mottaz is the Founder and CTO of Site9, Inc., the maker of ProtoShare, a leading on-line tool for “collaborative prototyping.”

6 comments on this article

  1. Paula Thornton (@rotkapchen) on

    Andrew: You describe succinctly the fundamental approaches of Design Thinking, working through the ‘possibilities’ — which also includes having done background research to have evidences to ‘debunk’ the many assumptions that will be raised as ‘fact’.

    Indeed, it’s the collaborative aspects of Design Thinking that often is ‘shunned’ by practiced designers. It is based on the fundamental principle that there are all sorts of insights that can be synthesized from the different perspectives of individuals — not just because people think differently, but for a very sound reason: people have different expertises and experiences. We have to rely on each other to all serve as the ‘eyes and ears’ of a collective perspective on things that are happening that will either impact or be impacted by any solution that might be put forth.

    It is this collaborative working through possibilities, by using ‘inspiration’ pieces (thinking like interior decorators) that to me is a focused way of accomplishing more than brainstorming. But there are also specific cases where (as you note) brainstorming is relevant. As I found myself badmouthing brainstorming again today, this showed up in my inbox bit.ly/NeFjem.

    Another critical factor, in addition to the significance of just ‘working through’ ideas collaboratively for the purpose of ‘shared meaning’ (which cannot be underestimated in its value), is the reality that most of the ‘innovation’ that goes on daily in a company is just the normal work that gets done (not the stuff for which meetings are called over). And the value of the artifacts that might get created (documents, spreadsheets, etc.), is often less than the decisions and actions that were taken to get to the results. That’s where preserving the highlights of such ‘conversations’ is invaluable. Assuming that someone can reconstruct same from emails is silly.

    I continue to be dismayed that many popular content management, knowledge management and file management systems do not include the contextual ‘commentary’ that is so relevant to business artifacts.

  2. Andrew Mottaz on

    Thanks for the comment. I think you sum up the main points really well: we need other people for their distinct expertise and point of view, and to get the most out of collaboration, we need others who are engaged, involved, and understand the context. ( I love your point that so much innovation is lost in translation because the context is not communicated ). Thanks for the link on Brainstorming too.

  3. Melissa Leach on

    Fantastic article. I have found that the individual prep work/rumination prior to a group brainstorm always makes a session much more productive (and fun). The challenge for me is how to assertively encourage my team members to see the value in that personal prep work, and then to get them to actually DO it.

  4. Bobby on

    Sometimes “collaboration” is confused with “design by committee” or “consensus”. Collaboration is often not only powerful but is necessary. But in my experience “Design by committee makes a product real sh*tty.

  5. Pingback: Collaboration with ProtoShare | Wireframing Tool - ProtoShare

  6. Pingback: Nonprofits, How We Love Thee (Not!) | Inspiring Generosity