A story about being in the room
They asked for a better inbox. Nobody asked why.
We finally got permission to run the whole process. Then a promise made in a meeting we weren't in decided the answer before we'd finished the question.
How we got here
At some point Chick-fil-A decided to stop renting its food safety tooling and build it in-house instead.
What was communicated to me when I started: it all got built fast, by the dev team, with no UX involved. That's not a criticism of anyone. It's what happens when the mandate is ship it, and they did ship it.
Since then the work has been going back through those applications and cleaning up the experience. That's the job I was brought in for.
Finally, the whole process
Permission to redesign an entire application, start to finish. First one up: Ops Hub Admin.
The requirements were about as loose as they get. My bosses aren't UX people, and they were deliberately trying not to box us in. They figured handing us a spec would sway the thinking, so they held back on purpose. Well-intentioned, and I appreciated it.
What we got instead was roughly: we don't like it, it's just not good, can you go fix it?
So we started close to blind. I was more comfortable with that than I probably should have been, because I've seen concepting and wireframing do the requirement gathering for you. Put something imperfect in front of people and they'll tell you exactly what's wrong with it. That was the plan.
Miro board with my colleague. Problem statement written down. Research questions built with our researcher. Two weeks to first concepts.
Miro board · problem statement and research questions
The requirement nobody mentioned
We presented the concepts. They looked nothing like what one stakeholder was expecting.
What we didn't know: my boss had sat in a meeting with the admins, heard them complain that email was overwhelming. It's how they managed vendors, operators, decisions, amendments, all of it. And he promised them a rebuilt inbox with better organising.
He told us while we were presenting.
Two people heard two different things
Worth being clear about who's who here: the stakeholder who told us mid-presentation that this wasn't what he expected is a developer, and he was in that original meeting with the admins. Same person, same room, same complaint. We just came away with different things.
He heard: they need an inbox with better filtering. I heard: they're tired of untethered conversations.
An admin gets an email about a problem. To see the problem they log into Ops Hub Admin and go find it. Now there's an inbox in one window and the record in another.
The complaint wasn't about filtering. It was that the conversation and the thing it was about lived in two different places.
A month of going back and forth
The hard part wasn't the disagreement. It was that we had no way to settle it.
There was no budget to put both directions in front of an admin and watch. So the whole thing ran on opinion. His, mine, my colleague's, with no data underneath any of it. When that's the setup, the loudest position or the most senior one wins by default, and neither of those is the same as the right one.
So I spent a lot of that month making a different argument than the one about inboxes. I argued for research access. I argued that UX needs to be in the room when those conversations happen, not briefed on them afterward.
Not because we're better listeners. Because we're listening for different things. When an admin says the inbox is overwhelming, a developer hears a filtering problem. Which is a completely reasonable read, and the right instinct if you're the person who has to build it. I hear a question I want to keep pulling on: overwhelming how? What are you doing right before you open it? Where do you go next? What's on the other screen?
Nobody asked those follow-ups, because nobody in that meeting was trained to. That's not a failure of anyone in the room. It's an argument for who should have been in it.
Every version of the conversation came back to the same question, and I never got an answer to it.
How do you fix "email is overwhelming me" by building another email?
That's the part I couldn't get past, and I never got a straight answer to it. He wasn't being unreasonable. He kept making the case that a well organised inbox genuinely would be better, and he'd promised it. So we were two people arguing sincerely with nothing but opinion between us.
Which meant the only way forward was a compromise, and I'd rather build one than have one handed to me.
So I went looking for the version that works
If we were building an inbox, I wanted to at least build a good one.
So I went and studied the products that already do this well. Slack has one. Linear has one. Asana has one. All three give you a single place where things needing your attention pile up, and none of them feel like email.
What they have in common turned out to be the thing I'd been arguing for the whole time. In every one of them the inbox is a routing layer, not a destination. It tells you something needs you and then hands you straight to the thing itself, in context, where you can act on it. You're never reading about a record in one place and then going to find it in another.
That gave me something I could actually stand behind. Keep the familiarity he'd promised. The shape, the density, the way you can scan an inbox. Drop the part causing the problem, which was treating the message as the destination.
I took him three versions of it, each borrowing something different from what I'd found. He stayed with the one that looked most like email.
So we compromised, and then iterated, and iterated again, still without requirements underneath any of it. That part is worth saying plainly: there was a real sense of building this on the fly, making calls in the moment that should have been settled weeks earlier by someone talking to an admin.
Losing it properly
The compromise got us most of the way, not all of it. The final call still landed closer to what had been promised than to what I'd have built on my own.
It wasn't a bad experience. It just wasn't the better one, and I was never convinced otherwise.
But half-committing to a decision you disagree with produces worse work than either option would have. So I built it like I believed in it, and proposed the only honest path forward I could see. Ship it, let people use it for a few months, then go get the feedback we couldn't afford up front.
Final designs · the version now in development
Then someone asked about archived data
Somewhere around the twentieth round of design, someone asked a question nobody had asked before.
What do we do with archived data?
An inbox is built for right now. It's a stream of things currently needing your attention, and it has no natural answer for history. The appeal from eight months ago that someone needs to go look up.
And history matters here more than it might sound. This data doesn't originate in Ops Hub Admin; appeals and waivers arrive from elsewhere in the system, carrying a record of what happened. I'd just come off the 2030 work, so the excellence loop was sitting right at the front of my mind, and that loop only holds together if what happened before stays attached to what's happening now.
So we built a second experience to hold it. Which means Ops Hub Admin now has two places to go looking for the same kind of information: the inbox for what's live, and a separate tab for everything before it.
The archived data question isn't a hard problem. It only became one because we'd picked a shape that couldn't hold it.
Design around the record instead of the message and history has an obvious home. It sits with the thing it belongs to. The inbox created the problem it then needed a second screen to solve.
That's the disjointed experience I'd been describing for a month, arriving on its own without anyone needing to test anything. Real requirements would have surfaced it in week one, and I'd have raised it then.
There was a second thing sitting underneath it too. An inbox holding ten items is fine. At thirty it's the same overwhelm the admins had described in the first place, just in our product instead of their email. We compensated with filters, a lot of them, which is what you do when the structure is fighting you.
I brought all of it up gently. There isn't much value in being right about something loudly.
The dev team asked the same question
We walked the developers through the finished designs, and someone stopped us.
If historical records live in their own tab, and you can also reach them from the inbox, what's the point of having both?
Then the room looked at the UX team to answer it.
I didn't have a good one. That was the argument we'd been making for a month, arriving from a completely different direction, from people with no stake in who won it.
The thing I keep coming back to isn't that I was right. It's that each decision made the next one harder. The inbox needed filters. The filters needed a second home for history. The second home needed a reason to exist. None of those were bad calls on their own. They were all downstream of one call made before we were in the room, and every one of them cost design time that a real requirement would have saved.
Where it stands
It's in development now. I compromised on most of what I wanted, which is how this works, and I'd do the same again in the same position.
I want to be fair to the result too. I'm not unhappy with it. It isn't the version I'd have built alone, but it's a real improvement on what was there, and it will make those admins' days better than they are today.
And there's a reason the risk here was acceptable that I'd be dishonest to leave out. Somewhere between six and twelve people use Ops Hub Admin, all of them internal. If it launches and doesn't fully land, we'll hear about it within a week, from people sitting down the hall, and we'll fix it. That's a genuine argument for shipping and learning rather than testing first, and I understand why it was made.
It's just not an argument against research. It's an argument that we could afford to be wrong, which isn't the same thing as being right.
What I'd take from it
Being in the room isn't a courtesy. It's the whole job.
Every argument in this project traces back to a conversation we weren't part of. Not because anyone shut us out. Nobody thought to include us, and the cost of that only shows up weeks later, when the work has already been promised.
And you can lose an argument without losing the work. I still think it's the wrong answer. I built it like it was the right one, because that's the job, and because a version I half-believed in would have been worse for everyone.