Skip Navigation
The Illuminating Web
 
 

The 3D HLX Process:
Design : Establish Needs

In Draft

The first step to a successful web site is to carefully examine the needs that the site must meet. The project team is developing the site at the request of a client. Before any planning is done, it is important to establish the audience of the site.

Establish the Audience

A web site's audience is the group of people that most commonly use the site. In the case of most internet sites the client is not the audience. It is important to draw the distinction between the audience and the client. Web sites built to a client's specifications are worthless unless they meet the needs and expecations of the audience.

To illustrate the relationship between these three groups consider the following scenarios:

Alice creates a one page website to share photos of her adventures in Wonder Land with family and friends. Alice is the project team and client, her family and friends are the audience.

The Polar Corporation creates a web site to publisize and sell their new product and decides to outsource. The project team is a private contractor. Polar's marketing and management are the client, and the general public is the audience.

Giant Robots Ltd. needs a site to handle customer support. They assign their IT department as the project team. This site is a coupled internet/intranet that allows the help desk to publish manuals and a knowledge base to the web for the general public and handle service requests from registered customers. Giant Robots is the client. The audience for the internet site is the general public and the audince for the intranet site is registered customers and the help desk staff.

Notice that in each case there is a relationship between the client and the audience. The biggest pitfal in misinterpreting the audience is the "hostess' delima". When throwing a party the hostess must consider the interests of the attendies. The hostess herself is an attendie, but she is one of many. A client's inclusion in, or relationship with the audience for a web site must not cloud the objectivity of the design process.

Alice might very well be a member of the audience for her online photo gallery, but she is just one of many. Her role as the project team and client should not lead to decisions that would detract from her friend's and family's use of the site. If Alice is fond of Active X controls and wants her web site to use these she should first make sure her friends and family all use Internet Explorer. If all of her friends have switched Mozilla, requiring Active X would be a bad idea.

In the case of the Polar Corporation, the contractor is in a tricky situation. The contractor's income source is the client, the Polar Corporation. If Polar's marketing and management team puts company interest before the audience's expectation, the site will fail. The customers will be turned off by the web site and buy the products elsewhere. Polar will not be pleased with their investment. The contractor will not want their name attached to the site. No one will be satisfied. Idealy, the contractor should sell Polar a web site that is designed for the audience, not the marketing department. At the very least, the contractor may compromise and make the site as audience centric as possible while still incorporating Polar's sales gimicks.

There are some cases when the client is the audience, but more often than not the client is only a subset of the audience. Many intranet sites are built as a tool for company employees, but not the general public. In this sense, an intranet site's audience is part of the client's company. If the client is a company's management and the audience is all the company's staff, then the client is a subset of the audience. The client's expetations should not be generalized to the expectations of the entire audience. When the client is management, but some other group of employees is the audience it is especially important to tailor the site to that audience, not the client. There is usually a very large discrepancy in the way management would like work to be performed and the way in which work is actually accomplished.

Formalizing the Project Team

Once the audience and client have been carefully identified, the project team must evaluate it's own role in the project. Much like an equation, the outcome of the project lies in balancing the needs with what can be reasonably produced. The audience and client are set constants, in order for the outcome of the project to optimal the project team must be the variable that makes the equation fit.

For proper web site design to occur the project team must fullfill several roles. Regarless of how many comprise the team, each role must taken seriously and performed by one or more people. Information Architects, Subject Experts, Graphic Designers, Technical Staff, Maintainers, and Audience Advocates each serve a critical function in planning the development and deployment of a web site. The amount of man power invested into each role varies. An online encyclopedia for example would need many more subject experts than the average project. A web site showcasing a fine arts college should pay special attention to graphic design. The needs of every site will be different and the strengths of the project team should balance these needs.

Gathering Background Information

