Big Idea

The argument in one line.

A structured PRD-to-screen-prompt pipeline running before you open Claude Design is what separates generic AI mockups from wireframes that reflect your product's real user journeys and planned edge states.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You are building an app with Claude or AI tools and keep getting generic-looking UI mockups that do not match your product.
You have a PRD or feature spec and want to go straight to structured wireframes without hiring a designer.
You use Claude Design and feel like you are prompting blind without a repeatable system.
You are a solo builder trying to nail a UX philosophy before committing to a design direction across many screens.

SKIP IF…

You are looking for design system fundamentals such as colors, typography, or tokens; this is about prompt architecture, not visual design principles.
You do not have any product idea yet; the pipeline requires at least a rough concept and defined user journeys to work from.

TL;DR

The full version, fast.

Most people get mediocre Claude Design output because they prompt it without product context. This 4-step Claude Code skill fixes that: shape your PRD into a UX-focused doc by stripping engineering noise, generate three divergent UX philosophies and pick one, create per-feature state briefs covering empty, loading, populated, and error states, then export screen prompts formatted for Claude Design. The result is structured context-rich prompts that produce wireframes reflecting actual user journeys and planned edge cases rather than the training-data average.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 00:33

01 · Hook: finished UI preview

Opens with polished Claude Design output and frames the problem as a skill issue not a tool issue.

00:33 – 04:39

02 · Step 1: PRD shaping

PRD-to-UX skill strips engineering details and asks target platform, user journeys, anti-goals, and USP. Outputs a UX-focused PRD.

04:39 – 07:59

03 · Step 2: UX philosophy divergence

Three divergent philosophies generated: Conversation as Substrate (chosen), Journal with Assistant, Command Bar First. Evaluated against mobile goals and discoverability needs.

07:59 – 10:51

04 · Step 3: Feature and state briefs

Agent Chat feature scoped with user stories. All screen states briefed: empty, loading, populated, error.

10:51 – 11:39

05 · Step 3.5: Design direction (optional)

Optional vibe brief. SHADCN default chosen, which skips the custom brief and moves straight to screen prompt export.

11:39 – 13:33

06 · Step 4: Claude Design execution

Screen prompt pasted into Claude Design. Product questions answered: desktop web app, neutral black and white, 3 layout variations, weekly sparklines, subtle footnote citations, 3 follow-ups, 4 visible exchanges.

13:33 – 15:31

07 · Results: three layout variations reviewed

Notebook style, split canvas, dense log. Split canvas preferred. Tweaks panel shown for sidebar and density toggles.

15:31 – 17:26

08 · Color iteration and error states

Color applied to split canvas. Error states mocked: tool layer error with retry query, agent layer error with retry response, reconnecting pill. Closing: you need a system.

Atomic Insights

Lines worth screenshotting.

Asking Claude Design to build a dashboard without product context produces the statistical average of all dashboards, which is a prompting failure not a tool failure.
Stripping engineering details out of a PRD before feeding it to a UI tool is the critical step most builders skip.
Three divergent UX philosophies generated before any design work force you to make the core architectural decision explicitly, not implicitly.
Anti-goals in a PRD are not optional: language models will build whatever fits the description including everything you did not say you did not want.
Designing in black and white first removes the aesthetic decision from the structural decision so you can evaluate layout without color distraction.
Feature state briefs covering empty, loading, populated, and error states mean every edge case has a planned visual, not an afterthought discovered in QA.
Claude Design question-and-answer flow at generation time forces you to make decisions about variations; skipping it means those decisions get made arbitrarily by the model.
The conversation-as-substrate philosophy informs every subsequent screen, sidebar, chip, and navigation decision; it is an architecture choice not a style choice.
Iterating on color and polish only makes sense after the structural layout is locked.
A 4-step terminal skill that runs before any design tool scales: every new screen generated from the same product inherits the same context without re-explaining it.

Takeaway

The system you run before Claude Design is the design.

WHAT TO LEARN

Structured prompt pipelines, not better one-off prompts, are what separate AI-generated UIs that look like training-data averages from ones that reflect real product decisions.

