User-Centered Design in Procured Software Implementations
Journal of Usability Studies, Volume 6, Issue 2, February 2011, pp. 60 - 74
Article Contents
Case Study: The Microsoft SharePoint Implementation
The following sections discuss how usability got involved in the project, some of the challenges and realizations we faced while defining and iterating on a UCD-infused migration process, and the final push toward a distributed implementation model.
Setting the Stage for Usability Involvement
In early 2008, the author’s company decided to purchase Microsoft Office SharePoint Server (MOSS) to replace a custom-built application that enabled staff to share and collaborate with each other on project-related artifacts, such as Word documents and Excel spreadsheets. The organization was also planning on replacing department and team intranet pages with SharePoint pages, because they would be more easily maintainable by end-users. Because it was a forgone conclusion that SharePoint would be purchased, the implementation project team’s initial objective was to discover the benefits and limitations of the technology and decide how best to proceed with a company-wide migration.
To start, the implementation team focused on running a pilot rollout. Test cases intended to exercise and get feedback on specific SharePoint features were documented and distributed to two teams in the Development department. Although the test cases were not explicitly written as use cases with end-user goals, they were based on some tasks users were expected to do with SharePoint in the future (see Figure 1 for an example).
Figure 1. Example SharePoint test case
After several weeks there was little response from the teams. The author offered to help the SharePoint implementation team collect feedback by
- administering a preliminary survey in SharePoint to get participants into the system and to learn more about their team and how they worked today,
- observing a subset of participants while they worked through the high priority test cases (along with another usability specialist), and
- administering a follow up survey to gauge participants’ thoughts after having tried SharePoint and to explore whether they felt it would improve how they work.
In total seven participants were observed for 60-90 minutes each. The participants were from a variety of functional roles (engineering, quality engineering, documentation, technical marketing, etc.) and had no prior SharePoint experience.
Usability specialists’ observations of the participants helped the SharePoint implementation team discover which features were most and least valuable to participants and which would require the most change to participants’ current workflow. We also uncovered several aspects of SharePoint that caused participants frustration or confusion—most were primarily due to basic usability issues and users incorrect assumptions about the product’s conceptual model.
Usability specialists’ discoveries existed at a level far deeper than what demos could elicit. In fact, most demos of SharePoint garnered positive reactions, while observations of actual use led to questions like, “Are you really going to make me use this?” and negative feedback such as “an overwhelming and unintuitive interface.”
As a result of the pilot rollout feedback, the SharePoint implementation team (which now included a usability specialist) adopted the following strategy:
- Recommended that an initial implementation include only a subset of SharePoint features (document management, search, etc.) that were most valuable to users.
- Planned a phased rollout, which would start with the IT department and then proceed through other departments based on business need and enthusiasm. This action-oriented process would allow the team to learn from the challenges of an actual rollout and revise processes and support as necessary (Vilpola, 2008).
- Formed some preliminary thoughts around
- how to set up a SharePoint taxonomy (including how to centralize the growing and disparate international office content),
- what the various site templates might look like, and
- content standards for the organization.
The SharePoint implementation team also talked about the best ways to help departments migrate their content into SharePoint. The team created the concept of a SharePoint Liaison—a person who would help department-specific project teams
- learn the basics of SharePoint and be the first contact for support questions (i.e., technical trainer/support role),
- understand other SharePoint-related projects, as well as technical and organizational decisions that affected the department’s migration and/or workflows (i.e., program manager/change management role), and
- structure and design the new sites (i.e., user researcher/information architect/interaction designer role).
The SharePoint Liaisons in our organization were most often usability specialists, for several reasons:
- Our internal usability specialists already interfaced with users in many business areas while working on custom built applications.
- Because of the pilot, the SharePoint implementation team started to see how usability specialists could add value to their migration efforts.
- The SharePoint implementation team understood that there would be many site re-design efforts as part of the migration.
Like any user-centered design project, having an early “seat at the table” helped usability specialists get up to speed more quickly with the technology’s opportunities and constraints, and helped influence the overall migration process so that it kept the focus on users and their goals.