How to build a usable web site

Home

Definition: HCI What is Usability Color Design for the Web

 

| Home |News & Commentary | Newsletter | About | Recommended | Email
 
 

When Requirements Interfere With Usability Goals

 
Designing a usable web site requires more than being able to define the business and project requirements. These goals must be in synch with usability principles and goals, or the design process may suffer.
 
 

July 1, 2001

Defining requirements is an important part of the web development process. There are various types of requirements that are used throughout the various lifecyles of a web project including:

  • Business requirements
  • technical requirements
  • project requirements

These requirements help define the necessary processes and components that are needed for the project to be successful

Lets take a further look at how requirements play a role in web design development lifecyle.

Business requirements defined

These requirements define the project scope as it relates to the business process. Without a business requirement, the project scope and direction can remain unclear. These requirements are broadin scope, and are used to help provide project direction at a high level. They help define the business purpose of need for the technology.

 They include:

  • Identify business need. This justifies and explains the reason why the technology is needed. A web development project might explain the need as follows:

In response to customer demand, and increased pressures in our competitive environment, the development of a company extranet that will allow us to conduct business with suppliers, customers and employees. Extensive interviews and research with customers, and an analysis of the competitive environment has established a need for such a web presence.

  • Define users of the technology. A web site might have a variety of users such as employees, customers, potential customers, and researchers. The user groups should be narrowly defined, rather than with broad user categories.
  • The interaction between the business, its employees and its customers in how they relate to the applied technology.
  • The intended behavior if each user group in relation to the technology. For example, how employees will use the technology on the job. An extranet web site might define the requirement as service employees will use the site to communicate with suppliers regarding the status of unresolved technical and delivery issues for all product shipments. This system replaces the Customer Service Inventory Planning and Status system
  • Tangible benefits to each user group.

Example: using the web site, staff will be able to reduce order processing by 20% while reducing training costs by 42% within 14 months.

Why requirements alone aren’t enough

Even if you’ve created good requirements,there is no guarantee your design will be usable. One of the biggest challenges in today’s development process,is the intersection of various players who participate throughout the project. In many cases, decisions are made by teams, whose input carefully considers all the many needs and requirements.

There are several things that can go wrong during the implementation phase:

Example:

Business requirement:

  • The company is to develop a web site that’s easy to update, and provides a uniform experience to all users.

In the above example, a good design process would consider the usability impact of this request, and determine the best way to achieve it. However, if the designer doesn’t consider the usability impact, a less desirable solution could be implemented. For example, to create a uniform experience, you could simply design for a particular screen resolution, such as 800x600. In addition, the site maintenance requirement is met, since the designer can create a single page, rather than multiple pages for each screen resolution. So, the designer slaps down a note at the bottom of each page warning users “this page looks best at 800x600”

Problem:

This approach puts an unnecessary burden on the user to change their screen resolution just because the designer thinks so. Without checking with a usability expert upfront, the design is implemented. Even if this usability problem is identified after the design, its too late in the process to change the error. Even though the business requirement is fulfilled, it produces an undesirable result that can create a poor user experience.

Example:

Business requirement:

  • Create awareness among all users regarding the site’s features and functionality to encourage user.
  • The site will be fully functional by December 11.

Armed with these requirements, it becomes apparent to the project manager that a particular functionality will not be operational by the time the site is implemented. So, to fulfill the above requirements,, a “sample” functionality will be presented on the site, to create user awareness, until it becomes operational within the next few weeks.

Problem:

This sounds just like an old “under construction” signs that whets the users appetite, but offers them nothing. But this is worse, since it looks more like an advertisement that wastes valuable screen real estate which could be used elsewhere. Although the business requirement is met, it is done at the expense of the user.

Recommendations

Here are recommendations to avoid such problems:

  • Involve a usability expert upfront during the development and interpretation phases of the business requirements.
  • Don't assume that just because you have created a business requirement based on the business needs, your design will be successful. A good business requirement understands both the business need, as well as the user need.
  • Give the usability expert the authority to challenge business requirements that appear to fly in the face of well known usability principles .Sure, usability testing will identify such problems after the design is implemented. Too often usability testing is used as a crutch to solve the problems that could have been identified during the initial planning states
  • Make sure that you are careful in developing these requirements, by conducting user task analysis. This will help you better understand how the userstasks are integrated with these requirements.
  • Don’t use usability testing only as a way to solve all usability defects. Good planning by identifying user needs can go a long way in helping develop a usable product.

Comments:

ganemanrussell@yahoo.com

 

 
 

Home

Definition: HCI What is Usability Color Design for the Web

 

Contact this sites Administrator