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.