The new design process

I think I figured out my new design process...

Step 1: Brain dump

This is the step where I dictate into the void. This could be either a conversation with a co-worker, a conversation with myself, or just holding down the dictation keys while I randomly muse and think about the problem I'm trying to solve based off of all the information that I have on hand. My personal favorite dictation tool is @WillowVoiceAI -- I'm using it right now to jot this down.

If it's a conversation with another person, basically I take the transcript from those calls and I just dump them into Claude. Unstructured, unorganized, uncategorized, uncontextualized. I just feed it literally everything about the project.

Sometimes I don't even tell it why I'm pasting what I'm pasting. I just say, "Here's a transcript, figure it out." @NotionHQ recordings are the current tool for this, but honestly if there was a tool specifically for this I'd be interested. @meetgranola is great, too, But for me, it's just easier to use Notion because that's where all of our documentation lives anyway.

Lowest friction wins.

Step 2: Scope and plan

this is where Claude Code is super valuable. I go back and forth, give it more context. It asks interesting questions. I gain better understanding the problem I'm trying to solve by describing it.

I dig and dig and dig with the AI as my research assistant and also kick off subtasks for it to go out and do web searches, create CSVs, tables, start writing markdown files that might be related. Pull in related documentation from other places that I might have access to.

Basically, this is where we're I'm trying to find needles in the haystack. Or rather, where i'm trying to find haystacks that might contain needles.

Step 3: The Bad Build

This is the crucial step that I at first hated, but now see as valuable.

AI is terrible at design.

I don't mean UI, I mean application structure, affordances, microcopy, layout, integration with current products, all the kind of design stuff that makes something feel really easy to use.

Terrible.

But I don't care.

I've realized that there's a huge benefit for tools like Claude code designing something poorly--it gives me a better starting point.

Rather than having to start from a blank canvas or from an existing product feature that maybe wasn't quite what I'm looking for, I start from a terrible design implemented poorly, but functionally sound.

Then things get interesting.

Step 4: Creative director

I take that terribly designed product and I start critiquing it, looking at it through the a super critical eye and shoot holes. No constructive feedback, just "woah this is terrible, fix X, Y, X"

I find all the edges. I find all the edge cases. I find all the screens that I'm missing. I find all of the error states, hover affordances, what information shouldn't be presented versus what is presented, and just start cutting everything down to its absolute bare minimum.

AI design is a maximalist. It'll throw colors and chips and icons and headings and categorizations and cards everywhere, like it's vomiting all over the page. It creates something that, to the untrained eye, looks like a product.

But it's a terrible design.

That's used to be a death sentence for a product. Unsalvageable. The cost to switch everything back from poorly made decisions used to be too high.

used to be .

Not anymore.

Now the cost to switch an application away from poorly made decisions is effectively zero. I can start from scratch 10 times in a day. I can butcher the crap app down to what it needs to be, and then build it back up in hours.

That poorly made scaffold, that garbage application, is just the ashes of something new. My job is to find that emergence.

I can put on my creative director hat, start redlining, annotating, understanding what information is presented versus what should be presented, and it gives me the clarity of realizing how the product might actually feel if it was designed properly.

Step 5: Refine

This is where I use tools like @conductor_build. I'll refine the application and the structure and the UI as much as possible without touching @Figma or any other traditional design tools.

I'll get to the point where it's presenting the appropriate information at the right time, where it has the information architecture sorted in a semblance of the correct way, where it feels performant, or where it has all the functionality that I might expect for an application. But then when I hit the point where it feels real, like this functionally could be a good product... it's still not well designed. It needs work.

It's still not crafted.

It's not designed.

Text and voice as a design medium are too clumsy. There's no precision to get in the weeds, to polish, to create iconography, to have uniform componentry, to understand how everything connects together, how elements can be reused, and how it fits into a larger application.

You run into constant issues with AI at this stage. If you introduce new functionality, it'll add new components, it'll create new button styles, it'll not remember elements that have already been built before and start bloating the prototype.

It's tantalizing to continue in this phase on and on and on again, but the ceiling will never be high enough. Continuing forever in this phase is folly.

This is a great step for getting stakeholder feedback, understanding how people might interact with the application, getting other eyes on it, seeing how it might fit, and start to get the conversation moving from a team perspective.

Once other people can see where you're working or how you're dealing with it, it's time to move on and leave the ashes completely behind.

Step 6: Gut it and save context

Steps 1-5 create an interesting application, but one that is full of unused code, poorly articulated decisions, and context that doesn't exactly understand where things should go versus what they are.

In this phase I tell Claude to write a new folder full of markdown files with context, history, and constraints that would be helpful for the next time I develop the application.

No code, just markdown.

Effectively, I'm starting from zero, but I'm using the transcripts and existing code to inform a better build of the app.

