The look and feel requirements describe the intended spirit, the mood, or the style of the product's appearance. These requirements specify the intention of the appearance, and are not a detailed design of an interface. For example, suppose you have a look and feel requirement like this:
This requirement does not say the company logo must be prominent, nor does it talk about the colors to be used. It simply states that the product must comply with whatever branding standards your organization has. These standards are published elsewhereyour own organization has a department or group responsible for these standardsand the designer has access to them. The fit criterion, when you add it, measures compliance with the standards. Consider the look and feel requirements that you might build into your next product. Among other appearances appropriate for your product, you might want it to have the following characteristics:
Software has become a commodity, and the distinction between the functionality of some competing products has largely disappeared. In these cases, the look and feel of one product might give it an edge over a rival. You should also consider the audience for your product (see Figure 8.3). Even when the product will be used in-house, your users have preferences when it comes to the appearance of the software. If your product is for sale, then its appearance is a factor contributing to the customer's buying decision. Figure 8.3.The intended audience for the product largely determines its look and feel requirements. These requirements make it attractive to the audience and sometimes make the difference between a successful product and one that nobody wants to use.
Developers of products intended for the Web should place a great deal of emphasis on the look and feel requirements. Your client has in mind the kind of experience he wants visitors to the site to have. Your task is to determine these requirements and to specify them with look and feel requirement descriptions like these:
Developers of Web products should place a great deal of emphasis on the look and feel requirements.
You might be tempted to describe the required look and feel by using a prototype. However, consider that the prototype does not express the requirement, but rather the result of the requirement. For example, suppose that your client asks for a product "in the company colors." While the prototype may match the required colors, nothing about a prototype tells the designer that the color is important. If the designer chooses to use different colors or a different mix of colors, as well he might, then the requirement for "company colors" will not be met. Thus it is important to write the requirement specifically, and not leave it to someone's interpretation of a prototype. The role of a requirements prototype is to simulate possibilities to help you discover and specify the users' real requirements. If you know your product will be implemented using software, then some of your look and feel requirements can be described by citing the appropriate interface standards.
And here's one other requirement that you should consider:
We repeat: Be careful not to design the interface, because you do not yet know the complete requirements of the product. Designing is the task of the product's designers, once they know the requirements. |