I'm sure there are others missing: e.g. Speak to user needs and goals rather than feature descriptions and design prescriptives. Read the specs. Read background materials. Stay up to date on the list. But this is a start:

Designs can not be judged on how easily they lend themselves to clean and simple implementations, aka a clear series of declarative statements.

Figuring out a clean and simple implementation that meets design requirements is Engineering's domain of expertise. Designs need to be judged on how easily they are understood by users in the context of how users will interact with the design.

For example:
If a design spec calls for: Tag pictures that have oranges in them as Orange.

The list of declarative statements needed to explain to a computer how to do that is long and complex.

A human on the other hand would find such a task easy to accomplish, although it would quickly become onerous and boring.

Designs need to be evaluated from the perspective of the user and the user experience.

For example, in order to evaluate the comprehensibility of the communication status icons, we need to understand and discuss the context in which the user interacts with those icons:

• What is the user trying to do when they see the icon?
• How does the icon appear to the user?
• Where else is this icon used? Is the meaning consistent? Would it occur to users to associate the two instances?
• What other information do they see when the icon appears?
• What actions are they like to take to clarify the icon if it is confusing to them?

Then, we can have a discussions about whether the user will understanding the meaning of an icon.

Designs need to be evaluated with a shared understanding of Design principles.

If a Designer disagrees with the prevailing Design principle, they must be ready with an alternate philosophy.

Examples of Design Principles:

Design Principle:

• Complexity is not the problem.
• Hiding the complexity and obfuscation are the problem.
• However, complexity must be consistent and contextual.
• For more, see:
  • WhenComplexityIsOkay20040809
  • PrinciplesOfGrok
  • WhyIsDataSoHardToGrok
  • LookingToThePhysicalWorld
  • TheUseOfColor
  • ChunkingOverTime
  • OneUppingNature
• External links:
  • Donald Norman on Google's so-called simple design: http://www.jnd.org/dn.mss/the_truth_about.html

Design Principle:

• A design that helps users understand how the App is implemented = Good design
• A design that does the right thing in the right context = Good design
• And, you don't need AI for that. You can figure out what to do by just listening to the user and understanding the user's needs.

The following does not qualify as a Design Principle

• Designs should be simple (This is too vague and subjective.)

Philippe's Comments

There are a host of issues with this document (starting with its title...). I'm going to try to articulate them as well as I can though the issues are not with the points taken individually but with vertical assumptions and coherence throughout the text.

Domain of Expertise and Role

There's a inherent assumption throughout the document that contributors to the project come with one and one only domain of expertise and therefore a role, specifically, they are either engineers (coders) or designers. I think this is fundamentally wrong. People can (and do) assume a variety of roles in their lifes and jobs with, granted, more or less success. More and more designers assume the role of coders (in web development). Engineer types can also write (blogs, books) and, well, design user interfaces.

In an Open Source environment especially, I don't think a project can be successful if it denies wholesale some capacities to its contributors on the basis of a predetermined role. One can impose that to a hired staff in a traditional enterprise, but in an Open Source process, it just won't fly.

That being said, indeed, when putting their design cap on, engineers should think as designers (following design principles focused on user experience first) not as coders.

Cost

The rules exposed here do not take cost into account. I do believe that design (of anything: car, building, iPods... programs...) must take the cost factor into account or take the risk of hubris. Design is also a matter of compromising between options so the designer cannot simply dismiss a cost argument or refuse to consider a cheaper alternative simply because "it is an engineering issue". This would be irresponsible. A Design needs also be evaluated with respect to its cost.

For example:

If a design spec for a "a low orbit human grade space vehicle" calls for: must land like a plane.

The answer should have been: it's not because planes are the only example of flying things designers have under their eyes they do cost effective space vehicules...

This would have saved the US tax payer a lot of money...

Coherence

The design principles exposed at the end are good. Unfortunately, the rest of the document seems to contradict them.

For instance, while I agree that a good design "helps users understand how the App is implemented", this is not possible if design precedes implementation and refuses to be evaluated with respect to implementation.

BTW, I don't think that implementation must precede design either. In reality, both must interact and dialog so that the design and implementation evolve together so that the user can indeed understand how the App is implemented.

-- MimiYin - 15 Jun 2006