It's all about teamwork in product design. Especially in Agile software development, where the value of engaging team members - from every level and function across the organisation - in the creative process has been clearly demonstrated.
But applying the "more the merrier" philosophy wholesale to every part of your day-to-day design work can cause more problems than it solves. There are points in the product design process when you're better off ditching the entourage and going it alone. The trick is knowing when and how to do it.
Design has no value if it is not collaborative
I'm not sure where it comes from, but there seems to be a popular school of thought, especially amongst those who graduated in the last decade or so, that design has no value if it is not collaborative. I say I don't know where it comes from, but I have some fairly solid ideas.
I suspect that, in part, it comes from the popularity of Design Thinking; a movement that attempts to boil design down to a step-by-step procedural model that can turn even the most hardened corporate terminator into an innovative creative dynamo.
I'm also pretty sure it has something to do with a general misinterpretation of the Agile manifesto. Agile implementations are like arseholes; everybody's got one… only their's is cleaner and more pure than anyone else's.
While it might seem unfair to say that most implementations of Agile feel like a "monkeys with typewriters" mentality, where the wisdom of the crowd philosophy becomes more important than the actual outcome, the truth is: most of the Agile mash-ups I've witnessed fall squarely into that bracket.
Most of all, though, I suspect it comes from the proliferation of product design resources online, created by very large corporate enterprises or public sector bodies who have the time, resources and budget to over-analyse and over-engineer every little nuance of a project.
Not all of us have that luxury. Collaborative hack-days and workshop jollification aren't quite as easy to stage when you're in a business with fewer than 50 employees, and everyone is balls-deep, struggling to keep the plates spinning.
Diamond-shaped for a reason
Wherever it comes from, I see it time and time again, especially in design. People love a good double diamond. It makes them feel like a proper design organisation to have a process they can illustrate on a single sheet of A4, but they quickly forget why it's diamond-shaped in the first place, and not simply a four-step linear process.
[ insert image ]
The problem space
In the Problem space, during the Discovery phase, you want as much input as possible to understand the problem from as many perspectives as possible, which is why it's a divergent phase. You open your net, taking in as much quantitative and qualitative data as you can about the problem and its impact on the business.
This is a great time to pull in your stakeholders; even those detractors and HiPPOs you know will cause problems for you later. Especially them. The more they feel they've been listened to early on, the easier it will be to explain later if and why their ideas didn't quite make the cut. But that's where the collaboration ends in the Problem space. Hang on to those stakeholders for too long, and they'll define the problem for you. They'll dominate the conversation until their opinion is heard over everyone else's.
During the Define phase, you need to cut out the noise, put your objective hat on, and hide yourself away to figure out the real priorities on your own. Then you can decide if your wider data supports the opinions of more influential stakeholders. If you've spread your net widely enough, you should have enough information to confidently define the problem without it becoming a committee exercise. Likewise, you should have enough insight to argue your case with some credibility.
The solution space
The Solution space is no different. Generating initial ideas is a team sport. The more perspectives you have, the better and more varied the ideas will be. Just make sure you've framed your brainstorming sessions clearly with the problem you've defined, and its impact on the business.
Assuming the problem is relevant to your company's broader business strategy, this shouldn't be too difficult. And it pays to make sure you understand that wider business strategy; the fuzzier those high-level business goals are, the harder it will be to keep your gaggle of multi-disciplined creatives focussed on the task at hand.
But once you've collated a bunch of exciting (yet mostly unworkable ideas) and debated the pros and cons of a few leading contenders, it's time to start fine-tuning those ideas into something you can actually build (or prototype, at the very least). This bit is not a team sport.
Design by committee
Democratic design never delivers anything but the safest, easiest, fastest option. Most people are naturally risk-averse, and will simply go with the flow when confronted by a room full of smart people who don't see the world from their point of view. And that's the best case scenario. In the worst case scenario, it delivers whatever the loudest, most intimidating or most numbers-driven person in the room feels is most appropriate. After all, who can argue with statistics?
When it comes to defining what is to be delivered or tested, clear the room, hide in a dark corner and figure it out for yourself. Take into account all the salient opinions expressed in your ideation workshops, but draw the conclusions yourself. Involve only those you need to establish which ideas are most feasible and viable (usually your engineers) given the time and budget constraints you're working within. Beyond that, do it yourself; the Deliver phase is a convergent phase for a reason.
Embrace the party of one
I see a lot of people (not just designers, I might add) continuing the collaborative effort to define the solution as a team, which inevitably leads to the best ideas being filtered out entirely or diluted to the point where every scrap of actual value has been lost to risk aversion and the herd mentality.
The modern design culture might be democratised now, but that doesn't mean it's a free-for-all. Someone has to take ultimate responsibility for what is delivered, and accountability for the impact it has on the broader business, and that can't be a collective thing.
It's yours. Own it.