A PRD stripped of engineering details and rewritten around user journeys gives Claude Design the right context: what the user sees and does, not how the backend works.
Stating anti-goals explicitly forces you to decide what the product is NOT, because without this step an AI tool fills the blank with whatever fits the description.
Generating three divergent UX philosophies before touching any design tool surfaces the core architectural decision before it gets baked into 20 screens.
Per-feature state briefs covering empty, loading, populated, and error states written before design work mean every edge case has a planned visual rather than an afterthought discovered in QA.
Starting wireframes in black and white lets you evaluate structure and layout without being distracted by color; add color only after the spatial decisions are locked.
The question-and-answer flow Claude Design presents at generation time is doing real design work: each answer is a decision that would otherwise be made arbitrarily by the model.
A terminal-based skill that runs before opening any UI tool scales: every new screen generated from the same product inherits the same context and philosophy without re-explaining it.

Glossary

Terms worth knowing.

PRD: Product Requirements Document. A written spec describing what a product should do and why. Here it refers to a feature-level document focused on user journeys rather than engineering implementation details.
Claude Design: An Anthropic tool that generates UI mockups and wireframes from natural-language prompts. It asks clarifying questions at generation time and produces multiple layout variations.
UX philosophy: The foundational interaction paradigm for a product, such as whether everything flows through a chat interface, a traditional log view, or a keyboard-driven command bar. Choosing one early constrains all subsequent screen designs.
State brief: A written description of a single screen feature in a specific data state: empty, loading, populated, or error. Writing these before designing ensures all states are deliberately planned.
Anti-goals: Explicit statements of what a product should NOT do or become. Used to prevent AI tools from adding features or design patterns that contradict the product intent.
Screen prompt: A structured natural-language description of a single screen or screen state, formatted for a design generation tool like Claude Design.
MCP server: Model Context Protocol server, a local service that exposes structured data to any LLM via a standardized interface, enabling the AI to query real data rather than operating in isolation.
Divergent brainstorming: Deliberately generating multiple philosophically distinct options before converging on one. Used in step 2 to produce three maximally different UX approaches before choosing a direction.

Resources

Things they pointed at.

00:33channelG Stack by Gary Tan

01:10channelCompound Engineering

10:20toolSHADCN ↗

10:30toolClaude Design ↗

Quotables

Lines you could clip.

00:00

“Might just be a skill issue.”

Confident cold open that reframes a common complaint, no setup needed.→ TikTok hook↗ Tweet quote

02:33

“Language models will go off and do a bunch of random stuff that you do not want them to do, and so we are trying to avoid that.”

Blunt, specific, relatable to anyone who has fought an AI tool.→ IG reel cold open↗ Tweet quote

04:28

“You did not give any context, no motivational context as to what you are building and why.”

States the core argument in one breath, works standalone.→ newsletter pull-quote↗ Tweet quote

16:49

“You need to use it with a system.”

Closing thesis, five words that summarize the whole video.→ TikTok hook↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

analogy

I've been building some pretty awesome stuff with Claw Design, so I don't know what all of the complaining has been about with people claiming that it's not good. Might just be a skill issue. And so in this video, I'm gonna show you the four step skill that I've created that takes a PRD describing features and turns it into something really awesome like this.

So if that's something you wanna see, let's get in and look at it. So the first stage of this process needs to start with the PRD. We have to, like, functionally understand what it is that we are going to build.

This specific process that I kicked off uses the PRD that I generated from Gary Tan's g stack, which I did a video about a few weeks back, and I will link it on this one if you want to see that.

But we have to start with a PRD. And so there's two approaches that I've built in this skill. So if you do not have a PRD yet for what you're trying to build, then you can use this first kind of pre step in order to actually create one for you.

Now, the way that I generated this is I went through some of my top libraries for like agent coding plugins. So things like G Stack, compound engineering, over superpowers.

I went through a bunch of these things and saw what they did best with the PRDs and combined them all into one system. But if you do have a PRD already and you wanted to work with this system, we have this sub step that will take whatever you have and turn it into the format that's needed to go to the next step.

And so all I'm gonna do here is pass in the path to my PRD that I have, and then I'm gonna tell it to run this skill which is called PRD to UX. And so the thing that makes this skill work is that it goes through, it strips out the technical details that we don't need to use with Claw Design, and focuses only on the actual features and what they are intended to do.

