The Design Process Was Built for a World That No Longer Exists.

I've been thinking about this for a while. When I watched the video claiming the design process is dead, my first reaction wasn't disagreement. It was recognition.

Not because I think the process is worthless. But because the version of it most teams are still following was built for a world that no longer exists.

The line that stuck with me

"If you don't know what you're building, how do you know what the steps are?"

That's the real problem. We've been treating methodology like a guarantee. Follow the steps, get the outcome. But I've followed the "right" process and still gotten completely different outcomes. And a lot of the time, you don't even have the space to follow it properly, not because anyone is doing something wrong, but because things just move too fast now.

AI didn't break the process. It exposed how rigid it already was.

The thing nobody on design Twitter wants to say

I'll just say it: I don't think we should be designing screens in Figma anymore.

The gap between a design file and what actually gets built is still too wide. Figma doesn't close it. It adds another translation layer that slows everything down. If the goal is to build real products faster and better, design has to happen closer to the final output. For me, that means working directly in code.

This isn't a take for the sake of having one. It's where I've landed after watching too many handoffs lose fidelity, too many design systems drift from what's actually in production, and too many hours spent recreating things that already existed somewhere in the codebase.

What actually changed when I started using AI

In the products where I can use AI, my day looks completely different. I'm faster, more focused, and spending more time on the decisions that actually matter. In the ones that haven't made that transition yet, I feel like I'm going back to a slower version of myself.

I've built my own Claude skills to handle repetitive execution. Not to replace my thinking, but to protect it.

A quick note for context: a Claude skill is essentially a reusable set of instructions you give Claude so it can perform a specific task consistently, without you having to explain it from scratch every time. Think of it as a trained workflow you can trigger on demand.

One I use constantly is a Nielsen heuristics audit skill. I point it at whatever I'm building and in about five minutes I get a structured quality check against usability principles that used to take me much longer to run manually. It's not that it wasn't possible before. It's that now it actually fits inside the pace of real work.

But the biggest shift has been designing directly in code. With Starsine, we saw more design progress in a single day than we had in weeks of wireframes, iteration rounds, and feedback cycles. That sounds like an exaggeration. It isn't.

The reason is simple. When you design in code, you're working with what users actually see, feel, and experience. Figma prototypes with breakpoints are useful, but they're still a representation of the product. Code is the product. As a designer, being able to adjust things with your own aesthetic eye directly in the real environment changes the quality and speed of decisions completely.

Because that's what people get wrong about AI and design work. AI changes how you execute. It doesn't change why you make decisions or how you develop judgment. If anything, faster execution makes your thinking more visible. When anyone can ship quickly, what separates good products from forgettable ones is what's behind them.

Where things are actually stalling

It's not figuring out what to build. If anything, teams feel more empowered than ever to try things and ship. The barrier to execution is lower, and that's genuinely exciting.

The real bottleneck is the learning curve. There's a gap between what AI can do and what most people know how to do with it. That's where projects stall, where outputs stay shallow, and where the promise of moving faster doesn't show up in the work.

I think it's temporary. But it's the problem in front of us right now, and pretending otherwise doesn't help anyone.

So what do you actually do about it? Here's what's worked for me and what I'd tell any designer trying to close that gap today.

Accept that discomfort is the skill right now.

Not as a motivational poster, but as a literal competitive advantage. The people who can tolerate not knowing what they're doing for the next six months are the ones who will figure it out. Comfort with ambiguity isn't soft advice. It's the actual job requirement.

Start with your own workflow, not the product.

Don't try to build features with AI on day one. Start by using it to understand the codebase you already work with. Ask it to explain a component. Ask it to map out how a page renders. Build literacy before you build features. The product will come once you know how to move inside the stack.

Pair with engineers, not tutorials.

There's no guide for "design with AI in Rails" or whatever your specific stack is. But your engineering team already knows it. The learning curve shrinks fast when a designer sits with an engineer and uses AI together as the interface between them. That's exactly what happened with Alicia, software engineer, and me, lead designer. She helped me think outside the designer mindset and together we built the system to extract design tokens directly from the codebase. No tutorial would have gotten us there.

Expect the methodology to come from practitioners, not educators.

The frameworks for this don't exist yet in any formal sense. They're being written right now by people doing the work. Which means the best thing you can do is be one of those people, document what you learn, and share it. That's where the real playbook will come from.

What I built, and what broke first

A few months ago I created something I've been calling the design-system skill. The idea was to give designers and PMs a way to prototype directly from code, by extracting the design system from the codebase and making it the actual source of truth. That way, generating new features and pages is faster because everything is already grounded in what exists in the product.

My first attempt failed.

I tried to approach it from a traditional design mindset, connecting our Figma design system through MCP. It technically worked, but the cost in tokens, time, and effort didn't justify the outcome. That's when I realized I was thinking like a designer when I needed to think like a product builder.

What actually worked was getting out of my own perspective. My teammate Alicia helped me reframe the whole thing, and together we landed on a solution we're now applying across the company. The collaboration mattered as much as the idea.

What I think designers need to do right now

The process isn't dead. But the rigid, non-adaptive version of it was already on its way out before AI arrived. Startups and smaller teams were already adjusting it based on budget, timeline, and context. Nobody was actually following it strictly, even when they said they were.

What's changing now is that we're moving away from fixed steps and toward more flexible systems. Skills, reusable components of a process, things that can adapt to the context instead of forcing the context to adapt to them.

The designers who treat AI as a tool will keep up for a while. The ones who treat it as a medium, who learn to build with it and orchestrate what it produces, are the ones who will close the gap between design and engineering that has slowed product teams down for years.

At Telos, this is what we do every day. If you want to see how we work or talk through where your team is stuck, let’s talk.