The End of the Design Process

Maybe the best Claude Skill is the skill we developed along the way.

It seems there’s a lot of opinions out there about when to use which design tools and how to use them — use Figma for this, Claude for that, with this skill and these prompts — and when I started to write this article I fully intended to continue that discourse. Recently I’ve made an intentional effort to broaden my ability to design with LLM-only; no Figma or Paper, no visual references, just prompting Claude in VSCode and a web browser. I was going to write about how I only want to design in the browser now, and how an html page is the new Figma canvas, how designing purely in prompts got me designing interaction-first instead of layout-first, how I’m not sold on Claude skills being useful, and how yes, designers do need to code a little.

While I still think these things are worth talking about, there’s something that came out of that exercise of designing LLM-only that I didn’t expect:

Despite my goal of identifying and codifying a repeatable framework, what I actually noticed was my process, in the way that I worked, didn’t really matter.

Typically, we utilize process to support design work quality at scale, and price we pay for that is often flexibility as our work progresses. However, while I was working, the LLM could pull off pretty much whatever I needed to get done, at whatever stage of the project I was at. The magic of using an LLM to design is that it met me where I was, not the other way around. Want to convert your existing UI into components? Easy. Want to add new context and refresh the design? That totally works. It’s never really too early or too late to do anything because LLMs excel at disassembling and reassembling large quantities of data.

At the same time it seems that we’re all trying to leverage this period of discovery to be thought leaders and to productize our processes. We want to sell the right cocktail of our proprietary Claude skills and prompt structures with the promise that we figured out how to enable high craft work to be generated. However, in doing so we end up taking a shapeless, highly adaptable tool and stuffing it into an opinionated framework, which never fully delivers or consistently holds up.

Now of course designing by LLM prompt-only does work better if you take advantage of the full suite of tools available to you. I quickly realized that while you can get very far with just a single agent, eventually you’ll want help. So instead of a framework or a special markdown files, here’s my own findings:

• Prompt small. LLMs understand and implement small pieces much better than they do large PRD-style prompts. Plus it’s easier for you to understand as well.

• Reference code when you can. LLMs understand code better than they do images; visual references are hit or miss, but code references reliably work.

• Use Claude Skills, or don’t. There are some valuable skills out there, but almost all skills can just be prompts. The skills I have found useful are mostly used to manage context rather than execute something.

• Take advantage of disposable tuners. Prompting things like “Give me a disposable tuner to let me adjust this animation” helps turn your browser into a canvas. And the LLM will know it’s temporary and clear it from your UI when you approve the changes. Similarly, if you need a little tool to create a complex element, just generate it.

• Use multiple agents. Just like keeping prompts small, give lots of agents specific, targeted responsibilities.

• Embrace hooks and loops. Having an agent check for new components to add to your design system or catch drift, or looping an agent until a desired property is reached take you out of the “this still isn’t what I wanted” cycle and keeps agents running without the need for direction.
  
  That’s it. I’m sure this will evolve as the technology evolves, but this is what I’ve found to be helpful. No rigid process, no framework, no skills — none of these items are required to create high-end work, but they’ve helped me.

So if process doesn’t matter, what does? From my experience and observation there’s two things: the vocabulary and language you use and the conditions and environment that you’re designing in. The first is pretty self explanatory. The depth and texture of a high-craft product come from niche details, and those are created from those who know how to describe them in specificity and richness.

The second aspect is what I find most interesting: the conditions and environment we design in. This can mean your context structure, hooks, prompt organization, approval loops, etc. As I mentioned earlier, it’s never too early or too late to add or reorganize your environment and that’s precisely what makes designing with an LLM-first unique; you’re not just iterating on your design, you can iterate on your design environment as well.

Now this is where I’m going to contradict myself a bit. Despite the title of this article, the design process isn’t completely toast, but the end of a one-size-fits-all, tool (Figma) specific design process is. In fact, designing LLM-first actually provides designers the freedom and agency to create processes that are unique to them and/or unique to a problem space. They enable us to harness our specific points of view, spikes in our skill sets and our domain knowledge to create systems to support our work as it’s worked through.

Now the point of this article isn’t to convince you that we all need to leave our Figma-centric process behind or that designing LLM-first/in the browser is better. It’s that the most profound shift in design right now isn’t about what tools designers are using, it’s that designers now have much more agency in how we design; to truly design and own our individual processes, to use a combination of tools as we see fit and to design the optimal conditions for our approach and problem space.

The problems we solve are unique and differentiated; the way we design solutions should be as well.