Defining Roles within the Project

Intranet project roles should be clearly defined at the outset of the project. This includes an understanding of job titles and of what each person adds to the project mix. It also includes an understanding of overlapping skills, and boundaries around their expectations of each other.

In Example A, two-thirds of the User-Centred Design group consisted of content writers and artists who were not familiar with the term UCD. The usability engineers were challenged to find their place within the group, to help clarify the difference between roles on the team, and to incorporate usability engineering techniques wherever possible.

To successfully integrate themselves with the rest of the team, the usability engineers worked to understand the value that each team member provided. Each person's role was considered equally valuable and respected, and each team member was encouraged to think outside of his or her role, even if his or her opinions were sometimes overruled. Focusing on the common goal helped promote a combined sense of ownership and teamwork that has extended throughout many different projects to this day. Still, the usability engineers should have gone one step further. Clarifying the role of each team member in writing would have formalized the plan, defining it clearly from the outset. For example:

1. Usability Engineer. Conducts field studies and other observations, creates conceptual models, researches best practices, conducts heuristic evaluations of early design models and concepts, content (text, links, etc.), and navigation, provides the team with design feedback throughout the project.

2. Visual Designer. Creates intranet graphics, selects colours, fonts, and other graphical elements (buttons, links, etc.).

3. Content Provider. Writes all of the text that appears on the site, including text blocks, link names, button names, and banners, if included.

It is less important that the information be well written than that it be clear. In Example A, the usability engineers found that true working definitions were more appropriate than those you might find in a textbook. If the members of the project team feel that there is overlap in roles, for example, writing these issues down is a good way to ensure that they are dealt with. Doing so at the start of a project helps establish working relationships, expectations, and limits. A "roles" document can also help the project leader to understand who is responsible for what tasks.

People's familiarity with these roles is another critical factor. In our Example B, none of the consulting company's project team had worked together before. Although the roles of Project Manager, Technical Manager, and Developer were well established within the consulting company, all of the people filling these roles were new employees. To make matters worse, the concepts of usability engineering and information architecture were new to the consulting company as well, so no one quite knew how to integrate them into the process. The lack of clarity regarding roles within the consulting company was amplified when external clients became involved.

After the usability engineer created several page layouts, the visual designer created three concepts for the client to review. One of these concepts deviated drastically from the layouts — the navigation was on the right side of the screen. Although the usability engineer had made it clear to the visual designer that the right side navigation was not usable, she was on vacation when the concepts were presented. The client loved the uniqueness of the right side navigation model and selected it as the framework for the site. If the visual designer trusted the usability engineer and clearly understood the implications of an unusuable design, he might never have recommended the unorthodox design to the customer.

In addition, the usability engineer should have provided the team with extensive data supporting her page layouts. The team could have referred to this when the usability engineer was out of town.