Managing the use of style guides in an organisational setting: practical lessons in ensuring UI consistency

Interacting with Computers 11 (1999) 323–351

Managing the use of style guides in an organisational setting: practical lessons in ensuring UI consistency Nichole Simpson* Corporate Solutions Consulting (UK) Limited, 84-88 Pinner Road, Harrow, Middlesex HA1 4LQ, UK Received 1 January 1998; received in revised form 1 July 1998; accepted 1 November 1998

Abstract This paper explores the use of Corporate Style Guides as a mechanism for managing consistency at the user interface. The software design community is becoming increasingly aware of the value of Style Guides in promoting consistency and usability in designs. Style Guides form a valuable reference point and management tool, and can offer particular advantage in cases where distributed or outsourced design and development groups exist. Style Guides also fill a gap in the development process, providing advice more specific than the guidance contained in published standards, and more general than the design specifications of a single system. They provide opportunities for the improvement of group design activities and overcoming the limitations of an individualistic approach. Style Guides can be shown to deliver tangible financial benefits to organisations through the promotion of consistency of design. However, it is recognised that the process of managing the use of Style Guides is not well defined. This paper draws on lessons learned from a range of projects concerned with providing Style Guides and Style Guide management processes in commercial and industrial settings. 䉷 1999 Elsevier Science B.V. All rights reserved. Keywords: Corporate style guide; User-interface design; Cost–benefit analysis; Consistency of design; Conformancy checking

1. Introduction Style Guides and user interface (UI) consistency have been discussed in Human Factors and Software Development circles for the last 10 years (e.g. [1]), and the cost benefits associated with achieving consistency have been widely acknowledged [2–4]. Over the past five years the uptake of Style Guides by organisations undertaking internal development of applications, or customising commercial (packaged) software has seen a dramatic increase, as evidenced by our own work and also reports from others in the field [5–7]. * Tel.: ⫹44-181-4277795; fax: ⫹44-181-4277801. E-mail address: [email protected] (N. Simpson). 0953-5438/99/$ - see front matter 䉷 1999 Elsevier Science B.V. All rights reserved. PII: S0953-543 8(98)00069-1

324

N. Simpson / Interacting with Computers 11 (1999) 323–351

One interpretation of this is that it is an indication of the success of the Human Factors community in promoting and delivering the benefits of consistency. The importance of assessing consistency against project objectives, rather than defining it as an unequivocal standard to be pursued at all costs has been discussed [8]. However, the ability to define and pursue consistency in a relevant manner depends upon effective processes for managing the introduction and use of Style Guides, including conformancy checking procedures. To date these procedures have been absent or their importance have been difficult to convey to users [5,9,10]. Inconsistency may arise for a number of reasons associated with the development process including inadequate specification of design objectives, failure to understand user requirements, mis-identification of common functionality, mis-classification of generic design modules, and inadequate design specification. Inconsistency may also arise because of organisational factors such as distributed design and development groups, outsourcing of development tasks and lack of design or management expertise. Style Guides are a form of standard that assist in managing the development process, including addressing inconsistency. Style guides offer the following [2,5]: • Design management tools, offering opportunities to improve the efficiency and effectiveness of design activities; • A set of processes to support organisational learning—collecting and refining design experience in relation to the specific organisational context; • A common reference point for designers, developers (internal or external) and users, thus facilitating communication; • Authoritative specification of re-usable application controls such as menu bars, list boxes, command buttons and higher level task components; • Guidance about the selection and detailed design of controls and input methods; • Design principles to provide guidance in the absence of specific task knowledge; • Input to design assessment activities and processes. Even in the fast changing world of the world-wide web the need for style guides offering advice on how to achieve a level of consistency and orientation for users has been acknowledged [11–13]. However the prevalence of awards for ‘‘exciting’’ and individual designs, and the popularity of attention-grabbing plug-ins suggests that widespread awareness of the benefits of consistency has not yet been achieved in the world-wide web community. Mechanisms are required for managing consistency across corporate-wide suites of applications to enable integration and allow users to operate effectively with a range of products. Corporate Style Guides focus on common functionality and basic user-interaction styles which should be observed at a global level. Application Style Guides provide more detailed guidance focusing on specific product requirements such as the need to support identified user tasks. Guidance at this level should be congruent with a wider organisational style, but must also provide a mechanism for identifying, recording and implementing style divergence where required. Corporate and Application Style Guides are addressed in this paper, and the relationship between the two is illustrated in Fig. 1. Significant effort has been made in persuading organisations to examine their own

N. Simpson / Interacting with Computers 11 (1999) 323–351

325

Fig. 1. Corporate and application style guides.

processes and expend effort and resource in developing customised Style Guides which reflect the needs and objectives of the organisation and make these accessible to users through appropriately defined interfaces [14–16]. This paper argues that while this is necessary it is not sufficient in the delivery of consistent and usable systems. More effort must be made to define conformance and management procedures to increase the efficacy of Style Guides and the success of design activities undertaken.

2. The value of consistency The user interface provides the sole access point through which users can access system functionality. It is through the user interface that users harness system power to enable them to achieve their tasks and contribute to an organisation. For a user interface to be used effectively, it is highly desirable that it demonstrates a high degree of consistency, so that developers, users and the host organisation can benefit from standard tools with standard behaviours that enable people to work as productively as possible [6,17,18]. The features that comprise a user interface should be described by a set of generally applicable rules. These rules may address many aspects of the interface at many levels. The pursuit of consistency has far reaching effects including how the system behaves when it returns the results of user requests, the visual aspects of the presentation of information and controls, the syntactic requirements placed on the user in terms of how units of

326

N. Simpson / Interacting with Computers 11 (1999) 323–351

