Moving a critical maintenance workflow off a legacy system.
Dugo is a B2B platform used by telecom companies to document and visualize maintenance activity across critical network infrastructure. Our client, one of the largest telecom providers in North America,was in the process of adopting Dugo, but still relied on a legacy system to document issues found by technicians in the field.
I led discovery, product definition, UX/UI design, client workshops, testing, and implementation support, working with users and stakeholders, Dugo's product team, and developers.
MY ROLE
Product Designer
TIMELINE
May - June 2022
TOOLS USED
Figma, UserInterviews.com, Dovetail, Miro
We were asked to build a source of truth, but the data itself was the problem.
We were initially asked to build a dashboard in Dugo that could pull data from a legacy reporting system. The goal was to give managers one place to understand maintenance problems across the network. Before designing it, I interviewed the field technicians creating those reports and the managers relying on them.
The issue went much deeper than visibility. The legacy software was slow and difficult for technicians to use, and much of the most important information was captured as free text. The same problem could be described dozens of different ways, which meant managers could not reliably quantify how often issues occurred or identify patterns across sites.
Instead of connecting the legacy system, I proposed replacing the workflow.
Affinity mapping key insights from conversations with field technicians and managers to help understand main pain points.
The issue reporting process seemed simple from a bird’s-eye view. On the ground, it was far more complex
At a high level, the process looked straightforward: technicians visited a site, completed the work, documented what happened, and submitted a report for managers to review. However after speaking with the technicians who were on the ground reporting and the managers who reviewed the documentation, dozens of edge cases emerged. What seemed like a simple workflow became a complex branch of possibilities. Understanding every branch in this tree was critical to building a new process that didn’t end up causing the same problems as the legacy system.
Mapping workflows
Designing for every edge case
In the end, we did build a dashboard - one that could truly be used as a source of truth.
The client still got the visibility it originally wanted, but the dashboard was no longer trying to compensate for a broken reporting process. Because issues were now being captured consistently inside Dugo, managers could surface unresolved problems, understand their status, and begin identifying patterns across the network.
I stayed involved through implementation and later ran feedback sessions with more than 30 users to understand how the new workflow was working in practice and identify further iterations.
Reflection
This project reinforced something that has shaped how I approach product work since: a feature request is often a description of the symptom, not the underlying problem. The client’s dashboard request made complete sense. Managers lacked visibility, so better reporting seemed like the obvious answer. But tracing the problem back through the system showed that the higher-leverage opportunity was upstream, in how the data was being created. The most important design decision was not what the dashboard looked like. It was deciding that we should not build it on top of a workflow that was already failing.