Like, what's the job they accomplish? So this is an example where we had an engineering heavy design doc, which is what you get with a lot of spec driven libraries. And we wanna turn that into something that really describes more like what the user's meant to see, how they're meant to interact with the thing.

And so this skill is gonna come through and it's gonna ask us a few questions. So first, in this case, we can say that desktop's gonna be the primary concern for me building this out, but I do want it to be mobile supported as well. So we are going to put a c for that one.

Then we're gonna iron out what are the primary user journeys so that we understand directionally, like, how is the user gonna actually get the value out of what we are building.

So now the next part is it tries to answer, like, non goals or anti goals. I got this paradigm. I believe it was from compound engineering.

I could be wrong about that, but I'll link to everything that I used to inspire this skill down below. But what this is meant to do is make sure that we are stating what we specifically don't want to build, because language models will go off and do a bunch of random shit that you don't want it to do, and so we are trying to avoid that.

So what comes after that is the framing of the USP. What actually makes this thing unique from like an actual user interaction perspective?

So in this specific case with this nutrition logging app that I've been building, there are a few things that I think make it pretty unique. The first is that the user actually owns their nutrition data, and it can be queryable by any LLM.

So we're gonna have an MCP server. People don't have to just have this situation where the data only exists inside of our tool, and we can't really access it. We can't use it inside of claw to ask questions.

Like, we can't do any of that stuff. And that's kind of annoying as someone that actually uses these types of tools regularly. So for me, one of the big bottlenecks with other, like, nutrition tracking tools is that actually, like, logging food and getting insight out of anything takes a lot of time, and it's actually very hard and cumbersome to do.

So between b and c, these are the things that are gonna be those like eureka moments for the user where they're like, yeah, I for sure want to use this. And so the output of this first step is going to be a PRD that is really narrowed down to, like, functionally, like, what is this thing supposed to do?

What are the primary user journeys? Like, what are they functionally supposed to do inside of your app? And this is critical because if we don't have this, like, what screens are we making?

If you're one of those people that went into cloud design and said build me a dashboard and then it came back and gave you something generic and you're like, oh, this this looks dumb. Claw design sucks. It's like, no.

You didn't give any context, no motivational context as to like what you are building and why you are building it. So that's what this is meant to do, so that we have a really clear idea of why we're gonna be building certain screens and how it all actually connects together. And then from there, we have a list of the different features with user stories.

So like what is this meant to actually accomplish? And the reason that we're keeping this kind of high level is that in the next stage, which we're about to get to, we are going to take this and we're going to brainstorm divergent UX philosophies.

Because for everything that we're talking about here, there are a lot of different ways that you could implement on something like this. So what we're gonna do next is we are going to move on to the step that brainstorms those three different UX philosophies and then helps you pick one.

And so the way this works and a few of these tools that I mentioned that, like, kind of inspired this have been using this paradigm where you have these, like, divergent adversarial brainstorming sessions where we get things that are very different from one another.

And then we filter through like, okay. But based on who we're building this for, like, which directions actually make sense?

And so what we get out the other side are those different philosophical directions that we could take with our user experience. So the first one, for example, and this is the one that I happen to like the most, is this conversation is like the primary thing.

And this is valuable because most people that are like AI power users like me, I'm building this for myself, ultimately, the like chat interface is now the default mental model that people are used to. And so everything in this app, whether it's the logging, the querying, looking up recipes, getting your daily insights, all of this needs to flow through conversations.

Now, I don't want it to be just like one persistent conversation. I think there should be threading in case people wanna go back and and do other stuff. But ultimately, everything is going to be a conversation.

Now, obviously, that's important if we're gonna decide that that's what we're going to do, because that's gonna inform every single thing that gets built, which we're gonna look at when we go to build this inside of Claude design. The second option was, hey, well, this is primarily a journal that happens to have an assistant.

Now the reason that I don't really like this one is that this is like exactly what we didn't want to do, which this surfaces. We specifically did not want it to be, hey, it's a food log that happens to have a chat feature bolted on. I really want it to have this perspective where like anything this agent can do is something that the human would have done previously.

And so the third option was this command bar first. So this would be like something like superhuman where it's really driven by like keyboard shortcuts, like power user type of workflows.

