Pipe Portal Redesign

Problem

Modern gas pipelines are degrading, poorly documented, and hard to monitor.
This endangers crucial services, the environment, and public safety, notably in the form of pipe explosions .

To address this pressing issue, a team of engineers in Carnegie Mellon University's Biorobotics Lab built a pipe inspection robot that can provide its gathered data through the Pipe Portal.

However, the Portal's poor usability and aesthetic appeal compared to competitors would discourage industry adoption.

Getting Started

This was my main project as a full-time employee of the lab. I quickly realized 2 big challenges I would face.

1. In a lab of engineers, there wouldn't be any guidance or feedback from UX people.
2. I wouldn't have direct access to actual end-users of the Portal, who were extremely busy business professionals.

Internal team members who had used the Portal for testing would have to do. My project manager was also free about twice a week for design reviews.

Since she was an engineer, I was careful about how I explained my work and justified my decisions. I also kept cautious about her design suggestions, always keeping users in mind.

Research

My first meeting with my PM was a walkthrough of the existing portal.

This was super helpful for getting me familiar with the Portal, its main features, and how end users were expected to use them.

To investigate the current solution more in-depth, I conducted an audit of it.

As I traversed the portal, I tracked key features to bring over in my redesign, glaring usability issues, and any initial improvement ideas. These were noted in a report I sent over to my PM for review.

I also made sure to ask my PM for any insights into end users who she had access to.

They consisted of 3 groups:

This meant I was building a 2B product whose users likely want a quick, practical, and actionable experience over a trendy, minimalist aesthetic.

With that in mind, I looked at how the current portal failed, then synthesized what user needs a successful design would fulfill.

Design

After finding some direction, it was time to start sketching ideas.

Sketching kept me focused on the information architecture rather than the aesthetics, which would be the foundation for that efficient experience.

One of the biggest changes was to the old map sidebar.

I redistributed tabs into separate pages since some involved complex tasks needing lots of space.

Notably, I isolated the Jobs section where users would access data to inspect and annotate, including video footage from the robot.

I also made videos more visible and annotating functionality more obvious in the data display page.

Users use the video with other metrics to identify flaws within the pipe, which they mark by adding observations at certain times in the videos. Thus, I allocated a large portion of the page just to videos and playback controls, then added a bright, clearly marked “Add Observation” button in the top right.

In retrospect, this stage would've been a great time to get feedback beyond my project manager's.

Nevertheless, after several iterations and design reviews with my PM, the sketches were finalized and I was ready to move into building a higher fidelity prototype in Figma. I kept the color scheme neutral to give it that professional, polished appearance while still following the lab's branding, leveraging CMU's red to make important elements more obvious.

Evaluation

We conducted a heuristic-based usability test with 6 lab members. Some had used the old portal before, while others were internal project team members. Participants were asked to rank the design across 7 different heuristics, similar to the 5 areas of improvement.

I chose a heuristics based test because participants were engineers without any UX background, so I wanted to give them a simple, more objective way to measure the interface's usability that also connects back to the 5 user needs I identified previously.

The evaluation was valuable, as we discovered a major flaw in the user flow.

Participants felt the landing page shouldn't be the map, it should be the page that shows all the jobs since jobs hold the data that users want to inspect and annotate.

Development

After making the changes from the usability test and with limited time left, I began developing the data display page.

With only a couple weeks left, I focused purely on implementing the data display page. This page had the most complicated and most crucial functionality.

Due to its ease of use, built-in routing, and my extensive experience with it, I selected the Next.js framework.

Check out the demo below!