Lean UX (ii)

Lean UX

Design by Consensus.

Although Lean UX doesn’t call it out specifically, there’s moments where the recommendations seem to skew a little bit in the direction of this ineffective practice.

Gothelf and Seiden call this out specifically “Lean UX is a collaborative process…but it’s not design-by-committee”  (page 33). I feel though the process outlined demonstrates an effective way for involving all participants in the design process, they gloss over the difference between “consensus,” “committee” and “collaboration.”

In consensus/committee models, the mode of decision making is “all participants must agree on the solution.” The risks to this are many: the loudest voices tend to win [and often loudest correlates directly with power, years experience]; it tends to produce conservative, status-quo solutions; it subordinates the role of ‘design’ to merely organizing elements on the page [which is not design].

Collaboration models involve divergent voices and allows them to be heard. It gives the designer a great deal of input to work with, but ultimately the designer must make sense of all of these loose ends to create a coherent and consistent product. The big difference in the collaborative design model is that the designer, as the leader, must negotiate the conflict inherent in this process: not everyone’s work will get built. “Feeling heard” is important and creates the model of trust, transparency, and inclusion that Gothelf and Seiden frequently reference. What Lean UX doesn’t go into is how you negotiate the process of working from a collaborative process. What happens when you don’t include the tech lead’s design suggestion? What about the project manager who felt like since a common element emerged on six of the eight activity sheets, that she felt that was what you were going to do?

This is hardly to say that a designer should revert to the ‘hero model’ of design, but I don’t think Lean UX gives the practitioner a helpful framework for navigating what can be very dangerous waters. The process outlined veers a little too close to Design-by-Committee and the text itself becomes a little too “buzz worthy.” Managers and the like might really love the inclusive, collaborative, team-building nature of the process outlined, but designers might find themselves asking “how do I take this methodology forward.” I’m not sure Lean UX necessarily posits an answer here, as Gothelf and Seiden seem more invested in their concept at this point.

I’d suggest the Team Idea Generation step (page 41) be somewhat scaled back a bit. Having the team decide which features to the parking lot, or deciding what ends up in the MVP feels a bit too much like design-by-consensus. The authors even say “to get a consensus, the team will need to prioritize and pare back features.” They start with collaboration and end with consensus.

I’d suggest scaling this part back. Using the terminology suggested, or using the outputs directly in the prototyping process perhaps improperly applies finality to the decisions you make in the process. Don’t ask the team to create a final solution. Let the individual concepts be the end. Talk about the decisions that were made, but instead of trying to piece them together, use tools from your ethnographic methodologies. “Why” and “How” is this a good solution, rather than, “do we agree this is a good solution.” Allowing the team to categorize and prioritize might increase investment, but I think it causes two other unintended side effects: Firstly, the end product is not the result of a cohesive vision of summative understanding of how solutions answer design questions. It’s simply summative. Secondly, this causes your designer to feel somewhat less-invested and less-critical to the process. UX designers must be good facilitators. Certainly. But the value a good designer adds to the process is more than simply aggregating outcomes.

Elderly community members wanted some quiet space; younger kids wanted a skate park: to the community these goals were mutually incompatible. To the designer? These weren’t. Consensus would never have come up with a solution which included both.

This isn’t to criticize collaborative design. Certainly in my time as an urban planner, design charettes were incredibly valuable activities which allowed people not involved in architecture or local governance to articulate clearly what sorts of change they would like to see for themselves and their community. However, consensus rarely emerged from these meetings, because folks with differing hopes and goals rarely can see how all of their needs can coexist.

Take a park for example. Elderly Community Members wanted some quiet space; younger kids wanted a skate park: to the community these goals were mutually incompatible. To the designer? These weren’t. Consensus would never have come up with a solution which included both.