interaction are assembled and input, and the semantic environment involving tokens of meaning and their interpretation in relation to user goals and objectives. Consistency also operates within and across systems, and when evidenced at the user interface, allows users to generalise their skills and move confidently between applications, carrying out their tasks effectively and efficiently. This results in users being more productive, requiring less training, working more accurately and being more satisfied with the system. Consistent user interfaces have been shown to be inherently more usable [1,19,20]. The application of a Style Guide can deliver value to parties at many levels of the organisation. Some likely benefits include: 1. Users • Reduced learning overheads as generic principles can be applied across products and procedures transfer [21,22]; • Skills transfer between applications; • Confident use of the full functionality [23]; • Improved productivity [18]. 2. Organisation • Productivity improvements; • Reduced training costs; • Re-usability of design components to reduce the costs of subsequent projects. 3. Project Managers • A standard for guaranteeing the quality of deliverables from external suppliers; • Reduction of duplicated design effort; • Common reference point and mechanism for co-ordinating activities across groups. 4. Developers • Source of guidance as to good design practice [24]; • The opportunity for reuse of user-interface components and associated code thus enhancing developer productivity [25,26]. These benefits can translate into financial savings for an organisation, and satisfy the need for a cost–benefit based justification for the pursuit of consistency. The kinds of savings which can be attributed to consistent design are illustrated in the following examples. Design activities focusing on ensuring the consistency of a replacement information system, in line with clearly defined user requirements resulted in the following savings [4,27]. The user population numbered 22 876 and interacted with the system 12 times a day on average. The design activities are estimated to have provided a saving in excess of 4.5 min per day for three main tasks. This resulted in excess of 1500 h of effort with an associated cost saving of $40 000 per day.

N. Simpson / Interacting with Computers 11 (1999) 323–351

327

Similarly impressive savings have been illustrated in the areas of training and error prevention [2]. In recent projects conducted in the legal market, we have observed the following indications of potential savings. Although post-implementation measurements were not taken to confirm these savings, initial project estimates and available data obtained through usability and user-acceptance testing indicate that the desired benefits for users and managers are achievable. 2.1. User productivity Provision of consistent, usable searching functionality to legal professionals reduced document query turn-around time from 2 h to 5 min, and saved 30 min per search per user in terms of disruption to trains of thought. For a population of 1000 legal professionals at a charge-out rate of £100 per hour, assuming that 10% of users use the system for document queries, and assuming one search per user per day, the following savings might be expected: £1.70 fees per minute × 30 min × 100 users ˆ £5100 savings in lost fees per day. 2.2. Management effectiveness A reduction in the length of design review meetings, and subsequent design modifications might be expected to save a project manager 10 days effort over the course of a six month project. At a daily rate of £500 this would be a saving of £5000 for the project manager’s time alone. In terms of savings associated with avoiding delays in system delivery and roll-out through the need to amend inconsistent designs, the savings would be much greater. 2.3. Developer effectiveness Assuming the identification of common design modules, suitable for re-use across three related business infrastructure projects, and assuming a development time of 10 days for the original module, and one day modification for each re-use, the following savings might be realised: • Nine days development time saved for each subsequent project. • Daily rate for development staff £400 per day. • Estimated savings across the latter two projects ˆ 18 × 400 ˆ £7200. Such benefits show that Style Guides can form a valuable part of any development infrastructure. Organisations wishing to construct such justifications for the development of a Style Guide, or wishing to measure process performance should develop a benefits

328

N. Simpson / Interacting with Computers 11 (1999) 323–351

framework in a collaborative process involving all stakeholders. Operational data should be collected to substantiate benefit claims. The key benefits should be documented and used to drive other project decisions including delivery and implementation vehicles. In this way what is often seen as the rhetoric and empty promise of a cost–benefit assessment can be transformed into an engineering exercise and can be used as part of the quality control measures which are brought to bear in any product design/procurement lifecycle. Many cost–benefit calculations have been examined in detail in recent literature [28,29], and it has been shown that even experienced users of a system can lose up to 10 min a day of productive time owing to usability issues such as inconsistency [20,30]. The opportunities for such cost savings provide a strong case for identifying mechanisms for managing consistency. The rest of this paper will illustrate how management processes can be used to support Corporate Style Guides, and how they contribute to the realisation of such tangible and quantifiable benefits.

3. Choosing a type of style guide to suit a purpose Style Guides embody a specific set of design guidelines and exemplars, based on knowledge of a business’ strategic objectives, specific operations, Information Technology (IT) strategy and user population. This knowledge is applied to the design process to guide decisions and promote consistency and usability within and across developments. Designing consistent and usable systems which support users and engender them with confidence is not a simple task. The challenge to designers is to ensure a consistent fit between the users’ needs and the systems being delivered. This means that design decisions must be informed by knowledge of the users, their tasks and organisational conventions. Across distributed design groups, or in situations where design is being outsourced, this can be difficult to achieve. Style Guides can provide this information as they are based on a knowledge of the specific requirements of an organisation. Guidance in support of design activities can be provided at three distinct levels. A commonly used type of design support is the commercial Look and Feel Guide. However, these can only offer limited support owing to their generic nature. More specific and effective guidance can be incorporated into Corporate Style Guides and Application Style Guides. The use of these will be described in detail. 3.1. Look and feel guides (for specific interface environments) At this level design rules are presented which will allow designers and developers to produce designs consistent with the general characteristics of an environment. Such guides are generally referred to as Look and Feel Guides. Using the Microsoft Windows Look and Feel Guide, for example, would allow a developer to ensure that all interface components utilised in a design were consistent with the Windows style exemplified by Microsoft products. Look and Feel Guides are totally generic, and are not informed by specific user population or task structure information.

N. Simpson / Interacting with Computers 11 (1999) 323–351

329

Example topics from a Look and Feel Guide • Input basics • Windows • Common types of windows • Window controls • Window operations • Menus, controls and toolbars • Working with OLE embedded and OLE linked objects The level of generality of advice present within Look and Feel Guides means that style rules are open to a high degree of individual interpretation. Figs. 2–4 indicate three alternative designs which are all compliant with the Microsoft Windows 95 Look and Feel and yet show very little consistency. The application illustrates a system for batch processing of bills. The user is required to select specific bills from a list and post them to a ledger. Across the designs the following inconsistencies can be observed: • • • •

