Designing for Humans, Not Just Asset
Updated: Sep 12
The first time I landed in Doha, I had a laptop full of user flows and a head full of assumptions. By the third trip, I had neither — just a much better sense of what our users actually needed, and a stronger conviction that the hardest problems we were solving weren't technical at all.
I was there to run the first full customer rollout of Maintain, Cognite's collaborative maintenance product, at the headquarters tower of a major offshore oil and gas operator in Qatar — the kind of company running production at a scale where a maintenance decision made in an office can ripple out to platforms miles offshore. It was the kind of assignment product designers rarely get in full: not a workshop, not a discovery sprint, but three separate trips over the life of a real deployment — installation, feedback, and expansion — each one forcing me to revise what I thought I knew.
Trip One: Rolling Out to the People Who Asked For It
The first visit was straightforward, on paper. We installed Maintain, trained the target users — the engineers and shift teams who'd actually requested the tool — and walked them through the workflows we'd designed around their stated needs. It went well. People nodded, asked good questions, ran through their first few maintenance logs without much friction.
What I didn't yet understand was how narrow that first slice of feedback really was. We'd built for the people who asked. We hadn't yet met the people who hadn't.
Trip Two: The Feedback Nobody Put in a Ticket
The second trip changed the shape of the project. The goal was simple — go back, collect feedback, and this time bring Maintain to a broader group beyond the original target users. But what I found wasn't feedback in the form I expected. It was an argument.
Sitting in on a session, I watched two user groups start debating — not about the tool's UI, not about a missing feature, but about who was supposed to talk to whom, and why information that should have moved between teams in minutes was instead getting stuck for days. It was a fight about silos. About internal communication. About turf, honestly, more than about software.
At first I read this as a distraction from "real" product feedback. It wasn't. It was the most useful signal of the entire rollout.
We were operating inside one of the most technically sophisticated environments imaginable — the nerve center of a company running offshore oil production at industrial scale — and the bottleneck wasn't sensors, data pipelines, or dashboards. It was two teams who didn't have a shared way of talking to each other. Despite everything automated and instrumented around them, the thing slowing people down was still fundamentally, stubbornly human.
That moment reframed the whole project for me. Maintain wasn't just a maintenance tool competing on feature parity with other asset-management software. It had a chance to be something closer to a collaboration layer — a shared surface where teams that didn't naturally talk to each other could see the same information, at the same time, and stop relitigating who-said-what. The argument I watched wasn't a problem for the product to route around. It was validation of the actual hypothesis underneath it.
Trip Three: Watching It Work Where It Mattered
By the third trip, we were presenting Maintain to an even broader set of users, and I went in watching for something specific: would the tool actually reduce the kind of friction I'd seen in trip two, or would it just add another interface to argue over?
It didn't solve the human dynamics — no tool fully does — but it gave people a common reference point. Disagreements that used to start with "well, my system says..." started instead from a shared view. That's a small shift on paper. In a room full of people who'd been talking past each other for years, it wasn't small at all.
What Being in the Room Actually Changes
There's a version of this project I could have run entirely remotely — user interviews over video calls, feedback synthesized into tickets, iterations shipped without ever leaving my desk. I don't think it would have taught me the same things.
Being physically present, three separate times, with three different combinations of teammates — meant I wasn't just observing the product being used. I was in the room for the business conversations around it: the contract discussions, the moments where a client's frustration or relief was visible before it ever got written down anywhere. You pick up on things in that context that don't survive translation into a research report — the emotional stakes behind a feature request, the political reality behind a "silo," the difference between what a user says they need and what they're actually anxious about.
That proximity didn't just inform this one rollout. It just grounded how I think about my role as a designer. Sitting close to the business side — not just the user side — sharpened my instincts in a way that pure user research never quite does on its own. You start designing not just for a persona, but for a person who has a stake in whether this contract renews, whether their team looks competent in a meeting, whether the tool makes their working life easier or one more thing to manage.
The Parts That Weren't Work
None of this happened in a vacuum, and Doha made sure of that. Between sessions there was extraordinary food, and — genuinely one of the best hours of the whole project — an afternoon at the Museum of Islamic Art, its collection and its Pei-designed building both worth the trip on their own. I went back to a couple of the other museums too, whenever the schedule allowed a gap.
Not every unplanned moment was that gentle. On one trip, the region grew tense enough that Doha's skyline lit up with air-defense intercepts overhead — a genuinely unsettling thing to witness. My colleagues and I did the only sensible thing available to us: we followed the guidance we were given, checked in on each other ♥︎, and then went back to work the next morning as close to normal as we could manage. It wasn't bravado — it was just the quiet, practical calm you find you're capable of when the alternative is letting the whole trip unravel. If anything, it left me with more respect for the people who live and work there permanently, for whom "business as usual" isn't a choice, it's just Tuesday.
Most of the surprises were considerably lighter. On one evening out, a wrong turn and an open door somehow turned into an impromptu Somali celebration — music, food, and a room full of strangers who treated me like invited guests within about five minutes. Another time, someone's contact offered to take me out on a boat along the Persian Gulf, and we spent an afternoon on the water with Doha's skyline receding behind us, which is not a bad way to decompress between user sessions.
The travel itself had its own rhythm. Different people rotated in and out with each trip — and once, in between, just me. There's something clarifying about the solo trip in particular: no one to debrief with in the hallway afterward, just your own notes and the quiet realization that you're going to have to make sense of what you just watched, by yourself, before you can explain it to anyone else.
The Takeaway
If there's one thing I'd tell another designer heading into a first customer rollout, it's this: the feedback that matters most often won't look like feedback. It'll look like an argument in a meeting room that has nothing, on the surface, to do with your product. Pay attention anyway. Sometimes the disagreement you're watching is actually the clearest brief you'll ever get.
Comments