A Collaborative Approach to Developing Style Guides

ABSTRACT

Keywords

INTRODUCTION

Style Guides have become critical in exploiting the business benefits of GUIs. Although in the graphic design world, Style Guides are not new - many organisations have been using them for decades, but usually only for paper based materials - their application to computer software is still relatively immature.

Shortly after the introduction of the first GUIs the relevant manufacturers started producing Style Guides. The first to appear were developed by Apple for the Macintosh [1], but shortly afterwards both IBM and Microsoft developed Style Guides for Common User Access [2,3] and the Windows [4,5,6] platform respectively. While these guides have gained moderate acceptance, in practice they have not provided developers with sufficient detail; it is still possible to produce radically different user interfaces all of which comply with the relevant Style Guide.

As a consequence, end user organisations have started to develop their own Style Guides which add detail and higher level guidance to the industry standard guides. For these organisations there are a number of motivating factors:

• They may have a large, and growing, number of GUI developments. In some cases, these organisations are trying to build an integrated environment where a number of applications are presented to the end user as a single coherent system. Consistent user interfaces are critical in these cases.
• A lack of consistency between applications is a very clear problem - you don't have to be a usability expert to be able to spot it!
• While the process of applying Human Computer Interaction (HCI) can be viewed as a change in perspective and possibly culture, a Style Guide is something tangible that can be funded and has clear definable outputs.
• The proliferation of different GUI platforms and development tools has increased the risk of inconsistent user interfaces dramatically.

STYLE GUIDES

What is a Style Guide?

• Promote visual and functional consistency within and between different applications;
• Promote good design practice;
• Reinforce company branding or an organisation's public image.

It is well known in HCI literature that consistency is important:

• Once users have learnt how to use one application this knowledge will be applicable to other applications. This will minimise the amount of training required as well as encouraging users to use and explore different applications;
• Consistent applications will help staff to appear confident and competent in front of customers. This will improve the customer's perception of staff service. This is particularly important in customer facing situations;
• Consistency between the applications will allow the different project teams to share code, whether it is via custom controls or some other means. This will not only reduce the implementation time, but also produces less code which in the longer term will be easier and more cost effective to maintain. This is particularly important with GUIs where increasing amounts of code are associated with the user interface.

Consistency can be enforced by standardising on bad as well as good design and one of the necessities of a Style Guide is that it is built on good practice. As the body of knowledge of user interface design expands Style Guides will evolve.

Contents

• Internationalisation might not be an issue for some companies;
• The development methodology used;
• The type of systems and end users involved;
• The level of integration with existing guides.

Benefits

From the end user perspective, the following benefits may be obtained from a Style Guide:

• Reduced errors - less frustration;
• Increased confidence in the system;
• Reduced training requirements;
• Increased morale;
• Improved use of system functionality;
• Improved productivity;
• Reduced resistance to the use of new technology.

• Maintain control over look and feel;
• Control 3rd parties during the tendering and implementation phases;
• Reduce arbitrary design decisions and re-invention;
• Capitalise on learning/iteration;
• Enable production of re-usable software;
• Reduce development time.

• Produce usable systems enhancing customer service/satisfaction;
• Increase market awareness;
• Increase product awareness;
• Reduce training costs;
• Facilitate helpline support;
• Improve staff retention;
• Increase user acceptance of new systems.

REASONS WHY STYLE GUIDES FAIL

• Often the documentation runs into hundreds of pages. The material becomes difficult to use and read. It is ironic that many of the existing Style Guides, aimed at producing usable systems, are themselves difficult to use.
• The guide attempts to be too prescriptive and tackle too many application domains or different types of end users. The result is that it is not appropriate for a number of target applications.
• The document is never updated - either because no one realises that it needs to be updated or because no one is sure about who should update it.
• Little consideration is given to how the Style Guide is introduced into the organisation - there is no supporting material and no one is there to encourage developers to use it. When there are problems there is no one around to listen and amend the guide (if necessary).
• Often the use of the Style Guide alone is perceived to solve the "usability problem". For example, many organisations seem to believe that once a Style Guide is in place no further action is required to ensure usability. The production of a Style Guide is seen as a substitute for iterative design and user testing.
• Another group, or person, is perceived to be responsible for the system's usability and the development team are no longer responsible for the usability of their own system.
• Developers and users are not involved in the content and development of the Style Guide.
• The guide does not address how it should be used in practice or how it should be integrated with development methods.