Distribution of function between menu bars and command buttons; Positioning of controls such as command buttons; Size and labelling of data area (multi-column list box); Selection of list controls (single list versus paired list boxes).

Examples of existing rules from the Microsoft Windows 95 Look and Feel Guide [31] which pertain to the major interface controls used in Figs. 2–4 are reproduced below. As can be seen the rules are loosely articulated and in some cases might even appear to be contradictory. Usability issues cannot be adequately addressed as no task or user knowledge can be incorporated into such a generic guide. As a result designers are not facilitated in disambiguating the rules, and different interpretations arise which lead to design inconsistencies.

• Advice on the use of menu bars • ‘‘The content of the menu bar and its drop-down menus are determined by the functionality of your application and the context of a user’s interaction. You can also optionally provide user configuration of the menu structure, including hiding the menu bar…’’ • Advice on the use of list boxes • ‘‘List boxes are best used for displaying large numbers of choices that vary in number or content.’’ • ‘‘List box controls do not include their own labels. However, you can include a label using a static text field; the label enables you to provide a descriptive reference for the control and keyboard access to the control.’’

330

N. Simpson / Interacting with Computers 11 (1999) 323–351

• ‘‘Make the list box wide enough to allow the entries in the list to be sufficiently distinguished.’’ • ‘‘Order entries in a list using the most appropriate choice to represent the content in the list and facilitate easy user browsing.’’ • ‘‘Include a horizontal scroll bar. However this option reduces usability because adding the scroll bar reduces the number of entries the user can view at one time. In addition, if most entries in the list do not need to be horizontally scrolled, including a horizontal scroll bar accommodates the infrequent case.’’ • ‘‘When incorporating a list box into a window’s design, consider supporting both command (cut, copy and paste) and direct manipulation (drag and drop) transfers for the list box.’’ • Advice on the use of column headings • ‘‘Using a column heading control, also known as a header control, you can display a heading above columns of text or numbers. You can divide the control into two or more parts to provide headings for multiple columns.’’ • ‘‘You can control each part to behave like a command button to support a specific function when the user clicks on it.’’ • Advice on the use of command buttons • ‘‘Stack the main command buttons in a secondary window in the upper right hand corner or in a row along the bottom.’’ • ‘‘If a particular command button applies only to a particular field, group it with that field.’’ • Other relevant advice • ‘‘A group box is a special control you can use to organise a set of controls. A group box is a rectangular frame with an optional label that surrounds a set of controls.’’ • ‘‘Always include a label for every control.’’

N. Simpson / Interacting with Computers 11 (1999) 323–351

331

Fig. 2. Design illustrating the inconsistency which can arise even when a look and feel guide is applied.

Fig. 3. Design illustrating the inconsistency which can arise even when a look and feel guide is applied.

332

N. Simpson / Interacting with Computers 11 (1999) 323–351

Fig. 4. Design illustrating the inconsistency which can arise even when a look and feel guide is applied.

Inconsistencies through the use of generic guidelines can occur at many levels within and across designs. In designs that we have examined we have found many common types of inconsistencies, the following are just some of the examples: • Modal inconsistency – e.g. the Alt D key combination being used for ‘‘delete’’ in one part of an application and ‘‘page down’’ in another; • Labelling inconsistency – e.g. command buttons variously labelled ‘‘Close’’, ‘‘Cancel’’, ‘‘Exit’’, etc; • Terminology inconsistency – specific user terminology used interchangeably or incorrectly, e.g. ‘‘Matter’’, ‘‘Project’’, ‘‘Engagement’’; • Icon inconsistency – e.g. the wand symbol sometimes providing access to the function ‘‘new…’’ and other times indicating a special format tool. The use of a Look and Feel guide can therefore guarantee little in terms of managing consistency on task-specific basis. 3.2. Corporate style guide These documents provide style rules informed by a knowledge of the specific organisation. Information on the user population, organisational infrastructure and generic business areas can be included to ensure that the rules are more focused and specific. Corporate

N. Simpson / Interacting with Computers 11 (1999) 323–351

333

Style Guides may include guidance on fundamental support modules such as navigation, feedback, help, organisation-specific terminology and symbology. Corporate Style Guides provide a framework so that applications bear a strong ‘‘family resemblance’’ and operate in an integrated and cohesive way. The SSADM user group define a Corporate Style Guide as: ‘‘A document which defines the consistency standards that will be followed by the user interfaces of a range of applications. It needs to include [32]: • • • •

Standards for the user interface and some supporting rationale; Guidance material for educating developers; A conformance checklist for critical areas of the standard; An explanation of the overall structure and framework for an application’’. The development of a Corporate Style Guide requires the following inputs:

• • • •

Corporate Objectives; Platform/Infrastructure Decisions; Knowledge of stakeholders’ needs and objectives; A framework provided by Look and Feel guides as appropriate to the corporate IT Strategy; • Design rationale from existing application design style guides (optional). Example topics from a Corporate Style Guide • Interface processes • • • •

Confirmation Process Sequence Validation Default Behaviour

• Navigation • • • • •

Navigation models Inter-application navigation Application navigation Forms navigation Field navigation

• Common functionality • Searching • Browsing hierarchies • Sublisting • Corporate icons and terminology The examples below are drawn from the Home Office National Strategy for Police

334

N. Simpson / Interacting with Computers 11 (1999) 323–351

