From kde-active Thu Mar 29 17:17:23 2012 From: Thomas Pfeiffer Date: Thu, 29 Mar 2012 17:17:23 +0000 To: kde-active Subject: How to avoid Design by Committee Message-Id: <2215891.xPRpApX0q5 () rabbit> X-MARC-Message: https://marc.info/?l=kde-active&m=133304153214991 Hi all, as announced in my previous mail, here is my idea for reducing the likelihood of "Design by Committee". One disclaimer up-front: I don't want to abolish Democracy. Democracy is an essential part of Free Software and it's not necessarily a bad thing. Everybody's voice should be heard. *But*, democracy should not be confused with "Everybody tosses his opinion in, we mix it all up and get... something". This leads to things that nobody is happy with, as we've just experienced. And here, my favorite author about product design, Marty Cagan, comes in. He is the author of "Inspired: How to Create Products Customers Love" [1], a book which I passionately recommend to everybody who is involved in the creation if digital products in any way. And so far, everybody who read it liked it just as much as I do. On his company blog, Marty wrote an article "Avoiding Design By Committee" [2]. Although I recommend everyone to read the article, here is the gist (already slightly adapted to our situation by me): Product design should mainly be done in a small team consisting of: - The product manager (not sure if we can always have a specific person for that, but it would be great if we did imo) - A development lead - A user experience lead Each member of the team must have the authority and competence to represent a complete perspective (PM for business and market, UX for the user, and Dev for the technology perspective). That way, all perspectives are represented right from the start. And if a specialist needs to be involved for a specific question, the corresponding core member can call him in for that question. Then, when the core team has come up with a design, it has to be presented to the larger group of stakeholders which then have their say. The benefit here is that at this point, the core team should already have considered, discussed and found solutions to at least the more obvious issues. According to Marty, a good product has to be - Useful - Usable - Feasible And only if the core team thinks that all three criteria are met they present their design to the stakeholders. When done exactly "by the book", one team would be responsible for a whole product. However, I don't think this works in a project like Plasma Active. That does not mean, though, that we can't have core teams design specific features. If a small team with a representative for each perspective does the initial design for a feature, they can discuss issues much more efficiently than if they are discussed by the whole PA team. And only if the core team missed an issue or could not find an elegant solution to it does it need to be discussed by all. I wouldn't be surprised if this suggestion provokes negative initial reactions in many of you because it seems to contradict the values of Free Software, but I don't think it does. As I said, I don't mean to exclude anyone. Everybody should have a chance to voice his or her opinion. It's just that finding solutions to issues can be done much more efficiently upfront in a small group. So let's hear what you guys think about it. Thomas [1] http://www.amazon.com/Inspired-Create-Products-Customers- Love/dp/0981690408/ [2] http://www.svpg.com/avoiding-design-by-committee/ _______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active