Current Issue
The Bull’s-Eye: A Framework for Web Application User Interface Design Guidelines(1) - 22 September 2006
by Betsy Beier and Misha W. Vaughan
Read this article in Chinese (translated by Wei Luo, proofread by Shuzhong Zhao)
ABSTRACT
A multi-leveled framework for user interface design guidelines of Web applications is presented. User interface design guidelines tend to provide information that is either too general, so that it is difficult to apply to a specific case, or too specific, so that a wide range of products is not supported. The framework presented is unique in that it provides a bridge between the two extremes. It has been dubbed the ‘Bull’s-Eye’ due to its five layers, represented as concentric circles. The center of the Bull’s-Eye is the Component layer, followed by Page Templates, Page Flows, Interface Models and Patterns, and Overarching Features and Principles. To support this approach,requirements were gathered from user interface designers,product managers, UI developers, and product developers.
Also, usability testing of the guidelines occurred on several levels, from broad guideline tests to more specific product tests. The guidelines and lessons learned are intended to serve as examples for others seeking to design families of Web applications or Web sites.
Keywords
user interface guidelines, standards, corporate style guides, enterprise style guides, Web applications
INTRODUCTION
The Challenges
We faced challenges common to many companies attempting to create user interface design guidelines for a family of Web applications. We were attempting to design for multiple, Web-based software products across a variety of user profiles – with only desktop application guidelines as our reference point. We knew technological limitations would also impact our guidelines as we attempted to make them accessible, cross-browser compatible, and localizable.
This paper will discuss the problems we faced, often shared by other companies, and how we overcame them.
Our first challenge was the state of Oracle’s existing UI guidelines. They were focused on Java, not HTML, and were at the widget level, and so did not provide use-cases,multiple options, higher level component combinations (i.e., templates or flows), nor contextual examples to illustrate usage. Our attempts to use other guidelines as exemplars left our guidelines too broad to implement specifically and consistently across products.
Second, the new guidelines would need to work with an evolving technology – Web applications. Web application guidelines could draw from desktop UI guidelines, however this approach would be limited in its usefulness. Web applications are delivered via a browser that is dominated by different metaphors (e.g., page-centric) than desktop applications (e.g., windows and menus). Also, this HTMLbased UI would be less interactive than desktop applications – in order to support cross-browser compatibility, internationalization standards, and universal access standards.
Third, was the scope of our Web-based products. We needed to design for 100+ Web-based products, developed across multiple domains, and serving a variety of user profiles.
Fourth, we lacked any sort of centralization or support to design or implement a set of guidelines. Many development teams were already hard at work rapidly inventing their own product-specific look-and-feel.
To meet the challenges of developing HTML UI design guidelines, we would have to produce guidelines that were flexible enough to use across the variety of cases and issues, but specific enough to meet each team’s requirements.
Our Solution − The Bull’s-Eye1
The Bull’s-Eye was designed to address each of the four challenges. The Bull’s-Eye (Figure 1) represents the concentric circles of guidelines, each building on the next layer as one moves from the inside out. In the center of the Bull’s-Eye are Components, followed by Page Templates, and Page Flows. Interaction Models or Patterns sit on top of Page Flows. Finally, the Bull’s-Eye is completed with Overarching Features and Principles.
Figure 1. The Bull’s-Eye: A Framework for Web Application UI Design Guidelines
Lack of an HTML UI Foundation
Before conceptualizing the Bull’s-Eye and developing the standards, we evaluated our existing guidelines [10] as well as other software guidelines. An examination of approaches to developing style guides [2, 3, 7, 11], Graphical User Interface (GUI) guidelines [1, 4, 6, 16, 12, 13, 5], and Web style guides [9] demonstrated that existing resources were either too general or too specific.
Existing approaches provided a set of user interface design principles (e.g., design guidelines and heuristics) that were too broad to apply in the specific case, or they provided a standard (e.g., at the UI component or widget level) that was too narrow to apply across the variety of cases faced by our teams. Unfortunately, we do not have room in this paper for a more detailed discussion of this analysis. This apparent gap in existing guidelines motivated our decision to create guidelines at multiple
levels, from the UI component to overarching features.
The notion of multiple levels of guidelines, from component level to flow level, became the basis for the Bull’s-Eye metaphor.
Web Applications
As part of our investigation into Web design guidelines, we explored existing Web metaphors. We examined existing Web applications and Web sites, as well as elements from the desktop world that were still applicable in the Web browser environment. From this study, we developed a set of generalizations about new UI design guidelines for Web applications, such as: using a portrait
page orientation (compared to a landscape page orientation), using browser-based hierarchical page organization, using free form layout (compared to GUIstyle windows, panels, and toolbars), and using Web navigation structures such as tab navigation and side navigation (compared to menu structures and multiple dialog interfaces). We found that our generalizations were consistent with other, similar efforts by Web design consultants, e.g., Najjar’s work at Viant [8], and consumer Web-application designers, e.g., Zhu’s work at Microsoft [17]. We then applied our findings to each of the different levels of guidelines in the Bull’s-Eye.
A second problem in designing for Web applications is that a browser-based UI would need to support crossbrowser compatibility, internationalization, and accessibility. To accommodate this challenge, we chose to reduce the available interactivity in the UI –specifically, Javascript is used in only very limited contexts and Java applets are not used at all.
A Broad, Varied Product Base and Set of User Profiles
Our product suite ranges from server technologies, to development tools, to customer relationship management (CRM), to enterprise resource planning (ERP), to business intelligence. This broad set of products and their associated user profiles often spawned very different UI interpretations (Figure 2) of what were usually typical tasks across applications. For example, a task that crossed product boundaries, such as ‘search,’ looked and behaved differently from one application to another. The page flow that retrieved and displayed search terms and the search result set was inconsistently designed across applications. The display and navigation of primary objects (e.g., from purchase orders to database targets) also differed widely across applications; they shared no common look or interaction behaviors. Even straightforward tasks such as viewing reports varied greatly across applications. An examination of the
product suites revealed UI inconsistencies across applications and divisions, and were most visible at the page and page-flow level. However, we knew it was possible to create a common look across systems [e.g., 5].
Figure 2. The Multiple Looks and Diverse Product Base of Oracle (circa 1997-1999)
At the same time, there was a varied set of user profiles.
For example, a self-service benefits application defined its users as ‘any employee in a company who can use a mouse.’ Every individual, from the janitor to the CEO, would need to be able to use this product to register for his or her benefits. At the other end of the continuum were database products, which defined their users as ‘novice to expert database administrators’ – who would have a much higher level of computing expertise.
To address the problem of needing a common look-andfeel across varied applications, we again turned to the notion of developing guidelines at multiple levels. The guidelines would not only encompass the individual UI components on a given page (e.g., the icons used on a search page), but also the page layout and a page flow (e.g., search page templates and a common search flow).
The Bull’s-Eye, at this point, addressed the overall problem of creating a common user experience across a broad product group, but it did not address the issue of user variety within these groups. For instance a basic search page template and a search flow would satisfy many applications’ needs (and potentially several user profiles), but would not satisfy all application’s
requirements, or varying user skill levels. It became clear that multiple options within each level of the guidelines would be needed to satisfy this variety.
Lack of Centralization and Support
In 1999, we received upper management support − a CEO-level mandate to move to a common look-and-feel. In order for this UI guideline and standardization effort to succeed, we needed three infrastructure practices in place:
- Education
- Coordination
- Communication
Education ranged from consulting with product teams to classroom lectures on the guidelines. In the early days of disseminating the information, the lead guidelines designer
developed large-scale classroom lectures to introduce whole divisions to the guidelines. These lectures were often tailored to a particular domain, e.g., human resources.
In an ongoing capacity, UI teams provided one-on-one consulting to product teams. This typically included translating a product’s information architecture and task flows into a guideline’s compliant interface design. Finally, a Web-based self-study course was created for the many developers we were unable to reach one-on-one.
Coordination took the form of: a) requirements gathering across products and user profiles, b) development of reusable UI code, c) usability testing of the guidelines, and d) individual product reviews. Requirements gathering occurred weekly, and was an ongoing process designed to track needed changes, identify enhancements to existing guidelines, and push new needs into the next version of the guidelines. A re-usable UI code base was developed to ease adoption of the guidelines, and enhance consistency of implementation. A team was assigned within Oracle to develop re-usable UI code based on the guidelines. Close coordination and collaboration with this team has produced
successful adoption of the guidelines code (how we define ‘success’ will be addressed later in the paper). To check the validity of guidelines, coordination with usability engineers provided the opportunity to conduct both product- and guidelines-specific usability tests. Finally, product UI reviews occurred at all levels, ranging from informal reviews with a UI designer to formal reviews with our department vice president.
Communication occurred both with the Usability and Interface Design department, and with the product teams they supported. Regular guidelines updates were disseminated via meetings and email notices to UI designers, usability engineers, product managers,developers, directors, and vice presidents. With this infrastructure in place, we were able to roll out the first version of the guidelines.
Since Betsy Beier and Misha W. Vaughan published it on ACM in April,2003, this article has been cited numerous times as a classic article in user interface guidelines design. It is published in uiGarden including two parts, and this is the first one.
Comments made
Possible Related Articles:
bal
Hi ! As you mention Oracle templates to illustrate your concept. You may know that this old fashioned template is automatically generated from Oracle docs database and have never changed since a long time ago. I don’t think it serves your theory just because Oracle’s site is not the High end / Popular example of user experience modernity.