Information Systems. As part of the strategy a ‘‘Corporate’’ user-interface style guide was produced to guide the development of all police systems. The examples illustrate how a Corporate Style Guide can provide guidelines relating to organisation-specific tasks. In addition, specific and contextually relevant figures can be produced which give life to the design rules. Such a level of guidance disambiguates many of the low level design decisions which cannot be adequately covered by a Look and Feel Guide, and promotes acceptance by developers by providing them with meaningful illustrations of the standard. For example, in the case of police applications, it was determined that many users’ tasks would involve creating subsets of existing lists, and that the creation of structured records through form filling would require the status of text fields to be clearly indicated to users. To fulfil these requirements, the following rules and examples were made explicit in the NSPIS Corporate Style Guide [33]. Status of Text Fields There are two ways to classify single-line Text Fields: whether the field is editable or not, and whether it is mandatory or optional. These two factors are often confused and misused but are an essential issue in NSPIS applications. The Police use many applications that require data entry fields and this section sets out a standard by which these fields can be classified thus preventing any conflicts. It cannot be stressed enough how important it is to follow these rules given the amount of time and effort that is spent developing such applications and entering/viewing data in them. If these rules are followed rigorously, form design will be easier, faster, and the user will benefit from the consistency across applications. • • • • • • • • • • •

Editable fields can be identified by their white backgrounds. An Editable field can have input focus. Data can be added to Editable fields or the contents changed. Non-Editable fields have grey backgrounds. Non-Editable fields do not receive the input focus at any time as their contents cannot be changed directly. Non-Editable fields must not ‘‘disappear’’ or be hidden at any time. Mandatory fields require the user to enter data in order to complete a task. Mandatory fields are characterised by their light yellow backgrounds. Data validation is performed when a user exits a field which requires particular values. Optional fields have a white background and do not have to be filled with data before completing a task. In instances where fields can be both Mandatory and Non-Editable, display the editability status of the field.

Fig. 5 summarises the conventions for formatting text fields. In comparison, the following extract is taken from the Microsoft Look and Feel Guide [31]. As can be seen, no guidance is provided for indicating mandatory fields and the guidance provided for non-editable or read-only fields is lacking in detail.

N. Simpson / Interacting with Computers 11 (1999) 323–351

335

Fig. 5. Indicating the status of text fields.

‘‘The standard text box control provides basic text input and editing support. Editing includes the insertion or deletion of characters and the option of text wrapping… You can also use text boxes to display read-only text that is not editable, but still selectable. When setting this option with the standard control, the system automatically changes the background colour of the field to indicate to the user the difference in behaviour.’’ Creating Sub-lists There will be occasions when the users’ tasks involve making multiple selections from a list. This will be required most frequently when the user needs to apply some action to a sub-set of items from a list. Where possible, a paired set of list boxes should be used so that the user can view the items which have been selected from the entire list, and so that the order of selection is captured and made available. • Where users are required to make multiple selections from a list, then use two sublists with Command buttons for moving items between the two lists. The Command Buttons are to be labelled ‘‘Add Ⰷ ’’ and ‘‘ Ⰶ Remove’’. An example of list boxes used in this way is provided in Fig. 6 [34]. In comparison, the Microsoft Look and Feel Guide contains no guidance relevant to such a task, and does not describe the use of paired lists. 3.3. Application style guides These documents provide more detailed and specific guidance at the application level. Detailed task requirements and consistency issues informed by a knowledge of the data types and volumes to be handled may require more in-depth style guidance, or may suggest the need to deviate from the high level corporate guidance. Such issues are within the remit of an Application Style Guide. The SSADM user group define an Application Style Guide as: ‘‘A project specific document which defines the consistency standards that will be followed during user-interface development. It documents the areas of agreement that have been reached on a project, and any justified changes to the [Corporate Style Guide]. It needs to include [32]:

336

N. Simpson / Interacting with Computers 11 (1999) 323–351

Fig. 6. Supporting the creation of sub-lists.

• Specific project standards for the user interface that take into account the constraints of the implementation tool; • A conformance checklist for critical areas of the standard; • Detailed naming and layout standards.’’ Example topics from an Application Style Guide • • • • •

Bespoke controls Intra-application navigation Window management Colour coding Common functionality    

List ordering Search criteria and results Boolean operators Wildcards

The range of applications under development within an organisation at any one time, or under one initiative, is potentially vast. Current applications being developed under the NSPIS banner for police forces in England and Wales include [34]: • • • • • • •

Accounting Case preparation Civil claims Command and control Complaints Contract management Crime and incident reporting

N. Simpson / Interacting with Computers 11 (1999) 323–351

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

337

Crime pattern analysis Criminal investigations Custody Escort planning Finger prints Fleet management Force reference database Geographic information Home Office Large Major Enquiry System (HOLMES2) Inspections Intelligence Legal database Maintenance Management planning and information Messaging Names Office automation Operations planning Payroll Personnel management Photograph and tape library administration Police fire arms log Property register Public relations Resource allocation Traffic management Training administration Vehicle procedures Vehicles Warrants

While there are common elements which will be present in all applications (as captured in the NSPIS User Interface Guide), there are many very specific, low level pieces of guidance applicable only to single application modules. These are best dealt with by an Application Style Guide. This point is indicated in the introduction to the HOLMES2 Application Style Guide: ‘‘This document is the Application Style Guide for HOLMES2 development. That is, it is specific to HOLMES2 as opposed to being applicable across all NSPIS developments. However, this document was prepared to be upwardly compatible with the NSPIS Style Guide. The NSPIS Style Guide and all other Style Documents including the Interactive Style Guide need to be used alongside the HOLMES2 Style Guide.’’ ‘‘By Application Style Guide is meant a guide or standard that addresses the idiosyncrasies and functionality of a specific application. Therefore by

338

N. Simpson / Interacting with Computers 11 (1999) 323–351