AN ALTERNATIVE APPROACH

1. Raising awareness amongst developers and end users
   Often it is assumed that both the developers and end users understand the rationale for developing the Style Guide. This assumption is often not correct and leads to misunderstandings later in the process. Including management in this awareness raising process often pays dividends later on.
2. Building consensus
   One of the most successful approaches has been built on the use of a working party consisting of key developers and end users from each of the teams within the organisations. On a weekly basis over a period of 2 months specific topics (e.g. Keyboard Interaction, Navigation, Terminology) are presented to the working party for their review and input. This material is subsequently revised and forms a chapter in the Style Guide.
3. Documenting the Style Guide
   Only once a certain level of consensus has been reached, is the Style Guide documented. This approach ensures that the commitment and understanding of the developers is gained and the best of their ideas are documented.
4. Providing training and support material
   The way the document is introduced into the organisation is critical. The document should be supported by the use of training and support materials. The members of the working party who help develop the guide preferably provide the introductory presentations and the subsequent training.
5. Establishing an environment which enables the guide to evolve
   In many organisations evolution is perceived to be another word for "putting right previous mistakes". The Style Guide should be viewed as a repository for good ideas and this will constitute a body of knowledge which will grow over time. This is often the most difficult part of the approach to control, particularly because it is so dependant on an organisation's culture. The creation of this environment can be facilitated by using presentations, workshops, seminars, bulletin boards and roadshows.

Integrated with the development process
If a Style Guide is to be successful it must be designed to support the development methods being used. One of the most frequent problems with Style Guides is that they do not address the different ways in which they could be used. In fact, frequently the Style Guide is not aimed at supporting any kind of development process.

A critical part of the production of a Style Guide is understanding the development environment and culture of an organisation.

Getting it right in the first place
Style Guides are often used as a means of checking the conformance of a user interface once it has been implemented. While this is a valid use of a Style Guide it is not the most productive.

Our experience is that the Style Guide is best used from the outset of the project. With one organisation that we have worked with the Style Guide is taught to all new Visual Basic programmers. This organisation now has a number of developers that routinely use the Style Guide and would not consider developing a user interface without it.

Allowing evolution
The Style Guide must be based on good practice and as the organisation learns more about what is appropriate in their particular environment this knowledge need to be incorporated into the guide.

This evolution relies on setting the guide in the correct context and establishing a process that deals with requests for change impartially.

Communicate strong visual and functional style
The challenge here is to produce designs which are distinctive, but still conform with the industry standards. Maintaining a distinctive look and feel, while allowing the guide to evolve, presents a significant challenge. In addition, in many organisations their corporate image is constantly evolving.

Encompass relevant platforms and functionality
The scope of the Style Guide may have to be restricted as it is impossible to have a guide which will cover all systems - from back office to customer facing touchscreen systems.

Developed alongside a development team
Often Style Guides are developed in isolation from "real" projects. The result is a Style Guide that is impractical and frequently un-implementable in the chosen development environment. In addition, developers will often resist using the guide because they have not been involved in its production.

Our approach has been to develop the Style Guide alongside a development team and immerse ourselves in a real development project. From the development team's perspective, they receive HCI and graphic design input into their project. From the Style Guide team's perspective we know that the designs are practical and implementable. In our experience, this is the quickest and most effective way of gaining commitment to the use of the guide.

This approach also has the added advantage that this is often the quickest way of ensuring an early success. Once developers realise that the Style Guide can improve their project, other projects are often very quick to follow suit.

Not just a document
Developers do not tend to read large documents. Ultimately we are attempting to change the way software is developed and if we want to achieve this it will be difficult to achieve via documentation alone. In our experience, other communication methods must be used. In the past we have produced:

• Interactive demonstrations to illustrate the look and feel. Some of these demonstrations have a mode which allow developers to browse the layout of the screen to pixel level;
• Checklists to ensure conformity;
• Reference tables for quick reference of critical data. These have been produced as "bumper stickers" which developers have attached to their monitors;
• Competitions to spot the deliberate mistakes in a user interface design. This was originally based on an idea by Molich and Nielsen [7], but later GUI versions were developed;
• Source code, custom controls and property tables which promote sharing user interface code.

Our approach is to provide training, on an informal as well as a formal basis. However, our preferred approach is to work alongside a development team and develop the Style Guide with them. In our experience, this is the most effective and quickest way of developing a practical, usable Style Guide.