I don't know that I like that one too much because ultimately, I am going to move this onto like a a mobile app or at very least, like a mobile responsive, like web interface. And so having the entire user experience built around this like kind of slash command style thing that's activated by the keyboard.

I don't think I would like something like that. And it also kind of hides the discover ability of features. So another important thing about what I wanted to build here was that everything needed to be quick.

Quick to find things, quick to log things, quick to get insights. And this in some ways obfuscates that because it's it's actually hard for users that are new to the app to move through and, like, find the things that exist. So we have different options here.

We can tell it to keep looking at different options. If you didn't like any of these, you could give it more direction. You could tell it to go out and research things that might be relevant to this.

You can say you want a hybrid. Whatever it is that you liked out of these, you can move through and say, hey, this is what I wanna move forward with. And so it's gonna document this to a persistent file, and then we will be able to move on to the next step, which is step three.

And so this next step of process is arguably the most important, and that's where we are going to create feature and state briefs. So what it's gonna do is it's gonna take this philosophy that we have defined, which in this case is that, you know, the conversation is everything. And then we're going to think of that through the lens of every single feature and the different states that the feature could exist in.

So loading data, error data, full of data, you know, empty state, all of those types of things are gonna have their own brief, so that we can move into a tool like Claw Design and actually see what those things look like. So we have two different options then. Number one, we can generate all of the features in one pass or say, hey, I just wanna look at one of these features specifically.

And so in this case, we're gonna say, hey, I just want to look at the agent chat. So what we get once this is finished processing is a list of user stories related to this feature because these are all use cases that we need to make sure we generate like, UI elements for.

We know where it's gonna fit into the overall thing that we're building. And then we have a few different versions of each of those screens. So for example, if it's an active conversation that's ongoing, what's the purpose of this feature?

What happens when it's a fresh conversation with no new messages yet? What happens if the agent is thinking about a response for the user? What are we gonna show to them so that they know it's actually working?

What is it gonna look like when a bit of a conversation has already happened? All of things and the edge cases get decided ahead of time so that we can plan for them and we can actually build those things out.

So the next step which is kind of step three and a half is optional. And that's if you have an idea of what you want the like vibe of the actual UI to be like the design direction, you can provide it here.

So this could be a plain text description of how it should feel and maybe colors that you wanna have or references. Or you can just say, hey, I wanna default to like a black and white, which is actually a really good practice for designing stuff, so that you can make sure it all actually fits together cohesively instead of focusing on the button colors when in reality none of it actually makes sense.

So in this case, I'm gonna just say we wanna SHADCN style default. And then what it's gonna do is it's gonna move through and it's gonna execute the final step, which is taking all of those screens exporting them into a format that's going to work well with a tool like Claude Design.

So now that this thing is done processing, we can see we have this new directory in here called screen prompts. And if we were to click into, this case, we only have one, we now have a pretty detailed description of what each of these screens should look like.

So for example, if we went down and said, hey, this is the populated screen and we wanna see like, what does it look like when a conversation is actually taking place? So we can hop over into Claw Design and in this case, I don't really wanna use a design system.

I want it to again, design in black and white. So we're just gonna pick that we want the wireframe look and then we're gonna go through and we're gonna hit create. And now all I'm gonna do is come through here and I'm going to paste in that screen prompt that we copied.

And so now we've come in here and we've pasted that prompt that we copied, and we are going to go through and we're gonna answer the questions that they have about our product. So this is really cool because it gives us a chance to kind of decide, like, what do we actually wanna see variations of in this design?

And so this is what we are gonna move through and answer. So what is the product? For purposes of this video, I'm gonna just look at a desktop web app.

Any existing design system or brand will say no. For the aesthetic direction, I'm gonna say that I want this to be neutral black and white because I don't want it to go out there and and try to add in, like, colors and things that are gonna be distracting. I just wanna look at the UX of what we are building.

How many overall layout variations? We'll say three. So this is cool.

Like, what do we actually wanna mock up? Because in the prompt, we had like, hey, there can be these inline snippets that are rendering like in the chat.

So which ones do we wanna actually look at? So we could say we wanna look at like weekly trend lines, maybe a list of entries.

I won't go crazy with that one, but we can get a look at what some of these look like. For how we choose to do like citations inside of chats, I'll just say like very subtle footnote. How many different follow ups do we wanna look at like a mock up of?

