upa - home page JUS - Journal of usability studies
An international peer-reviewed journal

User-Centered Design in Procured Software Implementations

Jen Hocko

Journal of Usability Studies, Volume 6, Issue 2, February 2011, pp. 60 - 74

Article Contents


Early Challenges and Realizations

The following sections discuss some of the early challenges we faced and realizations we had while working through the process.

Recognizing the COTS implementation as a change management problem

Although feedback about the System Services company-facing site was positive, the SharePoint implementation team was concerned about how long the project took to complete. There were several causes:

While these factors are often recognized when a UCD process is used to develop custom applications, they were not, at first, seen as applying to a COTS implementation like SharePoint. There were also additional factors that the author believes could arise more frequently in COTS implementations in general:

Most of these factors align with documented change management issues (rather than specific problems with SharePoint technology or the UCD process), as shown in Figure 3.

Figure 3

Figure 3. Managing complex change from Knoster, Villa, and Thousand (2000)

The SharePoint implementation team did not explicitly consider or discuss many of these change management factors as part of the initial plan, but quickly started to see that successful change for a project of this nature required vision, skills, incentives, resources, and an action plan (Knoster, Villa, & Thousand, 2000). These change management factors needed to be discussed and agreed upon by the SharePoint implementation team and any department undertaking a migration effort. Lack of any component could have negative consequences, some of which were experienced throughout the course of the early implementation projects.

Creating and sustaining a solid information architecture

In addition to recognizing that SharePoint migrations required attention to change management processes as much as custom development projects that included UCD do, the author also quickly learned that revamping each departments’ information architecture would require a greater level of effort and guidance from usability specialists than originally expected. For example, some SharePoint sites initially went live without support from a usability specialist, and received negative feedback from staff. This feedback was enough to halt user adoption and the department’s migration, and so the author was called in to investigate what the problems were. After conducting a few interviews, it was discovered that users were confused by the creation of both company-facing and internal sites for a single department (when there was no need for the separation given the user base’s information needs), as well as mixed-model items appearing in the left navigation bar’s Site Hierarchy (e.g., application, team, and project names in one list). (See Figure 4. Note that the Systems Services company-facing site design customized their site to hide the left navigation bar and therefore did not encounter this issue.)

Figure 4

Figure 4. Business applications’ Site Hierarchy in SharePoint

Where the site divisions were concerned, it became clear that a “one size fits all rule” would not suffice; usability specialists were needed to help project teams understand when the intended audiences’ information needs differed enough to warrant separate sites, and when one hybrid site organized effectively for all audiences would do. Sub-sites (which showed in the left navigation bar’s Site Hierarchy by default unless customized to be hidden) also needed to have a coherent underlying model to be understandable to target users.

The SharePoint implementation teams’ original vision—basing the top two levels of the hierarchy on organizational structures (i.e., Division > Department) and then leaving it up to the department project teams to organize their team and project sub-sites as they wished—meant that SharePoint Liaisons had to provide more guidance about how to create solid site hierarchies. In addition, departments needed to know how to structure their content to make their site hierarchies maintainable and scalable over time.

To address these concerns, the author created two Microsoft Word document templates and added them to the overall migration process:

Figure 5 shows parts of the Current Information Architecture Evaluation template.

Figure 5

Figure 5. Current Information Architecture Evaluation template

Although any UCD development effort might involve information architecture work, documentation, and plans for maintaining the structure, the SharePoint implementation team also had long-term goals of obsoleting the SharePoint Liaison function. Therefore, the author created each of these templates in two versions: one for SharePoint Liaison-guided migration projects and one for self-service migration projects. Obviously the level of detail required was more involved when self-service requirements were added, because we also needed to educate project teams about how to create and sustain a solid information architecture.

Managing consistency while forgoing customizations

Although the content standards initially discussed by the SharePoint implementation team were replaced with the idea that liaisons could help the organization manage consistency across departments, the sites being designed evolved and ran into challenges.

The left navigation bar on the System Services company-facing site, for example, was hidden for good reason: users had expectations that worked counter to what SharePoint did with this space and were confused by it, so a SharePoint developer helped the project team customize the site to hide it, so users could focus on content that would help them achieve their goals. Project teams in other departments that had no choice but to show the left navigation bar ended up adding links to all kinds of content, further confusing the situation. Another example of a customization was on the Human Resources department’s company-facing site’s Benefits & Perks section. While the best UI widget for getting users to relevant content may have been meaningfully-named tabs, they were also custom-developed and could not easily be replicated by other project teams (see Figure 6).

Figure 6

Figure 6. Human Resources company-facing site: Benefits & Perks section

Because these customizations resulted in increased user confusion and frustration, the SharePoint implementation team ultimately returned to the original plans and constructed department, team, and project site templates and guidelines. The templates added some links to important content in the left navigation bar and advised departments to allow SharePoint to populate the rest. This way, end-users would see the persistent navigation they expected, but would also have the opportunity to learn how SharePoint leverages this area without everyone interfering with the conceptual model by doing their own thing.

Previous | Next