Ensuring ownership
This is one of the key factors and often one of the most difficult to achieve, particularly when the Style Guide has been put together by a third party. This collaborative approach to developing a Style Guide greatly helps to produce a feeling of ownership, however, a group or individual in the organisation must be identified as being responsible for the maintenance and updating of the guide. Such individuals often become the focal point for the guide and end up providing developers with ad hoc advice on generic user interface design issues.

DISCUSSION

• Rather than being concerned with document production, Style Guides are about changing culture and influencing developers. If one set out explicitly to change the way people work our first choice would not be to write a document. Style Guides are about winning hearts and minds.
• Style Guides also raise the issue of the difference between analysis and design and the difference in the skill sets required. The majority of HCI is based upon analysis and amongst many practitioners there seems to be a belief that design is just another form of analysis. However, the skills required to design something are very different (although complimentary) to being able to analyse something. For example, can an art critic paint?
• The answer to this particular issue lies in the combination of graphic design and HCI - neither party has the total answer - but both are holding different pieces of the same jigsaw puzzle.
• It is important that Style Guides are positioned properly in the development lifecycle. It is also important that their limitations are fully understood. On a number of occasions Style Guides have been seen to be the panacea to an organisation's usability problems. Whereas a clear definition of a systems requirements might have been more appropriate.
• A number of practitioners seem to perceive their role to be one of policing a Style Guide. While this is a valid role on certain occasions (and only then when accompanied with constructive criticism), a much more positive role would be for the practitioners to help get the design right from the outset. This again raises the issue of the difference between analysis and design.
• The Style Guide should be well presented and easy to use. It is ironic that many commercially available Style Guides are difficult to use - either because of poor structure or layout.
• The guide should be designed for the intended use - it should be easy to read, cross referenced and ideally available in softcopy.

• Many of the benefits of a Style Guide are not directly related to the guide itself, but are the consequence of ensuring different implementation activities are co-ordinated. As a consequence of the production of Style Guides one organisation decided to set up a database of error messages (once they had been sorted out for one application the customer decided to share them across applications) and of custom controls (where different custom controls are used to perform very similar operations).
• Be aware of the pitfalls. The majority of them are related to the soft side of implementation and there are a number of ways of avoiding them, e.g. making sure the key influencers are involved, making sure the views of the end users are taken into account.
• Make sure developers feel involved throughout the lifecycle. It is important that the developers feel that the Style Guide is theirs and it has not been imposed on them by senior management.
• Standards are often perceived as boring, out of date, old fashioned and slowing down development. If the Style Guide is perceived in this light then it is unlikely to succeed.
• Appropriate development methodologies for GUIs are still emerging. In many organisations different development teams are using different methods, in some cases it almost seems as if they are making it up as they go along on a per project basis. This makes it very difficult to integrate a Style Guide.
• Style Guides also have a role in end user involvement. Frequently, the difference in vocabulary between developers and users is so great that it can become a barrier to forming a successful partnership. Style Guides, because of their very graphical nature can help solve this problem.

CONCLUSION

This paper outlines a collaborative approach to developing Style Guides. We have used the term collaborative because if the Style Guide is to be successful then it must be developed in conjunction with the software developers and end users. This approach has been used successfully with a number of different commercial organisations.

ACKNOWLEDGEMENTS

REFERENCES

1. Apple Computers, Inc. Macintosh Human Interface Guidelines. Addison-Wesley, Reading, MA., 1992.
2. IBM Corporation, Common User Access: Advanced Interface Design Guide. IBM, 1989. (Part no. SC26-4582).
3. IBM Corporation, Object-Oriented Interface Design: IBM Common User Access Guidelines. QUE. 1992.
4. Microsoft Corporation, The Windows Interface: An Application Design Guide. Microsoft Press, Redmond, WA.,. 1992.
5. Microsoft Corporation, Microsoft Windows 95 User Interface Design Guide: Preliminary Draft 5.00. Microsoft Corp. October 1994
6. Microsoft Corporation, The Windows Interface Guidelines for Software Design. Microsoft Press, Redmond, WA., 1995.
7. Molich, R. and Nielsen, J. Improving a Human-Computer Dialogue. Communications of the ACM, 33(3), (March 1990), 338-348.

srg_txt.l Stephen Gale Created 21-12-95