definition it does not repeat material available in the NSPIS Style Guide’’ (HOLMES2 Application Style Guide, 1996.) An example of style guidance specifically relevant to the HOLMES2 application is provided in the following. The advice relates to the graphical annotation and indexing of documents such as statements. Indexing and Annotating Documents ‘‘The updating of HOLMES 2 is driven from documents. These may be messages, statements, house to house enquiry forms, officers’ reports, etc. Some of these documents will be available on the system as images or in electronic form. In addition these images may include annotations. Annotations on documents will be denoted using markers. These markers must convey a number of attributes. Markers must convey both the text of interest and the index to which the annotation refers. A complicating factor is that the same piece of text may be annotated multiple times. Single underlining will be used to indicate the text to which an annotation refers. For each annotation a separate marker is provided. Therefore a piece of text that has, for instance, an associated nominal and category annotation would be underlined once but two markers (icons) would be provided with it. Markers will be displayed as superscript symbols. So for instance, a piece of text might be underlined. At the end of the underlining there would be a superscript symbol to indicate the index to which the annotation refers. For example, a and a location using a . Nominal annotation will be indicated using a Importantly these markers are colour coded as discussed later. Once a document has been indexed, then index reference numbers will be added to enable records to be uniquely identified and their source to be traced. The readability of text should be maintained at all times as far as is possible. It will not be acceptable for statement readers to strikethrough a piece of text to indicate that it was dealt with. It is desirable that the text displayed on-screen be formatted in the same manner as the hardcopy of the documentation. That is, the inclusion of markers should have no effect on the word wrapping in the document. To achieve this, allowance for additional annotations will have to be made when allocating space for the textual content of documents. Achieving this will permit users to make direct comparisons when necessary between prose presented on-screen and its hardcopy equivalent. The text must always be readable.

N. Simpson / Interacting with Computers 11 (1999) 323–351

339

The content of an annotation must be accessible via a right mouse click on a marker. This will result in the display of a Pop-Up menu offering the user options including the displaying of the annotation text. Once a record has been created or modified (based on an annotation to a document) the annotation mark must be amended to indicate that it has been dealt with. This will be achieved by adding text to the marker in superscript. This text will be the unique identifier for the record created or updated. Double clicking on an annotation will retrieve the associated record. It should be possible to view all documents in annotated form and without annotations.’’ An Application Style Guide allows specific design guidance to be captured once, early in a project, and subsequently utilised by all members of a development team. An Application Style Guide is not the same as, and does not replace, a user-interface design specification, rather it is an aid to producing a high quality and consistent design in the most efficient manner.

4. Developing a style guide The development of a Style Guide must be integrated into the system development lifecycle in the case of an Application Style Guide, or into the organisation’s Information Systems (IS) strategy in the case of a Corporate Style Guide. Whilst the case can convincingly be made for moving from a Look and Feel Guide to a Corporate Style Guide, with its increased specificity of advice and guidance, it can be less easy to determine whether efforts should also be expended on Application Style Guides. Corporate Style Guides represent a strategic investment, and are essential for the provision of a framework within which global consistency can be achieved. However, time pressures, or the perceived value of an individual application (in terms of volume of users or criticality to business operations) may suggest that the more tactical approach of developing an Application Style Guide alone is adopted. There is no hard and fast rule over whether an organisation should develop a Corporate Style Guide as a pre-cursor to specific application style guides, or as a result of lessons learned from individual projects. The former approach requires that the Corporate Style Guide be informed by, or even seen as part of, the organisation’s Information System Strategy. The latter approach can be seen more as a consolidation exercise. Once a Corporate Style Guide has been defined however, all application developments must use it as their first reference point. Any requirements for deviation from the Corporate Style Guide must be documented, justified, signed off, and fed back into the Corporate Style Guide where applicable. In this way not only is consistency managed, but the benefits of individual design solutions which deviate from the standard design space are not lost. The activities that should be undertaken during the development of a Corporate Style

340

N. Simpson / Interacting with Computers 11 (1999) 323–351

Guide are listed: • • • • • • • • • •

Agree the scope of the deliverables; Agree the audience for the Style Guide; Review general Style Guides; Interview key stakeholders; Agree the Style Guide’s content; Produce, review, modify and publish Style Guide; Produce, review, modify and publish Quick Reference Guide; Produce conformancy checking documentation; Produce change control procedures; Produce seminars, handouts and other awareness materials.

Fig. 7 indicates where the development of an Application Style Guide best fits within the development lifecycle. The Application Style Guide takes user task modelling activities as its primary input. These include specification of the users, identification of critical and frequent tasks and high level task content. The Style Guide is used to inform userinterface design decisions, and in turn may be modified in light of detailed issues which emerge from the design process. The Style Guide should also be informed by the results of prototype evaluation activities, which may identify required modifications to existing designs. Once a Style Guide has been developed it cannot be regarded as a static entity, rather it must continue to develop in line with any organisational and strategic changes. For this reason, supplementary procedures and materials must be developed including change control, conformancy checking and other management procedures. The effort required to develop and administer these is often underestimated by an organisation, and in some cases (such as large organisations or critical applications) may require the creation of a dedicated role. These issues are dealt with in more detail in the following sections. 5. Using a style guide It is not until a Style Guide reaches the stage of being used within an organisation that the benefits can begin to be realised. However, even at this stage, a number of enabling or facilitative activities need to be undertaken. The following factors have been identified as contributing to the failure of Style Guides [9]: • Lack of consideration of how to introduce the document into the organisation; • Lack of guidance as to use and integration with development methods; • Lack of procedures for updating the document. The following management processes and activities will help to safeguard against such failings. 5.1. Sponsorship The mere existence of a Style Guide will not be sufficient to ensure the delivery of consistent applications. Support must be provided from senior managers to ensure that the

Fig. 7. The development of an application style guide within an idealised system development lifecycle.

N. Simpson / Interacting with Computers 11 (1999) 323–351 341

342

N. Simpson / Interacting with Computers 11 (1999) 323–351