At the same time, I also take screenshots of every single state that I can think of: all the different permutations, all the different edge cases, and all the stuff that I want to actually refine and design at a higher level.

Step 7: Figma and craft

This is where I used to start just like three months ago. Crazy.

I take all the screenshots and all of my context, I generate user diagrams, and then I go into Figma. I start actually building out the application in a way that is good design: auto layout, all the old stuff that I used to do, colors, reusing design systems, typography, tokens, all of that.

I'm not going to lie, after all of the progress up until this point, this feels slow. But it is very important for a high polish output.

There's a significant tool gap here where I could take all of the different codified elements from the application and generate the Figma screens that would match this. But I'm not sure that I trust any of the translation layer, because there's also a lot of exploration that happens here once I'm in Figma.

In this stage I can go broad. Explore different affordances, microcopy states, orientations, all the stuff that was in the application. High friction in AI world is now low friction in Figma and vice versa.

I found that at this phase, I still have the most flow state. I still am exploring the most options. I still come up with novel solutions that I didn't think of before, because my medium now is visual design, not necessarily articulating my thoughts or understanding app componentry.

While I'm working on that, I'm also sharing screenshots, creating Figma prototypes, sharing it with the team, and understanding exactly if I'm working in the right direction.

I will say, previous to the step, all the UI design is terrible. And I keep labeling it as such when I share it with the team.

"Don't look at the UI, just look at the functionality."

I also am able to evaluate my prior unexplored ideas in a much more freeform way, and I'm able to come up with a final output that is not nearly as comprehensive as what it used to be inside of Figma... I don't think I actually need nearly as many screens as I used to, because a lot of the ideation has happened already.

But the final output of this is much higher polish than anything that an AI is able to generate.

Step 8: Build it again

Now I take all those design files and all those context documents, and I start a new conversation within @conductor_build. Still planning phase.

This is where I really want to scope out the project and understand exactly what questions it has given my new mockups. Understand if there's anything that my mockups address that conflict with the previous context that I've identified. This is likely to happen, but I needed to go through and understand it.

This is also my least favorite phase of the entire flow.

The Figma MCP is super underpowered. Screenshots are not sufficient for this. But it's all I have... for now.

Ideally, what I'd be able to pass through is a screenshot of the application, the names of all the components, all of their screenshots, a complete structure of the components that I'm passing through, all of the text, all of the color tokens, and everything, including the screenshots, but not limited to them.

I'd also love if I could pass through a JSON representation of the prototype that I've created, showing all the different states that are in there.

Figma prototypes are so easy to build for user flows, but they're really hard to build for complex user interactions, list-based elements, or anything data-driven or dynamic. I still want to be able to use them, but it feels like an effective way for me to actually hand off the data that's in there to the AI to build.

This is where I think that the current developer handoff features of Figma could actually be really valuable. I think I'd want to annotate and describe and have a conversation back and forth with the AI about the implementation plan for the features that I have. It'd be interesting if he could even ask questions about my design file, try to unite it with context it already has built, and maybe be able to suggest some gaps in my design that may not work.

Basically how I usually go to a real developer.

Once everything is built, and once I have a good competent, reasonable, effectively built prototype, it's onto step 9.

Step 9: Handoff

I don't think there's any replacement for a qualified exceptional developer. I don't think that AI is going to solve this problem yet. This step is still unbelievably crucial.

Performance, implementation, APIs, understanding the code structure, understanding other developments that are in process, understanding other features that are in progress, how to integrate them, how to use the most effective components, all of those things require a context that requires a developer.

While I can't actually push code to the @Vercel production builds, I don't think I should be for anything more than small tweaks and UI changes. That's where I have found the flow here feels very similar to how it felt in the past. I give something to a developer, and they build it in the production system.

This part of the flow feels very similar to what it used to be like. I give something to a developer and they go and build it in the production application.

If you're working on a website or you're working on something for yourself, then this step is non-existent. Designers should absolutely be able to ship front-end code if it's just a marketing website or something that isn't dealing with millions of users or millions of $ of implications. Maybe that will change, but I still like having the confidence of handing off to someone who has a rigorous background, and understanding of what will happen if something goes wrong and how to resolve it.

Final thoughts

I think the only difference is the planning and what I'm handing off to developers. Instead of a static flow and static mocks, they get the same static mocks, but plus a stateful, integrated, performant, and remarkably real feeling prototype. It works on anybody's computer. We can test it on any number of devices, and we can still go back to the AI that was used in the prototype and riff on the designs, without needing to go full into production code and complexity.

I'm not sure how long this workflow will continue. The tools may change, the process may change, the amount of complexity may change. But when I look at it detailed out, it's still design.

It's still a process of exploring different solutions.

Of making things up and finding flow.

The difference is what tools, and the order they are used.