OSIsoft
PI Display Migration Tool
Convert and migrate old data visualization files to a new format and new location
OVERVIEW
The Display Migration Tool is a Windows app to convert the files/displays of PI ProcessBook (OSIsoft’s old-generation data visualization software) to the format of PI Vision (the company's new visualization app) and store the new displays on the PI Vision server with proper permission settings. It also informs users of the migration capabilities of each file because of feature imparity between the two visualization products. The tool has a short learning curve for first-time users and always keeps users informed of the migration stage and status, as it’s not supposed to be used frequently and the target users generally multitask at work.
The migration tool is critical for customers to move onto OSIsoft's new visualization platform and technology without spending too much effort on rebuilding their hundreds and thousands of existing displays. Before I was pulled in, there was already a version available created by the development team. They got feedback that the tool was confusing to use, so I was asked to do a redesign.
As the team was small and was new to the UX process, I intentionally involved the stakeholders more often in the design process through constant design reviews, testing sessions participation, and collaboration in the Affinity Diagramming exercise. As a result, we moved smoothly in the process with shared understanding and quick alignments.
ROLE
UX / Interaction Design
Usability Testing
Affinity Diagramming Workshop
UI / Visual Design
​
WORKED WITH
- 2 Product Managers (Strategic, Technical)
- 1 Dev Team Lead
- 1 Design Team Lead
- 3 Developers
- 1 Tech Writer
- Customer Support Engineers & Customers (for testing)
TYPE
Windows App
Enterprise Facing (B2B)
File Utility
THE CHALLENGE
Design Problems to Solve
-
The existing workflow of the file migration tool was confusing based on user feedback
-
Users use this tool for only a few times, so it should be self-explanatory to new users
-
Users need to be clearly informed of any migration issues, as not all displays are fully migratable
Constraints & Challenges Facing
Scattered & Limited Research Data
The data we had available was from limited conversations between PMs and a few customers. There wasn't sufficient in-depth research data to help draw a full picture of user scenarios, and we didn't have time to do well-rounded research upfront.
The Team was New to The UX Process
The dev team and the PM had not worked with designers before or exposed to the UX design process. Therefore, they were not clear of how to collaborate and I needed to take full leadership to push the design forward. In the meantime, I needed to educate the team with the UX process and build trust.
THE SOLUTION
Old Design vs. New Design
Design Highlights
2
1
3
4
Clear Guidance on the Flow
​
1. Use steps to guide the usage of the two panes. Since information on both panes needs to be available at the same time, a wizard design won't be appropriate and step instructions are used instead.
​
2. Empty state instructions and contextual help.
3. Use automatic background highlight to guide user's focus. The pane background color changes based on users' progress in order to guide their attention to the right pane. It also responses to manual clicks.​
4. A Wizard design is used for the migration configuration to guide people through different settings with contextual help and allow them to focus on one thing at a time.
Efficiency Support
5. Shortcuts to common actions. a. Links to view reports are given within the confirmation dialog, in addition to the View Reports button at the bottom. b. One-click bulk file import is available for matching files in the Import folder in PI Vision.
​
6. Links to the converted and migrated PI Vision files are provided after migration for users to see their displays right away
5a
5b
6
7
Resistant to Interruption
7. Clear system status is informed not only through proper and in-time interaction feedback, but also through intentional interruptions to the flow with confirmation dialogs. This helps users remember where they were before and what they should do next when they return to task from distractions. An example is the "redundant" OK dialog when analysis is complete.
How did we get here?
Move on to learn about the detailed design process.
THE DESIGN PROCESS
The team I worked with was relatively small and comprised of very senior developers in the company, and they had never worked with designers before. Given such a situation, I decided to involve the whole team as much as possible throughout the design process and produce detailed documentation to help them learn about the UX process and move faster with shared understanding.
01 - Discover & Define
Who's the User? How Did They Feel?
I started the process by having a kick-off meeting with all stakeholders to gather requirements and expectations of the design. The dev team also walked me through their old designs and pointed out some existing feedback and constraints. I also set expectations with the team of our collaboration process.
As there was already some exploratory research conducted by PMs and an initial version of this product available, I decided to create a version of new design first based on available data and conduct additional research later with concrete visuals. I had a separate meeting with the PM to sync up on target user profiles, use cases, and existing feedback to make sure that I have as much user data as possible.
1 / 2
Develop Persona
With existing research data collected I created a persona to give people a holistic view of the target users and highlighted some design strategies based on the characteristics of the persona. This helped me keep the user needs in mind while proceeding with design and also helped the team to better understand the design decision made.
What Can We Infer from the Persona?
-
Andrew lives a hectic life at work and has no time and patience to fumble around in a new tool to learn it over time.
-
He’s always in a hurry and may be constantly interrupted or distracted by other tasks or people.
-
It’s very common for him to leave the work at hand and come back to continue it later.
Therefore, the Migration tool should:
-
Be as straight-forward and intuitive as possible
-
Resistant to interruption
-
Allow easily resuming work from last time
The strategy above worked as a guideline for me to make design decisions along the way.
2 / 2
User Journey Map
With a better understanding of the user and their workflow, I went through the original version of the migration tool to find design problems and gaps. I then created a user journey map to map the problems I found at the different stages users went through to use the tool. It was meant to help the team understand existing issues with context, especially the workflow issues, in a more fun and digestible fashion.
02 - DESIGN
Exploring Possible Workflows
1 / 2
Wireframing - Set 1
After sketching out some screen layouts and functionalities, I created a set of static wireframes to demonstrate the features, flows, and layouts of the tool and organized the wireframes into a user scenario walkthrough to present to the stakeholders for feedback.
2 / 2
Wireframing - Set 2
After a few rounds of discussions with all stakeholders and iterations on the design, we agreed on the following version to prototype and do user testing.
.png)
03 - PROTOTYPING & TESTING
Does Our Design Work Well for Users?
1 / 2
Prototyping & Usability Testing
After the design was internally approved, I then built an Axure prototype and created testing scripts to prepare for a usability testing on the app’s overall flow and layout. We conducted 5 contextual inquiry forms of usability testings with the prototype on our customers remotely. I had participants go through the migration process and think out loud throughout the process. The goal of the testing was to gather feedback on the general workflow and functionalities of the tool and learn about any additional use cases.
I encouraged all stakeholders to sit in at least 1-2 sessions to observe the testing. This ended up with a lot of great discussions within the team after each testing session.
2 / 2
Testing Data Analysis
Affinity Mapping
Since a lot of data was collected through user testing, I ran an affinity mapping exercise with the team to organize the data and identify patterns in user feedback. Again, to educate the team with the UX design process and to help form a shared understanding, I involved both the dev team lead and the PM into this process and encouraged developers to participate when they were available as well. We collaborated very well and generated many insights.
Affinity Mapping exercise
Finding Highlights & Team Reactions
We collected a lot of valuable feedback from those sessions. It was surprising that the majority of the feedback was related to additional use cases to support, which was a sign of insufficient upfront research. Our team, therefore, realized the importance of thorough user research before starting to write codes. Terminology was the second biggest issue, due to a lot of technical terms used. Besides these issues, the design was on the right track in terms of the general workflow and users thought that were how they expected to interact with the tool.
The team did see the value of the UX process and found it very helpful. One of the developers even said that we should do this more often in the future, especially before the development!
04 - ITERATION
Find balance between user preference and technical constraints
1 / 3
Prioritize Action Items
I then synthesized the data and organized them into individual issues to address under different categories with suggested action items to take. I reviewed this with the dev lead and PM and we prioritized the action items. Product backlog items were then created to address these issues by the Dev Lead.
2 / 3
Iterating the Design
With the insights drawn from the usability testing results and the decisions made within the team (some of the issues we had to skip due to technical and time constraints), I updated the design to address the issues identified. Specifically, I worked with our tech writer to refine the terminologies used in the design.
.png)
Because we synced up frequently throughout the design process and the whole team was more or less involved in the testing and affinity mapping process, we were pretty much on the same page, so we aligned on design changes quickly and made decisions very fast. After the interaction design had been approved I created the UI Design.
3 / 3
UI / Visual Design
Selected UI Components
REFLECTION
Although the team was very new to the UX design process, they were very collaborative and we worked well together. Since the team was highly involved in the entire process, especially during the user testing and the Affinity Mapping exercise, we aligned on designs quickly and iterated rapidly. People were happy about the results and found the UX process very valuable. The developers even said that they enjoyed learning more about users and we should do this more often.
What I've Learned
Working with Team that's New to UX
It is important to take initiatives throughout the process and be collaborative as well when working with people who are not familiar with the design process. Involving stakeholders at each step and explain the science behind the steps would help people gain empathy towards users, see the value of the design process, and get aligned on solutions faster. Detailed documentation of deliverables also helps demystify design and help the team proceed.
The Importance of Upfront Exploratory Research
The majority of feedback we collected from user testing was new use cases that customers expected the design to support. This implied insufficient research before the design started. I was aware of this issue, but since at the time I joined the team was already in the middle of development and the releasing date was close, I decided to move on and gather additional user needs through later evaluative research. The benefit was that with a working prototype, users were better at articulating their needs and generating new ideas. However, we were still surprised at how much we didn't foresee. This was a great lesson to the team that there was a lot more to be done before writing code. One of the developers even said that "We should have done this before."