Style Guide is adopted, utilised and updated. A sponsor for a Style Guide is usually identified at the start of a project and is responsible for identifying key stakeholders to contribute to the development process. The sponsor is usually also responsible for securing the budget for support activities such as awareness seminars. It is frequently the case that a Style Guide is adopted by a project team, who agree to sponsor the use of a Style Guide on a flagship project. Such activities provide valuable case history material, and a testbed in which to prove the promised benefits. Sponsors should be sufficiently senior as to be able to manage or quash negative reaction which might come from groups who see the standards as limiting their freedom within the design space, rather than seeing the opportunity for their efforts to be focused more productively. 5.2. Awareness The existence, objectives and use of the Style Guide must be advertised within the organisation. Unless all developments make reference to the Style Guide, widespread consistency cannot be achieved. Activities which we have found to be valuable include awareness seminars, distribution using the Corporate Intranet, and establishing discussion bulletin boards. These mechanisms are particularly suitable for Corporate Style Guides where the potential user base is distributed across an entire organisation. For Application Style Guides, more personal awareness activities are required including briefing and handover sessions, and design reviews where the developers of the Style Guide use their familiarity with the material to assist the project team in taking on board the advice contained within the Style Guide. All awareness activities should have clearly defined objectives and should be endorsed by the sponsor. Without such credentials it is difficult to promote acceptance of the Style Guide, and awareness sessions can easily turn into pedantic and non-productive diatribes. 5.3. Audit Given the pressures produced by project deadlines and costs it is invariably the case that project personnel seek shortcuts. Invariably one of the attributes of projects that suffers is attention to issues relating to usability. Designers and developers may consciously choose to sidestep their responsibilities including adherence to the Style Guide. No matter how well individuals buy-in verbally to the importance of usability and conformance to a style, it should be incumbent on someone to ensure conformance. Conformancy procedures must be defined once and administered on a project by project basis. Conformancy assessments will need to be undertaken and documented. Follow-up activities may be required including modifying and re-assessing non-conformant designs, and extracting lessons learned in order to feed new information into future versions of the documentation and design practices. Colbert [5] identified a lack of guidance in relation to compliance testing to be a major weakness of industry Look and Feel guides. Although efforts have been made to provide the automatic evaluation of a design’s compliance [35], these efforts work only for those aspects of an interface that were formally specified, for example using notations such as Statecharts [2,36]. The ultimate objective of any design management process is to allow the benefits of a house style to be obtained whilst allowing the flexibility to exploit beneficial but

N. Simpson / Interacting with Computers 11 (1999) 323–351

343

non-standard design elements on a task-by-task basis. In an environment that is too rigidly defined such deviations may be described as inconsistent or non-conformant and risk rejection on that basis alone, whilst in an uncontrolled environment any degree of consistency would be unachievable. What is required is a process which allows non-conformant design elements to be identified and assessed against project objectives and usability criteria. The assessment process will then allow for the following options: • Acceptance on a one-off project/screen/form basis; • Acceptance on a global level leading to an addition to the style guide; • Rejection. Given the importance of conformancy testing and the management of design deviations, we have developed an approach based on testing designs against Corporate and Application Style Guides. The conformancy checking procedures may be administered at a number of levels. Conformancy checking forms may be used to give an overall impression of conformancy by sampling a limited number of instances of each component in the user interface. The SSADM user group [32] suggest producing detailed conformance checklists for critical aspects of a user interface. This approach might also be extended to frequently used modules or dialogue sequences. Ideally however, a rigorous and complete conformancy check should be administered. A conformancy form for checking Dialog Boxes against a Windows 3.1 based Corporate Style Guide is illustrated in Fig. 8. To support a complete conformancy assessment, a Conformancy Planning Process should be designed and used to guide test teams through the organisation and production of a complete test pack, with relevant forms to test each user interface component. It is only through following a rigorous conformancy planning and execution activity that conformance and consistency will be assured. The process of organising the appropriate materials for a full conformancy check is lengthy and is dependent upon the exact structure of the system under test. An illustration of the implications for complete checking is provided in Fig. 9. This figure illustrates a system with multiple Child Windows, each containing some of the range of permissible user interface components. One of the windows consists of a set of tabbed pages, each of which may contain some of the range of possible user interface components. An extract from the instructions and planning forms required to conduct a full conformancy check are illustrated in Fig. 10. Following the planning process, the correct number of conformancy checking forms must be produced and completed in line with the user interface structure. The planning process enables a complete conformancy check to be performed. Deviations can be identified and recorded in relation to the specific part of the design in which they occur. This enables corrective actions to be accurately targeted. Such formal conformancy checking procedures are the most appropriate tool for use in checking developments against Corporate Style Guides. Formal procedures are also effective for use on specific projects where an Application Style Guide is in existence. However, the constraints in place for a specific project can lead to a reduction in the size and complexity of the design space, and under these conditions, the overhead of conducting a full conformancy check might be rejected. In such cases we have found a

344

N. Simpson / Interacting with Computers 11 (1999) 323–351

Fig. 8. Conformancy checking form.

more informal approach can work well. It is the case that the authors of a Style Guide become very familiar with the material to the point that they have inculcated the style rules. For this reason, it can be effective to second one of the authors to a development team to act as a ‘‘living style guide’’ providing input to designs and reviewing them. Such activities also have the effect of increasing the rate with which the development staff themselves become au fait with the contents of the Style Guide and the process of rationalising design conflicts. Alternative approaches to conformancy testing include the use of ‘‘standards inspections’’ and ‘‘consistency inspections’’ conducted by domain and/or user-interface experts [37]. The size and cost of a conformancy checking activity can be difficult to defend in a project plan. When facing pressures to reduce the scope of a conformancy check,

N. Simpson / Interacting with Computers 11 (1999) 323–351

345

Fig. 9. Illustration of the complexity of a full conformancy check.

