.png)
June 2023 -
June 2024
Figma,
Miro
UX/UI Design
User Research
User Testing
2 UX/UI designers,
2 developers,
1 project owner,
1 supervisor
Prior to the redesign, PortOps was an outdated downloadable B2B enterprise software application. Teck Resources is the world’s second largest seaborne exporter of steelmaking coal. This coal is used in ~72% of global steel production. For the redesign, my main responsibilities included conducting various user testing sessions, synthesizing and documenting my findings, completely redesigning the UI, and realigning the experience of the tool to reflect our users’ needs.
I was put into this project as the primary UX/UI designer along with a staff designer, Vivien Anayien. This tool is vital for the exportation of steelmaking coal and allows a productive supplying of the global demand due to increased urbanization. In reality, it was also old, slow, and extremely outdated. The business was passionate about refreshing the tool to allow better productivity, and I was excited to tackle this challenge. Prior to this project, I also worked at Teck as a co-op.
PortOps when I first joined in June 2023
Our users, Teck's Coal Logistics team, work out of an office by Waterfront, Vancouver. I visited their office and obtained permission to visit the terminals where operations to distribute coal are performed. They and workers at Neptune Terminals are consistently communicating to ensure effective workflow. Both teams have the same goal: successfully exporting coal to our customers as quickly and efficiently as possible. PortOps is the centre of where shared data lives.
A simplified, very high-level graphic to show how coal transportation looks like
Before the redesign...
“Although some functions are good, the system is very slow and has many bugs.”
“PortOps works as intentioned, for the most part. However, it is fragile in the sense that it will crash or create problems for the user if not used in a particular way.
“After spending a year within the system, I am fairly confident I can get the information I need and submit reports as needed, but I often need to request the help of IT. The system is very slow, which makes data entry and editing cumbersome.”
“The user interface is not user friendly.”
The quotes from above were from initial user interviews for a UX audit of PortOps. The UX audit was conducted by Vivien prior me joining, and the audit found system slow and complex. Upon opening the app, it is clear that it was not designed with scalability and adaptability in mind. To do any task, users spend 35-45 seconds waiting for the page to load. Throughout the years, a large number features have been added while nothing has been removed. This lead to many unused features cluttering the interface that no one knew the purpose for.
To tackle where to start, we began conducting user research using two core techniques: interviewing and the role of observation. We observed and watched each user complete their daily tasks while having them explain what they were doing and why it was important. During observation, we noted down how they interact with the tool, including their actions, behaviours, and decision-making processes. These sessions were conducted both in-person and through online meets.
Usability and functionality workshop
“How do you go about receiving a train?”
“How do you communicate with the terminal team during [said] process?”
"What challenges do you encounter when trying to [perform a specific task]?"
"Show me how you typically [accomplish a certain goal] using PortOps."
“What KPIs and metrics are you mostly working with while [completing a specific task]?”
We saw a distinct pattern in the user data suggesting that PortOps is slow and confusing to navigate even for those who have been working with the tool for years. Many users have come up with their own “hacks” or work-arounds to quicken their workflow. There are a lot of features and components that users never knew existed nor were they useful for them. There was no previous documentation on the existing PortOps, so next, we decided to do a card sorting exercise with them to understand how users categorize and organize information.
We hosted various workshops with the users to have them each show us their most important tasks and what their most preferred workflow would be. This helped us gather ideas on how to create the new IA.
Old (top) vs. New (bottom) PortOps information architecture
We designed the new IA to be much more consistent while also keeping the user’s needs and mental model in mind. Main flows are no longer nested in multiple levels and are still primarily kept the same. We made it flexible by assessing potential limitations to accommodate for future growth or change of content, so the new IA can easily expand or evolve as necessary.
Various sketch concepts for I did for PortOps
Due to the fast-paced nature of our project, I sketched wireframes to quickly explore concepts and communicate ideas with Vivien and the rest of my team. Doing it in Procreate allowed me to make fast iterations and refinements during collaboration discussions, and it helped us identify potential issues and areas for improvement before creating wireframes.
Many of the quick and easy solutions for pages include figuring out exactly what our users need to perform their tasks and removing everything else, like how we did in “Blend Splits”. We wanted to keep workflows that were already working well for them without unnecessarily reinventing the wheel.
“Yard Management” went through many concepts where I designed various potential solutions and worked with our users to come up with the best design for them. A couple features, like the “Yard Management tool”, needed a complete redesign. This included realigning and defining components that were previously ambiguous. We spent a copious amount of time with the users to ensure our designs visually and accurately reflected their workflow.
Figjam board where we collaborated with devs to communicate differences between implementation and design
While following the dev focus of the sprint plan, we quickly realized early on that our design concepts weren’t being accurately depicted. This also affected our user testing sessions as many users were confused about why screens looked different from previous prototyping sessions and had concerns regarding what they were seeing. Although previous hand-offs from us included in-depth directions (eg. how to access component properties via Figma Dev mode, design documentation, etc.), we recognized that we needed to find a more effective way of collaboration.
As the devs had supported us during our design sprint, we sat down and talked about how the design team could provide better support to them during implementation. We found that the devs preferred to have reoccurring collaboration sessions where the design team could quickly communicate and provide feedback. I prioritized being available for them to address any ambiguities to promptly minimize misunderstandings or delays. While facilitating these sessions, I also documented changes in a shared Figjam board with side-by-side implementation vs. design concept screenshots to communicate the rationale behind adjustments.
This ended up working really well for us! Our designs are now accurately portrayed in integration. The collaboration between us became an ongoing process while we continuously made refinements to optimize the final product.
Throughout the project timeline, I found that both the time and day of our testing sessions affected our productivity and efficiency. Because of the two-week sprints, simply moving sessions from afternoon to morning allowed me to spend the rest of the day reflecting on feedback rather than doing it the next day.
Because of the different workflows between us and the developers, finding a shared place for documentation is important. Initially, this wasn’t as smooth of a process as it may seem. We tried logging in Confluence, Miro, and even on the Figma file itself. This just became a mess because now there was information everywhere, and we found ourselves needing to dig through them to try and find what we needed. Eventually, we found that Figjam was our preferred way to work and it was easily accessible to all teams. This made our workflow much smoother!
The PortOps redesign had an extremely tight schedule. I also had no prior knowledge or experience with anything related to mining, but the nature of this project required me to understand a lot of the workflows. Because of that, initially, I found myself struggling to manage with time. I quickly had to find ways of dealing with all the information and the timeline. I learned that identifying core requirements, keeping note of daily priorities and must-dos, and writing detailed documentation helped me adjust.
© Cathy Yan 2024. Made with love and iced lattes
