How do you accomplish "good design" in software? There are so many people/roles involved: Product Management, who is supposed to be closest to the customer needs Marketing, who is supposed to be closest to the customers wants/desires Development, who implements everyone else's ideas (and, ironically the farthest removed from the customer) Quality Assurance, who is supposed to be closest to the customers pain threshold Customer Support, who (unfortunately) is many times the only one to actually TALK to a real customer - but only the unhappy ones.
So, how do software companies resolve this? In order to completely understand what we should build, we need input from everyone, right? So, we get in a room and try to convince each other that WE know what would best meet the customers needs, then the developer returns to their computer and one of two things happen: either they implement what they THOUGHT they heard in the meeting, or they implement what THEY believe to be the right thing, regardless of what came out of the meeting.
This is called "Design by Committee", and it never works. It is based on self-referential design, where each person simply puts themselves in the position of "user", and decides how they would like the feature to work.
Frederick Brooks, author of the Mythical Man Month and No Silver Bullet talks about this in terms of "Conceptual Integrity":“Conceptual integrity in turn dictates that the design must proceed from one mind”... “I will contend that Conceptual Integrity is the most important consideration in system design”. He goes on to say that it is the single most important ingredient in success.
Wikipedia describes his idea of "Conceptual Integrity" in this way:
- To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. A "super cool" idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point is that if a system is too complicated to use, then many of its features will go unused because no one has the time to learn how to use them.
Donald Norman, author of The Design of Everyday Things also talks about this concept, He said:
"You don't do good software design by committee. You do it best by having a dictator. From the user's point of view, you must have a coherent design philosophy…The person who's done it best is Steve Jobs, and he's well-known for being a tyrant."In this particular quote, he was referring to Open Source projects, but I believe the concept applies beyond that realm.
Finally, in addressing the same topic, Alan Cooper, author of The Inmates are Running the Asylum, said it this way:
The bottom line is that we need one true "customer representative" who can design the interface for the product, and everyone else needs to operate in a "disagree and commit" mentality. That is, you have a chance to provide your input to a feature, but if the "customer representative" (or "interactive designer", or "product dictator", or whatever you want to call this person) designs it differently, you stand behind it. Having a single design philosophy, or "conceptual integrity", and the right person to own it, works wonders when presenting functionality to an end-user, and maintains a simple user interface without too many "bells and whistles" that detract from the main goal of your application.
“The hypothesis is that better results can be obtained by working in a team with equal representation from users, programmers, managers, marketers, and usability professionals. In my experience, this ‘Seat at the Table’ doesn’t work. The goals and concerns of the members diverge, and the one constituent whose goals are most relevant – the User – is often the poorest equipped to articulate his concern. What’s worse, the programmers – who always have ultimate control over the software-based artifact anyway – inevitably drive the team, usually from the back seat.”