Guidelines for Guidelines
Guidelines are a tool: building a design knowledge management system for programmers (5 years old but still applicable)
1. Designed for developers. Programmers are the users of guidelines. The structure of a tool for them should be built around their needs.
2. Focused around tasks, rather than design elements. The practice of writing software is different from that of designing interfaces, and should be reflected in how documentation for it is structured.
3. Specific, not principles. Programming is an applied art, and specifics address developers’ needs better than theories. Examples that resemble the current situation make it easier to understand the theory and make applying the guideline easier.
4. Prioritized. Design and development is a web of choices, and explicit prioritization helps make some of those choices. Not all guidelines have equal impact.
5. Succinct. Extra words won’t get read and supplementary diagrams will not get examined when the reader is in a hurry, and the reader is always in a hurry.
Originally a case study describing the creation of an internal design knowledge management tool for web developers as a means to encourage user-centered development practices.
