Practice 2. Guiding Principles
Guiding principles are a short list of statements that specify overall design goals and requirements. Their intent is not to specify the design but to help team members make daily design decisions that are consistent with the design intent. Some people also refer to them as pillars because they never change, or are not changed in major ways. They are literally the ideas that everything is built upon.
Guiding principles can be thought of as the vision for the design. However, where the vision describes what the project is about, the guiding principles describe how the project should be built. As with the vision, the guiding principles need to be understood and agreed to by everyone on the team, and they should be created before the start of the project. Ideally, they should be placed in a visible place where everyone can see them and even pinned up at everyone's desk.
Two important and distinct guiding principles are recommended (others are possible):
The easiest way to explain guiding principles is by example. Let's use one hypothetical example and one real example.
A Hypothetical Example of Guiding Principles
Suppose an IT project team is faced with the task of having to replace an existing backend system for sales tracking. The existing system has an obscure user interface because it has evolved over many years and users complain that they cannot get the information they need without calling for assistance. The system also needs replacing because it is becoming increasingly hard to maintain. And most important, the system needs to be replaced because it can't handle multibyte characters in the customer name field, yet the company has a growing customer base in China and Japan. The new system must be able to store and display Asian characters.
The vision of this project might be something like:
The engineering guiding principles might be:
Of these guiding principles, you should particularly note words and phrases like "clean 3-tier" and "replaceable." These statements will help ensure that the team is not just groping in the dark toward an end system, but has clear design goals. Even though the team does not have the detailed design at the beginning of the project, these goals will guide team members through every design decision made while the project is developed and help ensure that the end architecture has the desired characteristics. The last guiding principle is a statement that will make the developers think: They should avoid cutting corners and take the time to do things right.
The user experience guiding principles might be:
These statements are tangible and measurable and can be used by the product team to make daily decisions. Each of these principles stresses the importance of a clean transition to the new system in a different way. Their presence will help the team with their daily design work by focusing on usability issues that will ease the transition to the new system.
The vision provides the team with a clear statement of what they are building and why. The guiding principles tell the team how the product should be built, with the user experience guiding principles describing what the user's experience should be like, and the engineering guiding principles describing the "internal" characteristics of the implementation. In this case, the guiding principles describe the important characteristics of the new system that are required to address the deficiencies of the existing system (which is hard to use, learn, extend, and maintain).
A Real-World Example of Guiding Principles
Adobe's Eve (http://opensource.adobe.com) provides an interesting real-world example of guiding principles. Eve consists of a language that is used to specify user interfaces and a cross-platform layout engine. Although the authors do not use the term guiding principles, they do refer to the goals and requirements of the project:
These goals and requirements are guiding principles. They were developed before any code was written and therefore serve as the design vision. They are simple statements that serve as daily reminders for the development team as they make design decisions and tradeoffs. For example, the first requirement ensures that the team creates an architecture that allows existing applications to be converted to using Eve piecemeal. This must have been a challenge to the developers because it implicitly dictates that Eve be efficient and as lightweight as possible so that an application being converted does not dramatically increase in size or decrease in speed.