Experience Map
PI System Experience
Experience Map
PI System Experience
PI System Experience
Project
I was tasked with illustrating the journey of the PI System user experience from installation to maintenance. This map was used to highlight areas of opportunities, and define problem spaces from the insights which the map uncovered. The project helped introduce design research and journey mapping to our development teams as well as kick-start two large-scale projects at OSISoft.
Challenge
Introducing new concepts and ideas to teams in order to communicate effectively. Establishing a working relationship and rapport between UX and Development.
Duration
2 months
My role
I acted as the UX Researcher.
My Key Responsibilities were to:
- Collect and analyze information from primary and secondary resources
- Outline user journey across multiple products at a high level
- Create and deliver visual representation of the User Journey
- Identify pain points and opportunities in current user Journey
- Present research findings and opportunities to development and management teams
- Build working relationship with Product Managers and Development teams
Understanding the Problem Space
Primary and Secondary Research.
Spoke to stakeholders and customers about the current experience of PI. Read through support cases and existing documentation to supplement primary interviews.
Research Analysis
Organized the ideas, quotes, and feelings from research into large buckets. These buckets broadly defined the steps a user must take in order to set up and get value from their PI systems.
Stakeholder Review
Brought in stakeholders to review and vet the journey map at its preliminary stage. This was to ensure that stakeholders were involved and understood the process.
Experience Map
After the task analysis and primary interviews I outlined pain points and highlights within the experience for users.
The concept for an experience map was quite new for most of our development team and they appreciated being able to take a step back and look at the system holistically. At some points the information seemed a bit shocking, there were some pain points that were surfaced only by seeing how each component affected the other. It was critical to involve the development teams and stakeholders in the process because it allowed me to explicitly show how our users genuinely interacted with the system and I could challenge their existing biases in an objective way.
Before
Calculated the area of the empathy map by using time spent on task and quantifying the number of times the task came up in feedback sessions.
After
Removed empathy map to add opportunities. The second iteration was more explicit and easier to understand as a stand alone map.
Identifying Opportunities
Several opportunities were uncovered after reviewing the process at a high level, from installation to management. There were several breaks in the experience and areas that currently had no viable solution.
1. For users, going from a flat list of tags to a functional relational hierarchy they could use to apply contextual data to was a pain point. The task took too much time, there was no clear guidance on how to go get to the ideal end state, and users did not understand what value was gained from using the hierarchy since most of the client tools we provided were not utilizing the hierarchical relationship.
2. Our tools do not provide enough guidance on how to use it or get value from it. The activation energy for users was very steep. Of course once they passed the initial hurdles they would get great value out of it but there was a clear opportunity to improve our guidance and lower activation energy for users. There was also a big dependency on our technical support for getting through everyday tasks and troubleshooting.
3. Managing the PI system was the area with the most feedback. Each product we release has its own management utility, and while the tools themselves are interconnected, the management tools are completely isolated. This, coupled with the lack of guidance, make managing the PI System a burdensome task.
Getting Buy In
I presented the experience map to members of our engineering and customer support departments. My team lead also presented the document to the engineering department so that we could reach a wide audience. The map helped ground some of the efforts that had been going on. For example, the company knew that going from a flat list to a relational hierarchy was burdensome but they did not see why or how it affected other products. We needed the big picture view.
By presenting the experience map I was able to gain momentum for the UX team and work with the customer success and engineering teams to help alleviate the pain points we had uncovered.
Summary
- The Experience Map kicked started two large-scale projects that tackled the two largest pain points.
- This project exposed the company to the experience and empathy map techniques. The Experience map was used in discussions across the company, within Marketing, Customer Success, and Engineering. Many teams began using their own Journey maps to tell user-centric narratives, this was especially important for the Customer Success Team.
- Keeping stakeholders involved during the design and research processes builds trust and rapport. They had previously had little visibility into how the UX team functioned.
View Related Works