On building end-to-end ownership as a designer in an AI-first world
There’s a conversation happening in design circles right now about whether our role is disappearing. Whether AI is coming for our relevance, our seat at the table, our reason to exist.
I don’t know what the future looks like. Nobody does. But I’ve spent the last several months doing work I couldn’t have done two years ago – not because I became a better designer in the traditional sense, but because AI gave me access to territory I previously couldn’t reach alone.
When I saw a design problem hiding inside a technical one
We were building an automation product, and at some point the momentum stalled. Not dramatically. Just that quiet kind of stuck, where you can feel the problem but can’t quite name it.
The issue was somewhere in how the building blocks of the product were structured. How granular should the components be? How much should they do on their own vs. combine into something larger? That’s not traditionally a designer’s territory. My usual move would have been to ask an engineer to explain it, wait for their time, and hope the translation held.
Instead, I started asking AI.
I want to be honest about how that felt: uncertain. I didn’t know what to ask. I didn’t know if what I got back would be reliable, or whether I’d end up confidently suggesting something that turned out to be nonsense. The fear of sounding wrong in a way that would undermine credibility was real.
But I kept going. In practice that meant connecting Claude to our internal documentation and API references and working through the priority workflows one by one – translating what I could read, iterating on what I couldn’t. Bad questions, partial answers, better follow-up questions. Slowly a picture formed – and then something shifted. I wasn’t just understanding the problem anymore. I could see where a designer’s thinking could actually contribute to solving it.
The challenge was essentially this: if the components are too small and atomic, the product becomes maximally flexible but maximally complex – users have to assemble everything from scratch every time, and that’s not usable. If the components are too large and polished, they’re easy to use but too rigid – they won’t cover enough real-world cases. Finding the right balance is a technical question on the surface. But underneath it’s a product design question: what is the minimum building block that gives users enough flexibility to build what they need, without exposing them to the technical complexity underneath?
That’s when I recognised the parallel to atomic design. Not as an analogy I reached for to explain myself to the team – but as a genuine framework for thinking through the problem. The question of how granular your components should be, and where the line sits between flexibility and usability, is one designers have been wrestling with in UI systems for years. The same tension exists in automation design. The vocabulary is different. The problem is the same.
From there, I used AI again – this time to translate my thinking back into technical language. To take what I’d worked out as a design position and find the terms and framing that would let me bring it to the engineering conversation in a way they could engage with. Not to sound like an engineer, but to be specific enough that the idea could be evaluated on its merits rather than lost in translation.
The next day I brought a proposal to the team. It landed. The conversation moved. A few days of back and forth with an AI produced a complete component map – and engineers were building on it within days of seeing it.
You don’t have to go all the way. You have to go far enough.
Here’s what I didn’t fully anticipate. I knew exactly where my understanding ended.
I could write the suggestion clearly. I had the concept. But when the conversation in the room went deeper – when engineers started adding detail, asking follow-up questions, using terminology I hadn’t encountered yet – I knew I was close to the edge of what I could hold.
That’s uncomfortable. There’s a gap between what you can articulate on paper and what you can defend in real-time, and I felt it.
But I’ve come to think that discomfort is not a failure state. It’s just the new shape of the work. The goal isn’t to go all the way into someone else’s territory. It’s to go far enough to have something real to contribute – a perspective, a question, a frame – and then be honest about where you are. A product designer doing that is not overstepping. That’s exactly the job: finding the frame that makes something communicable, and trusting that the contribution is worth making even when the expertise isn’t complete.
Owning the conversation, not just the screen
The second story starts with a conversation I had with my developer about a question I kept coming back to: how could I contribute meaningfully here, without being dependent on him every time – and without stepping on the parts that weren’t mine to touch?
We were building an AI copilot for the automation product – an assistant that would help users create and understand automations through conversation. The functional side of it, making the agent actually build automations in the background, was his domain. I wasn’t trying to influence that. What I cared about was the “how” – the tone, the adaptive voice, when the agent asks a clarifying question rather than assuming, what it never says regardless of what the user asks. The personality of the conversation. That distinction – the “how” vs. the “what” – gave us a clear way to collaborate.
Because in a conversational interface, those decisions don’t live in Figma. They live in the file that defines how the agent behaves. And product design has never really been just about what happens on screen – it’s about how a product communicates. How it asks questions. When it speaks and when it listens. What words it chooses when something goes wrong.
The territory is getting larger.
So are the opportunities to shape it.
Once we’d mapped out who owned what, he set up a workflow that made that separation real. The tone and voice lived in a dedicated markdown file I could edit directly in GitHub – no code, no engineering context needed. When I committed a change, it deployed automatically and I’d get a Slack notification. From there, I’d open the product, talk to the bot, and see what changed.
The testing side mattered too. Prompt design can behave unexpectedly – a small change to personality can quietly affect something functional, and you often won’t know until you’re looking at a broken flow. So we set up tests to run against any change I made, making sure that whatever I did to the “how” didn’t accidentally affect the “what.” It made the iteration loop feel safe. I could experiment without the risk of quietly breaking something I didn’t fully understand.
A system prompt is a design artifact
It has an audience. It has a voice. It has edge cases that matter as much as any error state in a UI. It has things it should always do and things it should never do. It can be tested, iterated, done well or badly – and the difference is felt immediately by the person on the other end of the conversation.
The skills that make someone a good product designer – knowing who you’re designing for, understanding what they need in a moment of uncertainty, knowing what to leave out – apply directly to writing and refining a system prompt. The craft is the same. The file extension is different.
What made this possible wasn’t a new concept – conversation design has been a design challenge for a while. What was new, at least for me, was being able to actually do it without depending on someone else to build the bridge. AI gave me enough context to contribute directly, iterate independently, and stay in the loop on something that would previously have drifted into engineering by default – not because it belonged there, but because that’s where the file lived.
The territory is just larger now
I’m not going to pretend I have a confident answer to where this all goes. But I don’t think the right question is whether designers will be replaced. I think it’s whether designers will keep up with where the experience is actually moving.
Two things I’d carry from everything above:
Find your own frame, don’t just collect answers. The atomic design parallel wasn’t something AI handed me – it was something I arrived at because I kept asking until I understood enough to think for myself. The goal isn’t to absorb information. It’s to build enough context to form a point of view you can own, bring to the room, and stand behind.
Follow the experience wherever it lives. If the most important design decision on your product right now is sitting in a GitHub file, that’s where your thinking should be. Not to take over someone else’s work, but to make sure the experience has a designer in it. That’s the job – and it always was. The territory is just larger now.
Conversation is an interface. A system prompt is a design artifact. The skills we’ve always had as product designers – empathy, clarity, knowing what a person needs in a moment of friction – matter as much as they ever did. They just need to travel further than they used to.
That’s not a threat. That’s the most interesting version of this job I’ve encountered yet.
