Designing in the gaps

I joined Dust as a product designer a few weeks ago. I assumed I’d be designing AI interfaces. Chat windows, prompt inputs, the visual grammar of machine output.

What I’m actually designing is closer to plumbing.

That’s not a complaint. Plumbing is what makes everything else possible.

The problem is specific. People spend a large part of the day switching between tools, re-explaining context they explained yesterday, and looking for information that exists somewhere in the company but isn’t findable when they need it. Dust connects to those tools and tries to surface the right thing at the right moment. The ambition isn’t to replace how people work. It’s to make the parts that already work work better.

What surprises me is how hard that is to design. The product lives inside Slack, Notion and a dozen data sources at once, so I don’t own the full experience. I’m designing in the gaps. Sometimes the interface is invisible and the only evidence it’s working is that nothing feels broken.

Speed of feedback

The team ships, watches how it lands, adjusts. In a few weeks I’ve seen two features completely rethought after real usage. Not through a long redesign process. Someone noticed a pattern in how people were struggling, the team talked about it, and it changed.

There’s also a clear read on what AI is good at right now and what it isn’t. That instinct shows up in the design work. Features get scoped until they’re reliable, rather than shipped at a size that makes them unpredictable.

The hard question

Being inside an AI company is strange. The discourse is relentless. Every week there’s a new model, a new benchmark, someone declaring something dead.

From the inside, the work looks nothing like the discourse. It looks like: why did this agent fail on this input. How do we write onboarding for someone who has never thought about context windows. What’s the right error message when the model genuinely doesn’t know.

The hard question isn’t how to make AI impressive. Demos are impressive. It’s how to make it trustworthy enough that someone will delegate real work to it and not check every output.

I don’t have a clean answer yet. It’s the most interesting problem I’ve worked on.