practitioners would be well advised to ensure that any sampling procedure includes windows and dialogue sequences which address critical and frequent business tasks as identified during task analysis [2]. In this way the planned benefits realisation will be protected by ensuring resources are focused on the most important elements of the user interface, and financial benefit from improved usability likely to result. In our experience, testing and conformacy checking procedures are usually conducted under immense time and budget pressures. In these cases it can become tempting merely to test a random sample of windows, or even to confine testing to those windows for which development have been completed. This is a very dangerous course of action as it is often the complex and/or business critical elements of a system which are completed last in a project, and may not be available when the conformancy checking activity is undertaken. 5.4. Maintenance Style Guides are dynamic documents. As they are used in earnest, lessons will be learned that should be acted upon. New technologies will necessitate updates to documentation so that new styles can be adopted. Successive projects will demand new interaction styles, that are not covered in the current Style Guide. Change requests will be made by developers and their feedback should be used. For these and other reasons the documentation will need to be maintained and re-issued at intervals. Given the extended lifespan of some developments it may also occur that different projects will be operating under different versions of the Style Guide and this will also need to be managed.

346

N. Simpson / Interacting with Computers 11 (1999) 323–351

Fig. 10. Extract from conformancy planning process.

N. Simpson / Interacting with Computers 11 (1999) 323–351

347

Suggested deviations from or modifications to a Style Guide must be justified in terms of improved usability, and may be subjected to proof through usability testing.

6. Practical experience Table 1 characterises four major Style Guide projects carried out for clients in the UK for: central government, a multi-national pharmaceuticals company, an international finance house and an international law firm. As can be seen, the projects differed significantly in scale and the way in which they were implemented. This reinforces the point that Style Guides are highly organisation-specific documents and must take into account not only the technical infrastructure of a company but also its culture in order that appropriate management processes can be defined and put in place. As can be seen from Table 1, the style guides delivered to organisations vary greatly in such aspects as length, delivery mechanism and scope of audience. Style guide success requires strong commitment from the organisations, high levels of user input and thorough review and approval mechanisms. Each organisation was committed to conformancy procedures which were used in order to ensure the standard of designs against the style guide. Two organisations coupled this with usability testing to objectively measure the benefit delivered to the organisation through consistent and task-focused designs. This assisted them in implementing and managing iterative design activities to deliver maximum benefit. In all of the organisations reviewed, regular usage of the Style Guide by development teams can be observed, and ongoing feedback mechanisms are in place to deal with updates to the style guide, project specific change requests or design deviation rationale.

7. Conclusion Corporate Style Guides offer the opportunity to increase the effectiveness of design activities, ensuring consistency and maximising benefit to an organisation through retention and effective use of corporate design experience. Application Style Guides can be used to capture design guidance which has narrow applicability, reflects the objectives of individual projects and can be used to record exceptions to an established corporate style. These documents can be used to achieve consistency within and between applications and help to ensure the usability of systems supporting core business functions. The adoption and effective use of Style Guides offer payback opportunities in areas such as user productivity, system learnability, developer effectiveness, and quality control. For example: • Users – can transfer their learning between applications and are enabled to be more productive by virtue of the designs being structured around the tasks they must achieve in their organisational setting. • Developers – can take advantage of the opportunity to re-use interface components between consistent applications, and have a consolidated reference point for deciding between design alternatives.

70 pages Windows NT Netscape version 4 web applications

National strategy

Full paper style guide Quick reference guide Computer-based interactive style guide

250 pages Windows 3.1

Windows 95

Scope of style guide

Delivery mechanisms

Length of style guide Platforms addressed

Home Office research group

Flagship project group and usability resource centre

Rapid application development group Flagship project

Key forces

Owner of style guide/ sponsor

Usability resource centre

Home Office research group

Review and approval mechanism

15 interviews with stakeholders

10 interviews with forces and suppliers plus review of existing applications

Input from the organisation

Quick reference guide (paper) Web-based reference source

Organisation wide

Contractors

Project Director

Development teams

Project Director

10 interviews with users, project managers and developers

60 pages Netscape version 3 web applications

Quick reference guide (paper)

Project specific

Internal development groups

Internal development groups

Internal development and research group Police force, IT departments External suppliers

Audience for style guide

International finance house

Multi-national pharmaceuticals organisation

Government department

Organisation

Table 1 Summarised case histories for the provision of style guides in four major industry sectors

Business information systems department

Project development teams

Eight interviews with stakeholders and users plus expert input

Netscape web applications

230 pages NeXT

Full paper style guide Quick reference guide (paper)

All business support systems

Information systems department

International law firm

348 N. Simpson / Interacting with Computers 11 (1999) 323–351

Government department

Six months

168 days

Presentation at national user conference

Mandatory

Detailed audit and usability testing

Six core suppliers, 12 major projects per year

1300 for one application alone

Organisation

Development time

Effort

Awareness activities undertaken

Management of usage

Conformance procedures

Number of development groups/ projects

Number of end users

Table 1 (continued)

70–100

Four sub-project development teams

⬎ 20

10 000

Seconded consultant

Mandatory

Formal briefing and handover session

32 days

Four weeks

International finance house

Peer review

Discretionary but recommended

Web based discussion group

40 days

Four weeks

Multi-national pharmaceuticals organisation

1000

10 major projects per year

Usability testing and peer review

Recommended

Workshops including exercises designed to promote familiarity with style rules

30 days (NeXT) 25 days (Web)

Eight weeks (NeXT) Eight weeks (Web)

International law firm N. Simpson / Interacting with Computers 11 (1999) 323–351 349

350

N. Simpson / Interacting with Computers 11 (1999) 323–351

• Managers – can guarantee the standard of deliverables by reference to and conformance checking against the style guide. Organisations which invest in the process of becoming aware of their own data and processes and ensure these are communicated to, and incorporated within, IT groups and developments can expect to reap great financial benefit. This process requires the early identification of stakeholders, communication of goals and processes, definition and mandating of mechansims for usage of this information, definition of management processes and evaluation of output against corporate objectives. Recognition of the importance of a knowledge of corporate data and processes to the design of effective systems means that design activities can move beyond traditional system and user considerations. Higher level workflow and organisational issues can be incorporated and design can move beyond the mere selection of controls and presentation of task related data. In the future consistency will not only operate at the application design level, but will also take into account organisational resources, processes and strategic direction. The ultimate objective will to be provide access to these in a consistent and intelligible manner enabling systems to unite user and organisation in pursuit of common goals. Style Guides provide a cost effective and manageable means of achieving this aim.