Rather than starting with a completely clean slate, it is often best to work with as much established material as possible. Most clients have recognizable characteristics that distinguish them. If the client has an existing presence on the web or in other media this should be considered.

  • If the client has a specific visual identity or technical needs that are known ahead of time the project team should familiarize themselves with this.
     
  • If the client has an existing site, it should be closely examined. Clients with an existing site alleviate some of the challenges of site development, but create others. They may be "married" to certain features of the current web site.
     
  • If the client has known issues with the site, strategies for dealing with the problems can be explored. The client may be unaware of serious design issues with their current site or be hung up on trivial problems.

Similarly, any information that is available on the audience is extremely useful. Survey data from the client can be useful, but must always be carefully scrutenized. When the audience is the general public or some demographic, there are many useful and impartial sources of information for strategies and best practices. The key is not to rely on the client's understanding of the audience too much. The client often has a vested interest in something the audience does not. The client should dictate desired outcomes for the web site, it is the project team's job to determine how best to accomplish those goals.

Creating the Wish List

Some clients will have a very clear idea of what features they would like to see in a web site. Many create a wish list just by looking at their existing site and compeditor's sites and seeing what the like (and do not like). This wish list can cover a wide variety of needs including the appearance of the site to publishing and work flow concerns.

Project team members can also contribute to the wish list, though usualy only when they are doing so on behalf of a party involved in the deployment phase of a site. Audience advocates and maintainters should certainly have a say in the wish list.

Once the wish list has been compiled the project team will need to organize and refine it. Needs that the client and the audience share should be highlighted. When there are conflicting needs a compromise is needed. Some requests can never be met, others will require creative problem solving. The project team should work to group requirements and identify technologies and techniques that will make the wish list a reality. When there are multiple related sites being created (for different audiences) some development time may be saved if the project team identifies what needs are shared and which are unique early on.

Moving From the Wish List To a Plan

Some wish list items will be goals, others might be means to a goal. Brainstorming with flow charts can help with the organization process. The origin of every request on the wish list should be preserved. It is important to know if a goal is meeting the needs of the audience, a requirement of the client, or some compromise suggested by the project team. Goals should be linked to technologies, methods, and actions that will make them a reality. Goals should be specific. They should be grouped, but not absorbed into generalizations. Abstract goals should be avoided. These may sound good on paper, but are often cryptic and lofty.

The project team establishes that pop-up windows can be confusing or frustrating for many users in the established audience. It is decided that to avoid this problem any links that pop-up windows should be "properly labeled".

Later the team also learns from usability studies that short and undescriptive text links such as "click here" are problematic. They commit to "clearly labeling links".

If these two decisions later become generalized together it can be come unclear what "properly" or "clearly" labeling links originally meant.

At this stage it should be clear what the priorities for the site are and how the site will meet the needs of the client and the audience. If more formal planning is desired the charts can be convereted to or supplemented with an outline. When appropriate, these documents can be shared with the client to resolve discrepencies and prevent misconceptions and miscommunication later on.

Check List

At the end of this step the following should have been accomplished:

  • The Project Team has
    • a clear understanding of the client's needs and the audience's needs.
    • a properly balanced work force to meet the project's requirements.
    • background information on the client and when possible the audience.
    • an organized list of specific needs, ways to meet the needs, and how the needs relate to one another.
  • The Client has
    • an idea of how the planning will procede.
    • an understanding of the importance of meeting the audience's expectations.

Preparing For the Next Step

During the next step the project team will perform three separate tasks to further plan the site. The content management plan, planning for the navigational flow, and layout flow planning can each begin. Even though these three processes are inter-related each can begin immediately. Once some key decisions are made in the content management plan the navigational flow can proceed. Similarly, the layout flow cannot go very far until some decisions are reached regarding the navigational flow.

 

 
 

 
 

Terminology and Rationale

Design Process Overview

Development Process Overview

  • Establishing the Environment
  • HTML Actualization
  • Delivery Actualization
  • Content Mapping
  • Testing

Deployment Process Overview

  • Handoff
  • Population
  • Site Mapping
  • Repurposing
  • Updates & Service Requests