The Challenge
San Francisco Health Plan uses SharePoint for its intranet, file storage, and collaboration. However, common perception was that it was used only as a document repository with limited search capabilities. In a couple of smaller scaled projects and intranet designs, I worked with multiple departments to understand why that perception was widespread and how could we improve it. This case study details multiple independent projects that generated similar deliverables and lessons.
Duration
6 months
Tools
Adobe XD, OptimalSort, MS SharePoint, Google Analytics
My Process
Design
Wireframes
User Interface
Functional Prototype
Testing & Iteration
In Person & Remote Tests
Discover
Project Charter
Survey
Interviews & Focus Groups
Card Sort
Define
Task Flows
User Stories
Tools Review
Product Roadmap
Discover
How do we store and access documents?
All of these projects started with a staff member approaching me and asking to make a more user friendly site or knowledge base. The reasons were either driven by department goals or as a continuous quality improvement initiative.
The intranet administrator already knew we had to move towards using metadata tagging because it would save storage space. But, the question was how should we structure it? I met with the respective stakeholders that were leading the team of users to understand their own teams’ goals.
Survey
I always started with conducting user research: who are the primary users of the document library or knowledge base? What is the scope of the research? I constructed survey questions based on their job functions and main tasks. For example, for a knowledge base, when and how would they normally access documents?
When asking the IT department, they said…
Click to Enlarge
When asked to describe their experience, though, when searching documents…
“Things seem scattered and/or incomplete”
“Not very intuitive so I bookmark a lot”
“Its hard to find things unless you know exactly where to look”
“Searching is terrible unless I know the location to look. Using the search bar either brings back nothing or dozens of documents to see”
❇️ In summary, most users wanted to use the search bar, but had a negative experience finding documents.
Interviews (Stakeholder and User)
I did individual interviews to represent sub departments and teams. Since they are internal, we usually met in conference rooms to discuss.
❇️ One finding that was particularly interesting was that users were saving files in different folder locations all over the intranet, and it was harder to jump from one location to another.
Focus Groups
When possible, I facilitated some focus groups with users. I typically used focus groups if they were similar users (i.e. were in the same department or team) to get a more wholistic perspective on how they currently deal with the problem.
For example, in one interview we discovered that our System Administrators didn’t even use SharePoint’s interface because of security permissions and need to keep sensitive files hidden from other business users.
Card Sorts
Since all of the intranet projects related to storing information, I took content inventory and asked users to organize certain groups or topics based on what they thought makes sense. I conducted a closed card sort for the IT department, for example. I took previously used sections of the site and asked users to group them. The top 3 entries are below that showed most agreement between 4 participants across different disciplines.
Tools and Department Goals were categories that were not originally on the intranet.
❇️ Through this phase I discovered the behaviors and challenges users faced. While each department was different, overall behaviors were the same: search was popular, yet did not meet expectations; and sections of each site were not matching user’s mental models.
Define
User Stories
What do users wish they could do in SharePoint?
For each project, we created some form of user stories or statements. Since I was working directly with the users in developing the product, they could easily put a wishlist of what features they would benefit from.
Click to Enlarge
Within SharePoint, in every project we created user stories to document transparent requirements.
My teams used different approaches per project. For larger groups of stakeholders, the PM and I created an online roadmap feature for users to contribute user stories. Users could agree to certain statements if they think they would benefit from the entry.
For smaller groups, I held an in person workshop to solicit input.
Tools Review
Once I gathered the business and user goals, I met with the stakeholders to identify what solutions were possible using our intranet. The objective was to leverage existing technology to fit our needs. I worked closely with a trainer and administrator to learn the features possible on SharePoint in the past.
Click to Enlarge
For the Member Eligibility team, we created a list of user stories and connected them with features already available in SharePoint.
Design
Wireframes
Since I was working with some pre-built interfaces in SharePoint, I was able to rapidly prototype hi fidelity designs.
❇️ Since we determined that one common design issue was navigating back and forth between pages, we want to create a flow with fewer screens to flip through. We also introduced a tab feature that flips between document filters on the same page.
User Interface & Prototype
The interface needed to comply with or match the marketing intranet standards to ensure a consistent user experience. Since at the time of the project they were not drafted yet, we took inspiration from previously designed pages from the marketing team.
This is the navigation banner used around the ITS intranet. It needed to match the aesthetic of the rest of the intranet designed by marketing.
The marketing home page banner for SFHP.
Design resources from marketing.
Next Steps
Facilitated and Remote Tests
I am planning to do a combination of facilitated and remote tests to understand how users interact with the new flow. Up to this point we have been evaluating features and stories, but need to ensure that the entire file finding experience is seamless and more efficient than the previous way. I look forward to seeing how users adopt the new site so that we may enhance our designs.
Metrics and Tracking
For some sites I also set up Google Analytics to understand which pages yield more frequent and longer visits. This information may be used to refine the navigation of the site.
Outcomes
Artifacts
Throughout the process I created a set of artifacts that justify the design decisions the team made. It was more easily traceable to understand the evolution of each web product. Additionally, it made the start up time for creating a new project faster, since older artifacts were used as templates for new ones. For example, after I worked on the Customer Service team’s knowledge base, I was able to deliver parts of the new knowledge base with similar scope in half the time.
New Processes & Features
Some designs added functionality that allowed business users to carry out processes they have not had before. For example, the lists and libraries we created have auditing features to see number of visits a users makes to the site, as well as where in the process a document is during its drafting and publishing phases.
Lessons Learned
Leveraging existing technology
This project taught me how to design with existing constraints based on a particular application. Having a feature assessment and product roadmap really helped frame the solution. I was working with a trained background in SharePoint as well. Leveraging existing tools, however, did not saved time for teaching users. Since many features weren’t used or highlighted before, I worked with business users and staff to take advantage of the tool.
User Empowerment
I learned that by designing with a user collaboratively, rather than just touching base with them on use research and testing, it made a stronger product with faster iterations. Since I was working directly with internal users, it was easy to get feedback quickly and pivot if necessary.