ionite is an enterprise platform for software procurement and compliance. I was its founding product designer. I came back on contract to design its hardest screen, and it needed a kind of domain knowledge I did not start with. This is about how I closed that gap, and the part of the work that closing it doesn’t touch.
The screen was the control configuration surface: where an organization defines a security or compliance policy and sees which products and applications satisfy it. Something with the depth of a Vercel or Stripe configuration screen. You don’t design it by making it look clean. You design it correctly only if you understand enterprise software procurement, the approval chains, the distinction between a control and the products that satisfy it, how a team actually moves a tool from evaluation into production.
That domain fluency was not something I had. Every part of the screen depended on it: the interface copy, what the screen should even contain, which states carried weight. Without it I’d be guessing. So the problem wasn’t “design a screen.” It was “design a screen that needs knowledge I don’t start with.”
What that used to cost
Two years ago this screen would have cost me weeks before I designed anything, and none of those weeks were design. They were catching up: hundreds of questions to engineers and product owners, rebuilding their mental model out of other people’s patient explanations, and a real chance I’d still miss the nuance that separated a right design from a reasonable one. That gap was a professional limitation. I’m not going to pretend it wasn’t.
Compressing the ramp
The work started with one artifact: a transcript of a working session with the product owner and the engineers about what the screen had to do.
I ran that transcript with AI as a research partner. Not to design, and not to be told what to build. To get the macro picture fast: what the screen is for, where the real friction sits, how the people who’d use it described their own problem. The weeks of question-asking compressed into a few hours of readable understanding.
The skeptical read is that the AI did the work. A transcript is raw material, and compressing it is only worth something if you know what to ask it. That part isn’t a tool’s skill.
What the transcript couldn’t carry
A model can synthesize what a transcript says. It can’t know what the transcript means, because the meaning is in the people, and the people aren’t in the file.
I knew this team. Their roles, their hierarchy, how each of them talks. So as the model surfaced the discussion, I supplied the layer it couldn’t: this one’s a backend engineer, that one a data engineer, that one a product owner who has actually run procurement. When two people described the same pain in different words, I knew it was one point. When one person’s framing should outweigh another’s, I knew why, and steered the synthesis there. That’s years of working next to specific people, and it’s the difference between a synthesis that’s plausible and one that’s correct.
Four names for one thing
As the screen came together, a naming problem the team had been circling surfaced. The same entity went by four names depending on where you stood: a control in one view, a product in the catalog, an app in the applications tab, a providing product in the control overview. The team was arguing vocabulary, which word should win.
The real issue was structural. The entity wasn’t four things, it was one thing in different roles depending on where you looked from, and the fix wasn’t a single forced label. It was one approved noun, qualified by role: a product in the catalog, a providing product when it satisfies a control, a configured product in the applications tab. One noun, three roles.
The call that mattered more came next. The team assumed the interface vocabulary and the database schema should map one to one. I argued against it. The schema models its layer for its own reasons; the UI models the user’s mental model. Forcing them to match wouldn’t clarify anything, it would make people read one entity as several.
It’s almost better when the UI doesn’t reflect the schema one to one, because a one-to-one mapping makes people think of the same thing as separate entities.
That was the lead engineer, reacting in the room. It’s in no transcript and no model produced it. It came from knowing how interface vocabulary and data models behave, when they should converge and when they shouldn’t. That’s what I was hired for.
Patterns before inspiration
Most designers reach first for inspiration: find something good, match it or beat it. I don’t. Vercel, Stripe, Linear, and Supabase have spent enormous money and research turning interface problems into patterns we now treat as obvious. Nobody reinvents that by accident, so I don’t try. I keep a working knowledge of which patterns exist, why, and how they bend to a specific scope.
That’s what keeps AI from being a crutch for me. When a concept comes back from a model, I interrogate it for fit: this shape shows up three ways across known products, which one matches the scope and the outcome we’re actually building? The library and the judgment about fit are mine. The model just makes the library faster to reach.
The outcome
I delivered a working version of the screen in about a day. The old way, it’s weeks.
Speed isn’t the part I’m proudest of. The screen helped the team see their own problem: how the pieces actually related, and in a couple of places it helped them understand each other. The session that produced it was a problem-solving session with the model as the technical partner in the room. I knew what to ask and when. It knew how to synthesize toward the answer.
Two years ago the domain ramp alone would have blocked this work, and that was a real limit, not a modest one. AI compressed the ramp from weeks to hours. It didn’t make the naming call, or the decision to split the UI from the schema. Those came from years of doing the work, and knowing the difference is the part I can’t hand off.