Participatory Design Tips for UX Pro’s

So, there’s a lot of heated debate over participatory design, and if it’s really a wise idea in the software and SaaS worlds. This sort of design concept has been argued against by many, claiming the “too many chefs in the kitchen” cliché as defense in their dissent. Well, if mismanaged, I could see how that could very much be a problem with this design philosophy in fact. However, there are so many benefits to be potentially had with participatory design if it is managed and handled properly, and these benefits do stand to possibly alleviate issues existing in the traditional design phase and environment therewith. So, maybe, just maybe, if we can look at this design philosophy with the means of managing it right so that all the chefs don’t over-season the stew unsupervised, we can harness this unique approach for the benefits it has, without the dangers naysayers do rightfully cite at this time. So, how can we implement this without the problems of chaos and bedlam that many logically fear it could bring about (and in the past, indeed has)? Let’s first take a page from the stories of scenarios where it actually has worked, without even intending to necessarily embrace it as a philosophy. Design communities with participatory mentalities are actually pretty common, just not in the corporate or business worlds. Looking at open source development communities, one sees a wealth of projects being contributed to in this way – with the original creators and capable users contributing to frequent builds in whatever way they can, be it voluntary testing, design, input or code contributions. But, those aren’t businesses, so what can we and can’t we take away from that sort of case? What we can learn is that encouraging participation from everyone who is even slightly causally involved is a good idea, and a way to tap resources and fill voids. We can also take away the “find your own way to contribute” mindset that sidesteps “people who can’t program trying to” etc. issue. What we can’t take from this is the lack of regimentation these communities have. In a business environment where we apply this philosophy, we need to take what we said we could from above, and then handle it as such: First, everyone should find out how they can contribute. Design and feature ideas, testing, programming, whatever their talent may be (anyone who can’t do anything else can always test). And then, we form teams of these people, just as with a normal development and design environment, and place someone at the head of each. Issues are resolved, and handled internally, and then, the heads of these groups come together, with those of the main groups, for interchange and application where viable. This congregates everyone into regimented groups where everyone is still helping, ergo the product or design is absolutely matching the criteria of the target demographics and meeting stakeholder expectations, because these people are helping to design it. However, with a regimented compartmentalization of their presence in place (often disregarded in participatory design as a result of people thinking it antithetical to the philosophy), the chefs can’t ruin the stew, you see!