So we could say, okay, like three follow ups I think is fine. How many exchanges are visible between the user and the agent? We'll say four.

I think that's fine. We wanna actually like see what this looks like with the sidebar open. So we could say like, I don't know, decide for me.

One of the things I like about this tool is they give you different angles that you can toggle. So for example, maybe I wanna see what it looks like with and without the sidebar open, and maybe I wanna see a denser version of it versus a more breathable one.

Then we can actually mock up like a very basic interaction to see like, what would this really look like? And so I could say like, I wanna see what it looks like when a message is sent and when a follow-up kind of chip is selected.

And then it's even asking like, what do we want the sample conversation topic to be? And so we could say like correlating sleep trends from the WHOOP fitness tracker with dietary changes.

Alright. Maybe that's what the user is kind of asking the agent about. And now this thing is gonna go out and build it.

Okay. So now that this thing is done, we can see we have three very different types of interfaces that we are looking at. So though this first one is more of like a notebook style.

And so we can see this obviously took very seriously the idea that, like, the entire application is basically a conversational thread. So we can see what the mock ups of the graphs might look like.

We can see what the mock ups of a user having sent a message looks like. We can see the responses with certain types of formatting for things like like actual logs. And then we could even see what it looks like if we came through and asked another question, and then we had it respond to us.

And now we can see, hey. We have these little chips down here where if we wanted to see, like, okay. Well, is this being influenced by, you know, alcohol, for example?

And then the conversation would continue on and on. So this is, like, the first approach that we have. We also have this, like, split canvas style idea.

And so if we wanted to come through and see like, well, what does it look like with the sidebar open? We can come down here to these tweaks and hit open. And so we can see what it looks like with that sidebar open.

We can see what it looks like with more compact formatting or more comfortable formatting. So for me, like this standard chat interface, think would be like the best for me. It would have the most utility.

And then we can come down to this other like more dense log where, again, this is looking more like a computer log of sorts, and I'm not like super thrilled with this one. But again, we can go back to that skill and if we wanted to make completely different directions that we wanted to take this thing, we could go through and keep pushing back on it and asking it to iterate.

But now if we wanted to come through and actually see like, well, what does this look like with a little bit of color to it? We could say something like, for the split canvas, so option b in the middle, we wanna update this now to actually have like a little bit of color to it. So can we have it go through and start putting a bit of like a aesthetic on top of this thing.

And so now that we have processed that, we can see it automatically has like a much different feel to it. And realistically, all we asked it to do was to add some UI elements to it.

But if we hadn't taken the time to go through and actually decide, like, what shape this thing should have, it wouldn't really matter that we then came through and added nice button colors and rounding. So the next step from here is that this process continues. So if we were to pop down back into Versus Code, for example, and maybe we wanna see like, well, what does it look like when there is an error on this screen?

We could move through, we could copy that, and we can say based on the split canvas, mock up this screen state. Alright.

And now that that is done, it looks like it mocked up those different states that we had again based on the spec that we got from those skills. So we have a tool layer error, an agent layer error, and a general reconnecting pill. So we can go through now and we can actually look at those.

So for example, if like a query fails, we can see like what this state looks like to be able to retry that query. And similarly, if it's trying to make like a response to us with a message and for some reason it wasn't working, we can retry the response.

So instead of having like some super ugly thing that we didn't think about that's meant to be our error handling, we now have like a nice kind of more intelligent way to do it. We can also see down here, it's a little bit hard to see, but we have like what that reconnecting badge would look like.

So I think as far as like the actual usage of the app goes, again, this is a research preview and I think for what it is, it's very impressive, but you need to use it with a system. Like you can't just go into a tool like this and prompt it to build me the next Facebook and expect that it's gonna pop out some UI that isn't just, you know, the average of the training data.

And so having a skill like the one we went through is really helpful in getting us to that point. But that is it for this video. I will see you in the next

The Hook

The bait, then the rug-pull.

Most complaints about Claude Design are actually complaints about bad prompting. Sean Kochel opens by showing a finished nutrition-tracker UI with threaded conversations, inline data visualizations, and planned error states, then rewinds to the terminal-based 4-step skill that produced the prompts behind it.

Frameworks