Building the "Right" Project Team

The best usability engineer for a project is one who is intelligent and flexible, and one who is not controlled by ego. The usability engineer should have excellent negotiation skills, and should be able to present a compelling case for the work.

The right project team includes members with a variety of roles and hard and soft skills. Equally important, the right project team includes at least one firm supporter of usability. This person should be in a leadership position, and should be firmly convinced of the benefits of usability engineering.

In Example A, the usability engineers never became fully integrated with the project team. There were several reasons for this. First, the management team did not include a firm supporter of usability. Although they included usability in the project plan, they did not implement or support making changes to the system or the project schedule based on usability issues. In addition, the usability engineers on the project tended to be timid, and often approached their work complaining about what they could not do, instead of working to figure out how they could provide value to the project. The right project team in this case would have been one with stronger management support and more persistent, positive-thinking usability engineers.

In Example B, the intranet project team was a combination of two independent, already established teams: the consultants and the clients. The majority of the consulting group was made up of new consultants, many of whom did not have a clear understanding of how to integrate the usability engineer role within their own team. The clients had very few people to dedicate to the project, and had no flexibility with resources if the team failed to gel.

Still, what made this the "right" project team was the consistent, open sharing of information. Despite its shortcomings, the project team worked well together by educating, communicating, and negotiating. Team members listened to each other and shared what they knew about the project. Open communication led to trust within the team. As miscommunications, mis-perceptions and other mistakes occurred, the team talked through them, working towards resolutions without egos getting in the way. This assured the highest level of success on the project, and created a basis for ongoing understanding.

In our next projects for the company in Example A, we have had enormous success by allowing project leaders to interview potential usability engineering candidates. This gives the project leaders a strong sense of resource ownership, and eliminates the resentment they can feel when resources are imposed on their projects without their approval. An initial interview ensures immediate buy-in, and in these situations, the usability engineer starts out as a more integral and integrated team member, laying the groundwork for success.

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.

Identifying and Getting Access to Users

Successful intranet projects require access to users. In situations where this is discouraged, information may have to be gathered covertly. In situations where this is strictly forbidden, it is important to understand the limits and to find creative ways to work within them.

Identifying users of an intranet is as difficult as it is crucial. Getting access to them is more so. This proved to be a real challenge in Example A for several reasons. As is often the case, the project owners were concerned that employees would come to expect too much of the new portal. As a result, the usability engineers were told not to show associates prototypes or concepts that might "get their hopes up." Attempts at gathering information through field studies were repeatedly denied. The usability engineers were not to create any expectations at all, but to generate excitement whenever possible.

What to do? The project leaders repeatedly described themselves and the developers as typical users, suggesting that the team observe them instead of going out to the stores. The usability engineers accepted the offer and treated the observations as sales opportunities. In one example, the usability engineers observed a project leader retrieving information from the newly designed intranet site. After conducting the observation, the usability engineers described the type of information that could be provided by actual (rather than representative) users, and how a fresh set of eyes might be useful. Eventually, the project leaders referred the usability engineers to customers who could be relied on to provide less biased feedback.

We took every possible opportunity to educate the business and technology sides of the project on the types of information that we could gather through field studies. One of the most difficult concepts for us to land was that users could provide us with useful information about their use of the intranet even if they had never used it. For example, users could have let us observe their current work areas, showing us their offices, allowing us to understand what systems they used and how an intranet site could make their lives easier. These educational opportunities challenged our ability to remain positive and resilient At times we spent more time complaining about our limited role than working to make the best of it. We should have visited the retail environment and gathered the information we needed any way we could.

In Example B, the usability engineer had access to the current site's webmaster and the supervisor of the employees who were most likely to use the site. Both of these people were invaluable resources. Although the client's Project Manager had forbidden the usability engineer from asking these experts what the site would be used for, the usability engineer was able to gather this information by asking good, carefully framed questions about the underlying technology. The usability engineer initially asked what type of files were being accessed on the site and then followed up with a questions about how the users would use the files and what the users^tneeds were for the files. The subject matter experts didn't share the project managers' ideas that all the analysis was already complete and were therefore willing to discuss the users' need with the usability engineer. This data, covertly gathered and analysed, was used to build a solid information architecture, which was critical to the success of the site.