References [1] J. Nielsen, Co-ordinating User Interfaces for Consistency, Academic Press, New York, 1989. [2] D.P. Browne, STUDIO STructured User-interface Design for Interaction Optimisation, Prentice Hall, Englewood Cliffs, NJ, 1994. [3] K. Ehrlic, J. Rohn, Cost justification of usability engineering: a vendor’s perspective, in: R.G. Bias, D.J. Mayhew (Eds.), Cost Justifying Usability, Academic Press, New York, 1994. [4] C. Karat, Cost–benefit analysis of iterative usability testing, Proc. Interact’90, Third International Conference on Human–Computer Interaction, 1990, pp. 351–356. [5] M. Colbert, Style guides and their application: the case of Microsoft Windows and a remote tutoring environment, Behaviour and Information Technology 16 (1) (1997) 25–42. [6] C.E. Wilson, B.A. Lonny, L. Conte, K. Stanley, Usability engineering at Dun and Bradstreet software, in: M.J. Wiklund (Ed.), Usability in Practice, Academic Press, New York, 1990. [7] D. Rosenberg, L. Friedland, Usability at Borland; Building Best of Breed Products, in: M.J. Wiklund (Ed.), Usability in Practice, Academic Press, New York, 1990. [8] J. Grudin, The case against user interface consistency, Communications of the ACM 32 (10) (1989) 1164– 1173. [9] S. Gale, A collaborative approach to developing style guides, Proceedings of ACM Conference on Human Factors in Computing Systems, Vancouver, 1996, pp. 362–367. [10] A. Salasoo, E. White, T. Dayton, B. Burkhart, R. Root, Bellcore’s user-centred design approach, in: M.J. Wiklund (Ed.), Usability in Practice, Academic Press, New York, 1990. [11] Lynch and Horton, Yale Style Guide Manual of Interface Design for the World-Wide Web http://info. med.yale.edu/caim/manual/pages (1997). [12] W.M. Newman, M.G. Lamming, Interactive System Design, Addison Wesley, Reading, MA, 1995. [13] T. Berners-Lee, R. Cailliau, A. Luotonen, H.F. Nielsen, A. Secret, The world-wide web, Communications of the ACM 37 (8) (1994) 76–82. [14] A. Crerar, D. Benyon, Integrating usability into systems development, in: L. Trenner, J. Bawa (Eds.), The Politics of Usability, Springer, Berlin, 1998. [15] T. Stewart, Standards and style guides – a cross cultural perspective, in: L. Trenner, J. Bawa (Eds.), The Politics of Usability, Springer, Berlin, 1998.

N. Simpson / Interacting with Computers 11 (1999) 323–351

351

[16] B. Curtis, Designing interfaces for the organisation, IEEE Software 12 (6) (1995) 123. [17] R. Bernard, The Corporate Intranet, Wiley, New York, 1996. [18] A. Marcus, N. Smilonich, L. Thompson, The Cross GUI Handbook for Multiplatform UI Design, Addison Wesley, Reading, MA, 1995. [19] B. Shneiderman, Designing the User Interface: Strategies for Effective Human Computer Interaction, Addison Wesley, New York, 1992. [20] J. Nielsen, Big paybacks from discount engineering, IEEE Software 7 (3) (1990) 107–108. [21] M. Telles, Updating an older interface, Proc. ACM CHI’90, 1990, pp. 243–247. [22] P.G. Polson, E. Muncher, G. Engelbeck, A test of common elements theory of transfer, Proc. ACM CHI’86 Conference, 1986, pp. 78–83. [23] C. Lewis, D. Hair, V. Schoenberg, Generalisation, consistency and control, Proc. ACM CHI’89 Conference, 1989, pp. 1–5. [24] C.E. Bellantone, T.M. Lanzetta, Works as advertised, Proc. Human Factors Society, 35th Annual Meeting, 1991, pp. 324–327. [25] C. Wiecha, W. Bennett, S. Boies, J. Gould, Tools for generating consistent user interfaces, in: J. Nielsen (Ed.), Co-ordinating User Interfaces for Consistency, Academic Press, New York, 1989. [26] B. Tognazzini, Achieving consistency for the Macintosh, in: J. Nielsen, (Ed.), Co-ordinating User Interfaces for Consistency, Academic Press, New York, 1989. [27] C. Karat, Cost–benefit and business case analysis of usability engineering: Tutorial, CHI’91 Conference, 1991. [28] A. Chapanis, The business case for human factors in informatics, in: B. Shackel, S. Richardson (Eds.), Human Factors for Informatics Usability, Cambridge University Press, Cambridge, 1991. [29] R.G. Bias, D.J. Mayhew (Eds.), Cost Justifying Usability, Academic Press, New York, 1994. [30] E.T. Klemmer, Ergonomics: Harness the Power of Human Factors in your Business, Norwood, NJ, 1989. [31] Windows Interface Guidelines for Software Design, Microsoft Press, 1995. [32] SSADM User Group, SSADM and GUI Design: A Project Manager’s Guide, HMSO, London, 1994. [33] National Strategy for Police Information Systems, NSPIS Windows 95 Style Guide, HMSO, London, 1996. [34] National Strategy for Police Information Systems, Recommended Applications Portfolio, HMSO, London, 1996. [35] J. Lowgren, T. Nordqvist, Knowledge-based evaluation as design support for graphical user interfaces, Proc. ACM CHI’92 Conference, 1992, pp. 181–188. [36] D. Harel, On visual formalisms, Communications of the ACM 31 (5) (1988) 514–530. [37] D. Wixon, K. Holzblatt, S. Knox, Contextual design – an emergent view of system design in empowering people, in: J.C. Chew, J. Whiteside (Eds.), Proc. CHI90, ACM Press, New York, 1990.