User-Centered Design in Procured Software Implementations
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:
- No dedicated time for department project team members to work on the project outside of meetings.
- No prior experience with the UCD process (department project team).
- Little interaction with the department’s executive management and difficulty getting on the executive management team’s schedule.
- No clear decision maker during the design process or delegated owner to maintain the site after launch.
- Several unanticipated tasks that took a lot of time to complete (e.g., worldwide content inventory).
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:
- No clear internal resource for understanding what could and could not be done (via configuration or customization). The department project team, SharePoint implementation team, and SharePoint Liaison were all learning together.
- Unanticipated issues understanding where all the integration points were, and in trying to connect SharePoint to the legacy Help System.
- Different understandings of the SharePoint migration project’s priority (department project teams gave it a lower priority).
- Different understandings of what it meant to “complete” the project. (The SharePoint implementation teams’ understanding of the length of their involvement differed from that of the department project teams).
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. 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. 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:
- Current Information Architecture Evaluation template—walked project teams through the process of assessing their current structure by inventorying existing content and gathering user feedback.
- New Site Hierarchy Documentation template—helped project teams rationalize and communicate their site’s new structure and change process to others so it could be effectively maintained.
Figure 5 shows parts of the Current Information Architecture Evaluation template.
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. 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.