Najjar, L. J. (2002). An efficient Web user interface design process for commercial clients. Unpublished manuscript.
Lawrence J. Najjar,
Ph.D.
Austin, TX
lawrence_najjar@yahoo.com
It is very challenging to design high-quality Web user interfaces for commercial clients. Web user interface designers have to work in dynamic, unpredictable environments under intense time pressure. Clients often are inexperienced at software development and have not defined the requirements for their sites. However, they usually do have a date by which they want the sites launched. Traditional user interface development processes do not adequately meet these unique challenges. There is no generally accepted process for Web user interface design. This paper describes a Web user interface design process that meets these challenges and helps Web user interface designers be more efficient, effective, and successful.
User interface design process, user interface design methodology, design process, Web user interface design process
Although there are many helpful processes for designing user interfaces (e.g., [1], [2], [3]), those processes do not adequately address the unique requirements of Web user interface design. The most significant difference between traditional graphical user interface design and Web user interface design is the emphasis on time. For competitive reasons -- and to see a quicker return on investment -- Web clients often want their sites built very quickly. Also, Web clients are often unfamiliar with software development and underestimate the complexity, effort, cost, and time to complete the work. For these reasons, Web user interface designers must create high-quality Web site user interfaces in a very short timeframe. Web user interface designers must also keep the client involved throughout the process, address the needs of users, and produce a site that is easy to use (e.g., [5]). Web user interface designers must be extremely efficient.
Figure 1 shows a Web user interface design process that emphasizes the functional, interactive user interface design of Web sites. Steps that the user interface designer performs are shown as gray boxes. Steps that other team members perform that significantly affect the user interface designer are shown as white boxes. The process does not show the steps for the visual or technical designs. The process lists a step, shows when it generally occurs in a project, and identifies the deliverable associated with the step. The process is divided into three phases – Strategy, Design, and Build.
Figure 1. Suggested process for Web user interface design. Note: Does not include visual or technical design.
During the Strategy Phase, the strategist talks to the client and conducts research to understand the client’s business. Then the strategist analyzes competitors and the market to identify a unique need that the site can fill. The strategist builds a business case for the site. The strategist also develops the business objective for the site. This strategy drives the rest of the project. The Strategy Document describes why the client should build the site.
Based on the strategy, the strategist, requirements analyst, and information architect identify the intended users of the site, the users’ objectives for the site, the environment in which the users access the site (e.g., home, work, car), and the lowest common technologies that the users utilize (e.g., browser, computer, screen resolution, connection speeds). The project team commits to a download time for each page (e.g., maximum of 10 seconds via the slowest connection). The team also documents the users’ familiarity with the Web, the clients’ current Web site, and its competitors’ Web sites. The Experience Architecture Document describes who will use the site, why they will use it, and how they will connect to the site. The client reviews and signs off on the Experience Architecture Document.
In this step, the requirements analyst speaks with prospective users, subject matter experts, and the client to identify the functions users want that are consistent with the strategy. The requirements analyst uses tools such as focus groups, interviews, competitive assessments, contextual inquiries, and questionnaires to gather functional requirements. The work may reveal, for example, that “Registration” is a functional requirement.
Then the requirements analyst works with the client to prioritize the functions and assign requirements to projects. The team implements the most important functions in the first project and adds other functions in future projects. The prioritization criteria may include how essential the function is (based on the site type) (e.g., e-commerce sites must provide a product search function), differentiation from competitors’ sites, time to implement, and cost to implement.
The Functional Requirements Document is a spreadsheet that shows numeric values for the priority ratings. It lists the high-level functions for the site by priority and by proposed project (e.g., Current Project, Future Project). The client reviews and signs off on the Functional Requirements Document.
The requirements analyst breaks down the functional requirements into more detailed tasks called “use cases.” For example, the requirements analyst can break down the “Registration” functional requirement into use cases for “Enter information,” “Show confirmation,” “Show error message,” and “Edit registration.” The use cases describe what the user does, what the system does, error conditions, and other special user situations (e.g., when the user logs in the system shows different information such as a member greeting). The requirements analyst works with the client to prioritize each use case. The requirements analyst can use prioritization criteria such as value to the user, differentiation from competitors’ sites, and ease of implementation. The requirements analyst may also provide a separate category for use cases that are low priority, but that users expect to find on the site (e.g., “Contact Us”). The requirements analyst works with the client to assign use cases to project phases. The development project manager works with the lead development team members to estimate the resources (e.g., people, time, tools, money) to complete the current phase.
For the current project, the Use Cases Document lists each of the functional requirements and their associated, prioritized use cases. Since the use cases drive the user interface design, the requirements analyst should nearly complete the Use Cases Document before the information architect begins to organize the site structure. The client reviews and signs off on the Use Cases Document.
The Use Cases Document is helpful for controlling the introduction of additional requirements (“scope creep”) into the project. As the design proceeds, the client will want to add new functions to the Web site. These additional requirements can significantly impact the schedule and cost of the project. The later a new function is added, the larger the impact it will have on the project resources. To control scope creep, the team submits requests for new functions to the requirements analyst. The requirements analyst, project manager, and lead development team members estimate the impact of adding the function to the project. Since development team members are unable to perform their regular work during the scoping tasks, the team must be aware that each scoping effort costs time and money. To maintain the schedule and costs, the team can propose to swap out a current function for the new function. Or, the team can provide the client with an estimate of the additional time and cost needed to add the requirement. The client decides what to do. The requirements analyst updates the Use Cases Document to include the new functional requirement and associated use cases.
Based on the use cases, the information architect creates diagrams that show the information architect’s recommendations for organizing and naming the sections and sub-sections of the site. Since the diagrams change frequently as the team gradually fills out the site design, the information architect draws site structure diagrams for only the higher levels of the site (e.g., top three levels). Figure 2 shows a site structure diagram for NASCAR.com. The information architect reviews and changes these diagrams based on feedback from the client. The information architect uses a tool, such as Microsoft Visio, that allows the information architect to quickly develop and change the diagrams.
Like the outline for a book, the Site Maps show the organization of the major sections and sub-sections of the site. The section and sub-section names become the names of navigation controls. Since the Site Maps change as the team completes the design of the deeper levels of the site, and the design emphasis shifts to the Interactive Mockup, it in not necessary for the client need to sign off on the Site Maps.
Figure 2.High-level site map for NASCAR.com.
To allow clients to provide early feedback on the user interface design, the information architect develops an interactive, hypertext markup language (HTML) mockup that shows the organization of the site, the controls on each page, and how each control works [4]. Figures 3 and 4 show a generic interactive mockup. The Interactive Mockup shows entry fields, buttons, dropdown menus, hyperlinks, confirmation windows, and error messages. It shows the client how the site may work, not how it may look. The Interactive Mockup does not include graphics because the team must first define how the site works before defining how it looks. The information architect also does not use robust, complete, professional HTML to create the Interactive Mockup. Instead, the information architect uses an HTML authoring shell, such as Macromedia Dreamweaver, to quickly, easily, and cheaply design and redesign the user interface. The information architect does not connect the HTML to actual databases.
The information architect conducts iterative design reviews of the Interactive Mockup with the client. During these reviews, the information architect presents at least one representative example of every page in the site. To allow the team members to see the latest user interface design and to allow the client to show progress to the client’s clients, the information architect puts the Interactive Mockup on a Web server with protected access via special IDs and passwords. Since it shows the latest site organization, near the end of the Design Phase the information architect uses the navigation and organization of the Interactive Mockup to update the Site Maps.
The decisions made in the Interactive Mockup design reviews affect the work being done by other members of the team. Therefore, it is helpful for the development team project manager and one representative from each development team specialty (e.g., creative, technology) to attend each design review. The team members can quickly answer client questions, discuss design options, and provide feedback on the scope of changes being considered by the client. In addition, the client project manager, sole client decision maker, and subject matter experts should attend the design reviews.
One team member should take notes of the client’s design decisions, requested changes, approvals, and the issues and action items the project managers assign during the meetings. To improve coordination, the team member should post the notes in a project folder that the clients and development team members can access. Since the notes record the design decisions made by the client in each meeting, and the design will change in subsequent meetings, it is not necessary for the client to formally sign off on the design of each page of the Interactive Mockup.
Figure 3. Interactive mockup showing suggested location of controls on Home page of a generic e-commerce site.
Figure 4. Interactive mockup showing suggested location of controls on interior page of a generic e-commerce site.
The visual designers, HTML programmers, and information architect add graphics to several typical, important, or hard-to-use pathways in the Interactive Mockup. Then, the information architect recruits representative users and asks them to think out loud as they perform typical tasks that use the pathways. The representative users also complete usability feedback questionnaires after each major task. The information architect should conduct this work quickly and cheaply, using a convenient conference room rather than an expensive, offsite usability test laboratory. The information architect uses this user feedback to improve the Interactive Mockup. Ideally, the information architect repeats this test-redesign-test cycle until the ease of use of the Interactive Mockup is very high. The goal is to complete the design of the functional user interface before programmers write a single line of production code.
The Usability Test Report describes who participated in the usability test, what tasks they performed, the results of the user surveys, the usability problems identified, the severity of each problem, and a suggested solution for each problem.
To allow the HTML programmers and back-end programmers to do their work efficiently, the information architect puts the Site Maps into a single Microsoft Word document. Then the information architect captures an image of each site page from the Interactive Mockup and places it into the Word document. If the visual designers created a realistic version of a page, then the information architect uses that image instead. The information architect lists each of the controls that are on the site page and describes how each control works (e.g., default state, available choices, changes that occur if the user is registered, changes that occur when the user performs each action, error messages). The information architect works closely with the programmers to give them the information they need to bring the user interface design to life. The quality assurance testers also use the Interactive Design Specifications to perform quality assurance testing of the user interface design (e.g., confirm that each control does what it is supposed to do).
The Interactive Design Specifications describe the interactivity on each page of the site. The Interactive Design Specifications document is very long and complex technically, but because it describes how the team will build the site, the client needs to sign off on the document.
After the team builds the actual site, but before is launched, the information architect performs another usability test. In the user acceptance test, the information architect evaluates the usability of the actual code, final graphics, and databases. This test identifies usability problems -- such as excessive download times -- that could not be identified in the earlier Interactive Mockup usability test. Since the information architect already iterated the design with the client and with representative users, the test should identify relatively few usability problems. The team makes any needed changes to the final design and launches the site.
The User Acceptance Test Report describes who participated in the usability test, the tasks they performed, the results of the user surveys, the usability problems found, the severity of each problem, and a suggested solution for each problem. Working with the client, the team decides which usability problems to fix before launching the site.
In addition to the tasks described above, the team may want to perform other tasks. For example, the information architect can perform a quick usability expert review of the old site to help ensure that the new site is easier to use than the old site. If the site contains a great deal of content, a content architect can identify the content needed for the new site, determine the gap between the content that is needed and the content that is currently available, provide consistent naming schemes for the content files, organize the content files into a spreadsheet or database, and track the content as it is obtained.
Several information architects successfully used most elements of this design process on commercial projects that included BallardDesigns.com, Fast Forward, Fleet Galaxy Funds, GE Power Systems Parts Status system, HomeDepot.com’s Online Store, and NASCAR.com. For example, as described earlier, the details in the Use Cases Document helped the team control the scope creep that occurred on every project.
Clients were very pleased with the Interactive Mockup. Before the information architect created the Interactive Mockup, clients had to rely on paper analyses and conversations to understand the proposed site. The Interactive Mockup was the first concrete, realistic representation of the clients’ site. The Interactive Mockup design reviews were therefore very popular with clients. The design reviews gave clients a great way to understand and offer input into the design, and reassured them that the project team was making solid progress. The Interactive Mockup design reviews also established a common design foundation for all members of the project team.
Another document that proved useful was the Interactive Design Specifications. Since these specifications were based on a design that had already been iterated and approved with the client, the Interactive Design Specifications enabled the programmers to do very little rework. One project manager said that the Interactive Design Specifications allowed the programmers to do the most efficient build she had ever seen.
On the negative side, our Web clients were usually not interested in usability tests. The clients wanted the site launched quickly and were not willing to spend the time or money to perform an interactive mockup usability test or a user acceptance test.
This design process addresses the challenges that user interface designers face when building commercial sites. The process makes it easier for designers to efficiently create Web sites that involve clients throughout the design process and meet the functional and usability needs of users.
Will Payman of Scient (formerly iXL) contributed to the development of the interactive mockup concept and used it in several of the projects that I listed in this paper. I thank Laurie Najjar for her helpful editorial assistance.
1. Hix, D. & Hartson, H. Developing user interfaces: Ensuring usability through product and process. John Wiley, New York, 1993.
2. Lewis, C., & Rieman, J. Task-centered user interface design: A practical introduction, 1994. Available at http://home.att.net/~jrieman/jrtcdbk.html
3. Mandel, T. The elements of user interface design. John Wiley, New York, 1997.
4. Najjar, L.J. Conceptual User Interface: A new tool for designing e-commerce user interfaces. Internetworking, 3.3 (December 2000). Available at http://www.internettg.org/newsletter/dec00/article_cui.html
5. Najjar, L.J. E-commerce user interface design for the Web, in Usability evaluation and interface design (Volume 1 of the Proceedings of HCI International 2001) (New Orleans, LA, August 2001), Lawrence Erlbaum, 843-847. Available at http://www.lawrence-najjar.com/papers/E-commerce_user_interface_design_for_the_Web.html