What You Will Learn

• Define and validate a user problem using AI-driven research.
• Create a design.md to set visual direction, palette, typography, and spacing.
• Prototype and iterate key screens and empty states with AI design tools.
• Generate a single spec.html combining PRD, component library, and data schema.
• Build a full-stack app with AI, iterate on feedback, and keep spec/design in sync.

Study Guide

Introduction: The New Way to Build

Let's be honest about how software has been built for the last twenty years. It's been a relay race. The product manager writes a document, throws it over the wall to a designer, who spends weeks in Figma creating mockups, and then throws those over the wall to an engineer, who spends months turning them into code. Each handoff loses a little bit of the original vision. It's slow, it's expensive, and it requires a team of specialists just to get a simple idea off the ground.

That entire model is now broken. Not because the people are bad, but because the tools have changed. We are entering the era of the AI-native developer, a person who can take an idea from a vague thought to a deployed, functional application in a single afternoon. This isn't about writing every line of code by hand anymore. It's about directing intelligence,both human and artificial,to achieve a specific outcome.

This course is your complete playbook for that new reality. We're going to walk through a specific, six-step framework that takes you from a raw user problem to a finished web app. We'll use a real-world project called "Tastemaker" as our case study. It's an app designed to let users curate and share their favorite movies, TV shows, and video games on a single, beautiful profile page. This isn't a theoretical exercise. We're going to cover the exact prompts, the specific files you need to create, and the mental models required to make this work.

You'll learn how to define a problem worth solving, create a visual identity document that prevents your app from looking like generic AI slop, and use AI design tools to iterate on mockups faster than you ever thought possible. Then, we'll bridge the gap to code, building a full-stack application with a database and authentication, all guided by a single, consolidated specification.

The most important lesson here is a counter-intuitive one: the build phase is now the easiest part. The real work,the work that separates a beautiful, functional product from a digital mess,is in the planning. We're going to spend at least half of our effort on design and specification. If that sounds backwards to you, good. That means you're ready to learn.

Step 1: Defining the User Problem

Every great product starts with a problem, not a feature set. And the best problems to solve are your own. You are the expert on your own pain. You know the frustrations, the workarounds, and the moments where you think, "There has to be a better way to do this." This is your unfair advantage. You don't need to do extensive market research to validate your own lived experience.

Think about the creator of Tastemaker. They had a personal problem. Over decades, they had consumed thousands of films, television series, and video games. They tracked everything on IMDb, but the interface was utilitarian. It was a list. It was functional but soulless. There was no way to showcase a curated taste profile in a visually compelling way. The problem wasn't tracking; it was presentation. They wanted a single, elegant page that showcased their media preferences across all three categories,movies, TV, and games,in one unified place.

Now, you might think this is a niche problem. But here's where AI becomes your first research tool. You can take this personal problem and ask an AI chatbot to research it for you. You can prompt it to find out if a single platform exists that allows you to consolidate your movie, TV, and game preferences on one profile page. In this case, the AI would likely come back and say, "No, there isn't a single platform that does this well." That's your validation. That's your evidence that a gap exists.

The depth of your research should scale with your ambition. If this is a personal project for you and your friends, a quick AI search and a clear problem statement are enough. You don't need a 40-page business plan. But if you're thinking about turning this into a commercial product, you need to go deeper. You need to use AI to investigate monetization strategies. How would you charge for this? A subscription? A one-time fee? You need to think about user acquisition. How would people find your app? Who is your target audience? For a personal project, you can move fast. For a commercial venture, you need to slow down and do your due diligence.

Key takeaways for problem definition:
- Solve your own problems first. You're the most informed stakeholder you'll ever have.
- Use AI to research and validate the problem. It can scan the landscape faster than you can.
- Be specific. "I want to show my taste" is not a problem. "I want a single, beautiful page that shows my top movies, shows, and games" is a problem.
- Scale your research to your ambition. Personal projects need light validation. Commercial products need heavy research.

Step 2: Creating a Design Language Document

Here's a dirty secret about AI: when you ask it to design something without any guidance, it defaults to a generic aesthetic. You know the look. It's the purple gradient, the generic sans-serif font, the stock photo of a diverse team of professionals staring at a laptop. It's the "AI slop" look. It's technically competent, but it has zero soul and zero differentiation. If you want your app to stand out, you have to give the AI a distinct visual direction.

This is where the design.md file comes in. This is a markdown document that acts as your visual constitution. It codifies the design principles, color palette, typography, and spacing conventions for your entire application. It's the single source of truth for what your app looks like. Without this file, you're asking AI to build a house without a blueprint, and you'll end up with a structure where every room is a different color and the doors are all in the wrong places.

So, where do you get this visual direction? You don't invent it from thin air. You steal,or more accurately, you borrow,from what already works. There are fantastic resources for this. Mobbin is a massive database of UI screenshots from real, successful products. You can search by app, by screen type, or by interaction. It's a goldmine of design patterns. Dribbble is another one. It's a platform where designers showcase their best work, and it's a great source of inspiration for current visual trends.

In the Tastemaker case, the creator was inspired by an app called Monogram. They loved its clean, visually quiet interface. The key principle they extracted was: *"Keep the interface quiet and let the cover art carry the color."* That single sentence became the foundation of their entire design language. Then, they took screenshots of Monogram and fed them to the AI, along with that design principle. The AI then synthesized a design.md file that captured that aesthetic.

What does a good design.md contain? It should have more than just a color palette. It needs to articulate the *why* behind the visual choices. It should define the personality of the interface. Is it playful or serious? Is it dense or airy? It should specify typography choices,not just the font names, but the hierarchy and the mood they create. It should define the spacing scale. It should have guidance on how components should look and feel. Here's a simple example of the kind of content you'd include:

Design Principle: The interface should be a quiet frame for the user's content. It should be minimal, elegant, and never compete with the media it displays.
Color: Use a neutral background (e.g., #FAFAFA) with dark text (#111111). Accent colors should be used sparingly and only for interactive elements. The primary "color" in the interface should come from user-uploaded cover art.
Typography: Use a clean, geometric sans-serif font for headlines (e.g., Inter) and a highly legible serif or sans-serif for body text. Headlines should be bold and large, while body text should be small and unobtrusive.
Spacing: Generous padding is key. Sections should breathe. Use a base spacing unit (e.g., 8px) and scale it up (16px, 24px, 32px) to create rhythm and hierarchy.

There are also resources that can give you a head start. The website z.sh has a collection of pre-made design.md files for popular websites like Nike, SpaceX, Apple, Vercel, and Notion. You can use these as a starting point. If you're building a high-tech developer tool, maybe you start with Vercel's design language. If you're building a consumer product with a premium feel, maybe you start with Apple's. This is a fantastic way to bootstrap your design process.

Now, a crucial ethical note. There's a huge difference between being inspired by a design and copying it. If you're building a social media app, you should not copy Twitter's design system. But if you're building a plant-care app, and you're inspired by the clean, calm aesthetic of a meditation app, that's fair game. The rule of thumb is this: borrow the *principles* and the *aesthetic* from a different category. Don't copy the layout and specific UI patterns of a direct competitor. You want to evoke a feeling, not replicate a product.

Key takeaways for design.md:
- Default AI design is generic. You must provide visual direction to get a unique product.
- Use resources like Mobbin and Dribbble to find inspiration.
- The design.md file should encode principles, colors, typography, and spacing.
- Sites like z.sh offer pre-made design files to get you started.
- Be inspired by other categories, but don't copy direct competitors.

Step 3: Prototyping Key Screens with AI Design Tools

Now that you have your design language, it's time to see it in action. This is where you move from abstract principles to concrete visuals. We're going to use AI design tools to rapidly prototype the most important screens of your application. Tools like Claude Design, Paper, and pen.dev are changing the game. These aren't like Figma. They're not just a canvas where you manually drag and drop. These tools generate mockups from text prompts and reference files.

The process is deceptively simple. First, you export your design.md file. Then, you attach it to the design tool. Next, you write a prompt specifying what you want to see. For Tastemaker, the initial prompt was something like: "Generate a mockup for the public taste profile page and a logged-out landing page for an app called Tastemaker, based on the attached design principles." You should also specify the platform. Are you building for web-first or mobile? This is a critical decision that will shape the layout.

Here's where the magic happens. Before generating the mockups, the AI design tool will likely ask you a series of clarifying questions. This is a feature, not a bug. It's the AI trying to understand your requirements better. It might ask things like:
- Whose profile should the example show? (e.g., "A user named Alex")
- What should the layout variations explore? (e.g., "A row-heavy layout vs. a grid editorial layout")
- What sections should be on the profile page? (e.g., "Favorites, Recent Reviews, Lists")
- Should we see a light mode, a dark mode, or both?
- How realistic should the copy and data be?

You should answer these questions thoughtfully. This is a low-cost way to flesh out your requirements and prevent expensive mistakes later on. For Tastemaker, the user decided to show a profile for a fictional user named "Alex," and asked for variations that explored a row-heavy layout versus a more editorial, grid-based one.

The tool will then generate multiple variations for you to compare. This is a huge advantage. You can see two or three different visual approaches side-by-side and immediately start forming opinions. You might think, "I like the grid from Variation A, but the header from Variation B." This is the iterative process in action.

Once you have a starting point, the real work begins: refinement. You have three primary feedback mechanisms at your disposal. The first is direct file editing. You can click on elements in the generated design and delete or move them. If the AI added a decorative squiggle that you hate, you just select it and delete it. The second is conversational feedback. You can type a message in a chat panel, giving the AI specific instructions. For Tastemaker, the feedback was very specific and detailed:

Examples of conversational feedback:
- "Make the favorites display six across with navigation arrows on the side, like a Netflix carousel."
- "For recent reviews, show them full-width with the cover art on the left, star rating, and review text. Add a spoiler tag."
- "Display lists in a similar grid format to favorites."
- "Add a left navigation rail so users can quickly jump between sections."

The third mechanism is comment annotations. You can leave comments directly on a specific part of the design, like a sticky note. This is great for giving context to your feedback. You might put a comment on the hero image saying, "Make this less prominent."

This process is not one-and-done. It's a loop. You'll generate, get feedback, refine, and generate again. It took several iterations for the Tastemaker prototype to reach a satisfactory state. The final result was a refined profile page with a user header, category tabs for Movies, TV, and Games, six-card favorite rows, spacious review sections, and comprehensive list views. This is the most important thing to remember: AI generates a starting point, not a finished product. The difference between a generic design and a great one is the attention to detail you apply during this iterative feedback loop.

Once you've converged on a design you're happy with, you need to export the mockups. This is usually done as a ZIP file or a single HTML file. This export is your handoff artifact for the next phase.

Key takeaways for prototyping:
- AI design tools are not like Figma; they generate from prompts and references.
- Always attach your design.md and specify the platform (web vs. mobile).
- Answer clarifying questions,they prevent costly mistakes later.
- Request multiple variations to compare and contrast.
- Iterate relentlessly using direct editing, conversational feedback, and comments.
- Export your final mockups as a ZIP or HTML file for the next step.

Step 4: Creating a Consolidated Specification

In the old world, you had three separate documents: a Product Requirements Document (PRD) from the PM, a design file from the designer, and a technical spec from the engineer. This is fragmented and creates massive coordination overhead. In the AI-native world, we consolidate everything into a single, unified file: a spec.html. This file is your project's single source of truth, organized into three tabs: Product Requirements (PRD), Design, and Tech.

Why consolidate? Because it reduces the documentation burden, ensures consistency across disciplines, and makes it possible for one person to review and approve the entire specification in one sitting. It also makes it easier for AI to process. Instead of searching through multiple documents, it has one clear, structured reference.

To make this reproducible, you can create a reusable "spec skill." This is essentially a prompt template that you can use over and over again. It instructs the AI on how to structure the specification document. It tells it what to include in each tab. This is your personal boilerplate for turning a design into a buildable plan.

Let's break down what goes into each tab. The PRD Tab starts with the user problem statement. It then lists the high-level product goals. The requirements themselves should be concise and scannable, not long paragraphs. Organize them by application surface. For Tastemaker, this would be things like:
- Landing Page: Describe the value proposition. Include a call-to-action to create a profile.
- Public Profile: Display user's favorites, reviews, and lists. Allow sharing via URL.
- Creator Dashboard: Allow user to add/edit/delete content. Manage profile settings.

The Design Tab contains the design principles from your design.md, the style guide with specific color values and typography, and, critically, a component library. This is non-negotiable. A component library defines the reusable UI elements,buttons, cards, input fields, navigation bars. Without this, the AI will generate inconsistent, ad-hoc components as the app grows. One button might be blue and rounded, another might be black and square. The component library keeps everything consistent and professional. This library isn't static; it must be updated as you design more screens and introduce new components.

Finally, the Tech Tab is where you make the hard technical decisions. This includes the technology stack. For Tastemaker, the choice was Supabase for the database and authentication, with a modern JavaScript framework for the frontend. But the most important part of this tab is the data schema. This is the blueprint for your database. It defines the tables, the fields, and the relationships between them. This is highlighted as especially important because databases are notoriously difficult and expensive to change once you have production data. You can't just "refactor" a database like you can a piece of code. Getting the schema right up front is critical.

The Tech tab should also include an estimate of build time. However, take AI's estimates with a massive grain of salt. In the Tastemaker project, the AI projected a build time of three weeks. The actual active build time was about thirty minutes, with a few more hours spent on iterative refinement. AI is notoriously bad at estimating time because it doesn't have a good model of its own speed. Use its estimates as a very rough upper bound, not a realistic timeline.

The specification is not a one-shot output. You must read through the entire generated spec and provide feedback. This is a quality control gate. Does the PRD make sense? Are there missing requirements? Is the data schema logical? Does the component library cover all the elements you'll need? Failing to validate the spec before moving on is a recipe for wasting tokens and effort in the next phase.

Key takeaways for the spec:
- Consolidate PRD, Design, and Tech into a single spec.html file.
- Create a reusable "spec skill" prompt to generate this document consistently.
- The PRD tab should be concise and organized by application surface.
- The Design tab must include a component library to prevent visual chaos.
- The Tech tab must define the data schema early, as it's costly to change later.
- Always review and provide feedback on the generated spec before proceeding.

Step 5: Designing All Core Screens

You've designed the two hero screens,the landing page and the main profile page. But a real application has dozens of screens, and many of them are for edge cases that you might not think about initially. This step is about expanding your design from the "happy path" to the complete user journey. You need to design every screen referenced in your PRD requirements.

For Tastemaker, this meant moving beyond the initial prototypes. The design phase expanded to include:
- The landing page, refined from the prototype.
- The public taste profile, refined from the prototype.
- A creator/editor version of the taste profile, which includes edit functionality for reviews and "add" buttons for new content.
- Empty states. This is critical. What does a profile look like when a new user has just signed up and has zero content? A well-designed empty state isn't just a blank page. It should have a clear call-to-action, like "Add your first movie" or "Discover new shows." This is your first impression for a new user, and it heavily impacts retention.
- Full list views for games and other categories.
- Item detail sheets with save and rating functionality.
- A complete onboarding flow. For Tastemaker, this included a handle claim step, a step to select six initial favorite items, and a page-sharing setup.

The requirement to design default states, empty states, and edge cases is essential for a professional product experience. These are frequently overlooked by beginners, but they are the screens that determine whether a user sticks around after their first login. Think about it from a user's perspective: you sign up for a new app, and you're greeted with a blank, broken-looking page. You're probably going to leave and never come back. But if you're greeted with a beautiful empty state that says, "Here's how to get started," you're much more likely to engage.

The review protocol for these screens is the same as before. You use the same three feedback mechanisms: direct editing, conversational feedback, and comment tags. For example, you might look at the onboarding flow and decide that the "handle claim" step is too early. You might use conversational feedback to say, "Move the handle claim step to after the user has selected their six items." You iterate on each screen until it feels right.

This phase is where the cost-benefit of early iteration becomes crystal clear. Changes made during the design phase are nearly free. They involve updating an HTML mockup file. Changes made after the build phase can be incredibly expensive, requiring you to alter databases, restructure code, and re-test functionality. The design phase is the cheapest place to resolve ambiguities and refine the product.

Key takeaways for designing all screens:
- Move beyond the hero screens to design the entire user journey.
- Design for default states, empty states, and edge cases.
- A good empty state has a clear call-to-action to guide new users.
- Onboarding flows are critical for user retention.
- Iterate on every screen using the same feedback mechanisms.
- Resolving issues in design is nearly free; resolving them in code is expensive.

Step 6: Building the Application

This is the moment you've been waiting for. You have a validated problem, a clear design language, a consolidated spec, and mockups for every screen. Now it's time to turn all of that into a working application. This is where we transition from Claude Design to Claude Code.

The build phase begins with two artifacts: your spec.html file and the design export (the ZIP or HTML file containing all your mockups). You attach both to the AI coding tool and issue a build prompt. The structure of this prompt is critical. It should do more than just say "build this app." It needs to set the stage for a successful build.

Here's the structure of a good build prompt:
1. Attach the specification and design files.
2. Ask the AI to review both files thoroughly.
3. Explicitly instruct it to identify any ambiguities, missing information, or clarifying questions it has *before* it starts writing code.

This pre-build question phase is a game-changer. It forces the AI to think about the project as a whole and surface gaps in your planning. For example, the AI might ask, "The spec mentions user authentication, but the design export doesn't include a login screen. How should I handle this?" This is a critical question that, if left unaddressed, would result in a broken feature. By forcing the AI to ask questions, you save yourself from a major headache later on.

Now, let's be realistic about what the build phase actually looks like. It is not a one-shot process. You don't just type a prompt and get a perfect, deployed application. The reality is that even with comprehensive specs and designs, the Tastemaker project required substantial back-and-forth interaction. Here are some examples of the real-world feedback that was given to the AI during the build:

Examples of build feedback:
- "The favoriting hearts should only appear on card hover, not all the time."
- "The profile page elements don't perfectly match the approved design. The header spacing is off."
- "You forgot to include the review section on the profile page."
- "Please add Netflix-style carousel arrows to the favorites rows."
- "Keep the plan and design files updated as you make changes to the code."

This last point is crucial. As the AI makes changes directly in the code, the spec and design files must be kept in sync. You have to explicitly instruct the AI to update the plan and design files whenever product decisions change during the build process. This maintains the single-source-of-truth integrity. If you don't do this, your documentation will quickly become outdated and useless.

The final product for Tastemaker was a live, functional application. It included Supabase database integration and authentication. It had a landing page with a demo profile, full login functionality, and complete content management. Users could add movies, write reviews, and sort their collections. These are features that would have been incredibly difficult to retrofit without the upfront specification work. The database schema, defined in the spec, made the integration seamless.

Key takeaways for building:
- Attach both the spec and design files to the AI coding tool.
- Ask the AI to review the materials and surface clarifying questions before coding.
- Expect an iterative process with multiple rounds of feedback and refinement.
- Provide specific, actionable feedback, often referencing screenshots of issues.
- Explicitly instruct the AI to keep the spec and design files updated as code changes.
- A good plan makes the build phase, including complex features like auth and databases, much easier.

The Complete Workflow Recap

Let's zoom out and look at the entire journey. We've covered a lot of ground, and it's worth taking a moment to see how it all fits together. This framework is not just a collection of tips; it's a repeatable, structured methodology for turning ideas into software.

The six steps are:
1. Define the User Problem: Start with a personal pain point and validate it with AI research.
2. Create a design.md: Establish a visual direction to prevent generic AI output.
3. Explore Prototypes: Use AI design tools to generate and iterate on key screens.
4. Create an HTML Spec: Consolidate product, design, and tech requirements into one document.
5. Design All Core Screens: Expand the design to cover every state, edge case, and screen in the user journey.
6. Build the Application: Use AI coding tools to transform the designs and spec into a functional product.

Underpinning these six steps are five core principles that you should internalize. The first is to plan before you build. At least 50% of your project time should be spent on planning and design. The build phase is easy; the planning is what makes the build possible. The second is to provide visual direction. AI without guidance produces generic output. Your design.md is your defense against mediocrity. The third is to iterate relentlessly. Neither designs nor code will be perfect in the first attempt. The difference between good and great is the willingness to engage in multiple feedback loops. The fourth is to keep documents in sync. The spec and design files must evolve with the product. They are living documents, not static artifacts. And the fifth is to design for edge cases. Empty states and onboarding are as important as the primary screens. They define the user's first impression.

Why does this process work? It works because it aligns perfectly with how AI tools function. AI excels at generating variations from examples, processing natural language feedback, converting visual designs into code, and maintaining consistency when given clear guidelines. The process fails when you ask AI to do what it cannot do well: inventing design direction without reference material, making product decisions without stakeholder input, or building complex systems without a structured plan. This framework is designed to feed AI's strengths and avoid its weaknesses.

Conclusion: The Discipline of Creation

We started this course by saying the old way of building software is broken. We're ending it by showing you a new way. But the most important takeaway isn't about the tools,Claude Design, Claude Code, or any other AI platform. The tools will change. New ones will emerge. The underlying discipline, however, is timeless.

This discipline is about the inversion of effort. For decades, the bottleneck in software was the build. Writing code was slow, tedious, and required deep technical expertise. That bottleneck has been removed. Now, the bottleneck is the plan. The quality of your output is directly proportional to the quality of your input. If you feed an AI a vague idea, you'll get a vague, generic app. If you feed it a precise problem, a distinct design language, and a comprehensive specification, you'll get a precise, beautiful, functional product.

The Tastemaker case study is proof that this works. An individual, not a large team, took a personal frustration and turned it into a live web application with database integration and authentication in a matter of hours. The AI projected a three-week build time; the actual build took minutes. The difference wasn't magic. It was the application of a structured methodology and the willingness to iterate.

Your homework is not to watch more videos or read more articles. It's to go out and build something. Pick a small, annoying problem in your own life. Write it down. Create a design.md based on an aesthetic you admire. Use an AI design tool to prototype it. Write a spec. Design the empty states. Then, and only then, start building. Expect it to be messy. Expect to iterate. Expect to give feedback that feels repetitive. That's the process.

The gap between idea and execution is narrowing every day. The tools are accessible. The frameworks are available. The only thing standing between you and a finished product is your own discipline. The discipline to plan thoroughly, to design with intention, and to apply your human taste to machine-generated output. That is the new skill of the AI-native developer. And it's a skill you can start practicing right now.

Frequently Asked Questions

Introduction

This FAQ covers everything you need to know about turning a raw idea into a working application using AI-native design tools and coding assistants. It addresses questions at every level , from the fundamentals of the six-step workflow to the finer points of component libraries, data schemas, and iterative feedback loops. Whether you're building your first personal project or exploring how this process scales to commercial products, the answers below will help you avoid common pitfalls and get the most out of your AI-assisted development workflow. The questions progress from foundational concepts to advanced implementation details, so you can read straight through or jump to the sections most relevant to your current stage.

Foundations of the AI-Native Design Process

What is the "AI-native design process" and why is it different from traditional app development?

The AI-native design process is a six-step workflow that reorders the traditional product development sequence to leverage AI's strengths while compensating for its weaknesses. The steps are:

1. Define the user problem , Establish exactly what you're trying to solve and for whom.
2. Create a design.md , Develop a visual direction document based on real-world inspiration.
3. Explore prototypes , Use an AI-native design tool (like Claude Design) to generate multiple mockup variations.
4. Create a spec , Build an interactive HTML document containing product requirements, design guidelines, and tech requirements all in one place.
5. Design all core screens , Use the spec to generate mockups for every screen, state, and edge case.
6. Build the app , Hand the finalized design and spec to a coding agent to implement.

The key difference from traditional development is that visual prototypes are created before writing the full spec. In conventional workflows, a product manager writes a spec first, then a designer creates mockups in Figma, and then engineers write technical specifications. The AI-native approach inverts this because looking at high-quality visual mockups makes it dramatically easier to refine the product requirements. Additionally, instead of maintaining separate documents for product, design, and tech, everything is consolidated into one HTML spec, reducing version drift and simplifying revisions.

Why does the user problem need to be defined before anything else?

Defining the problem first anchors every decision that follows. When you understand precisely whose problem you're solving and what that problem actually is, you can make better choices about features, design direction, and even which platforms to target.

For instance, if you're building a personal app, the problem might be: "I have watched thousands of movies and television shows, played hundreds of games, and I want one single page that showcases what I love across all three mediums." The existing tool (like IMDb) only solves part of this,it tracks film and TV but doesn't celebrate games, and its interface is purely list-based with no aesthetic appeal.

When defining the problem, it's also valuable to look for existing evidence that the problem is real. Using AI to research whether other people are experiencing the same gap,whether multiple separate websites exist for curating different media types, for example,can validate whether you're building something genuinely useful or just inventing a problem that doesn't exist.

For those building a product intended for public users rather than personal use, this stage should also include research into monetization potential. The creator of this workflow notes that with AI making software development more accessible, it's harder than ever to make money from apps, so user acquisition and revenue potential must be examined honestly upfront.

What exactly is the six-step framework and how do the steps connect?

The six-step framework is the backbone of the AI-native design methodology. Each step feeds directly into the next, creating a pipeline that starts with a fuzzy idea and ends with a deployed application.

Step 1 defines the problem , you articulate who the product serves and what gap it fills. Step 2 creates the design.md , you establish the visual language that will guide all subsequent design work. Step 3 explores prototypes , you generate and compare multiple mockup variations of key screens. Step 4 creates the HTML spec , you consolidate product requirements, design guidelines, and technical specifications into a single document. Step 5 expands the design , you cover every screen, state, and edge case identified in the spec. Step 6 builds the application , you feed the spec and designs to a coding agent that transforms them into a working product.

The connections between steps are what make the framework effective. The problem statement from Step 1 informs the design direction in Step 2. The prototypes from Step 3 make the spec in Step 4 sharper and more specific. The spec in Step 4 guides the comprehensive screen design in Step 5. And the complete design package from Step 5 is what makes the build in Step 6 fast and accurate.

Do I need coding experience to follow this workflow?

No, you don't need to be a programmer to follow this workflow, though some technical awareness helps at certain points. The entire process is designed so that AI handles the heavy lifting , generating designs, writing specifications, and producing code.

That said, a few things will make your experience smoother. Basic familiarity with HTML and markdown helps you read and edit the spec file and design documents. An understanding of how databases work (tables, relationships, primary keys) will help you review and refine the data schema in the tech tab of your spec. And comfort with giving clear, specific feedback to AI tools is essential , the quality of your output depends heavily on the quality of your input and iteration direction.

The most valuable skill you can bring to this process is not coding , it's taste and judgment. Knowing what looks good, what feels right, and what makes sense for your users is what separates a polished app from a generic one. AI handles the execution; you handle the direction.

Design Direction and the design.md File

What is a design.md file and why is it so important?

A design.md is a markdown file that captures the visual design principles and style guidelines for an application. It includes:

Design principles , High-level statements about how the app should look and feel (e.g., "Keep the interface quiet and let the cover art carry the color").
Color palette , Specific color recommendations with values.
Typography specifications , Font families, sizes, and weight recommendations.
Spacing guidelines , Margin, padding, and gap recommendations.
Component style direction , How cards, buttons, and other UI elements should feel.

The file's importance comes from the fact that AI, by default, tends to produce generic-looking designs,often referred to disparagingly as "purple slop",or designs with a recognizable generic AI aesthetic. A design.md acts as a guardrail that pushes the AI toward a specific, deliberate visual language.

To create one, you can either:

Generate it from visual inspiration , Give the AI screenshots of an app you admire and ask it to extract the visual design language into a design.md. The AI will analyze the screenshots and produce a markdown file with concrete guidelines.
Use pre-built options , Websites like zsh.dev offer design.md files for popular sites like Nike, SpaceX, Apple, Vercel, and Notion, which you can adapt for your own projects.

The critical nuance here is the difference between inspiration and copying. Borrowing the general design language of an app in a different category is acceptable; directly cloning another product's interface in the same, competitive category is not. You should always evaluate whether the inspiration source is appropriate.

How do I generate a design.md from design inspiration?

The process is simple. First, collect screenshots of one or more apps whose visual design you admire. These can come from app store pages, promotional materials, or the apps themselves. Once you have these images, upload them to an AI tool and provide a prompt like:

"Here are a few screenshots from [App Name]. Can you create a design.md for [Your Product Name] based on this visual direction?"

Add product-specific context, such as: "The product helps people share their favorite movies, TV shows, and games on one page. Keep the interface quiet and let the cover art carry the color."

The AI will analyze the screenshots and produce a markdown file with design principles, colors, typography, and spacing recommendations that reflect the visual direction of the source material. This file becomes the reference point for all subsequent design work.

Where should I look for design inspiration before creating my design.md?

Several resources are particularly useful for gathering visual inspiration before you create your design.md:

Mobbin , A database of UI screenshots from real applications, organized by app and screen type. You can search for specific patterns like "profile pages" or "landing pages" and see how different apps approach them.
Dribbble , A designer portfolio platform that showcases high-quality visual work across web and mobile design. Great for discovering emerging aesthetic trends.
Direct observation , Any app, website, or visual medium that demonstrates an aesthetic worth borrowing from. This could be a favorite website, a well-designed mobile app, or even a print publication.

When collecting inspiration, think about what specifically appeals to you about each source. Is it the color palette? The typography? The spacing and layout rhythm? The overall mood? Being specific about what you admire makes it easier for AI to extract useful guidelines.

How do I handle the ethics of visual borrowing in design?

The line between inspiration and copying is one of the most important judgment calls in this workflow. The general rule is: borrow the design language, not the product itself.

Acceptable borrowing includes using a similar color palette, typography approach, spacing rhythm, or general layout philosophy from an app in a completely different category. For example, borrowing the clean, editorial feel of a news site for a personal profile app is fine , the categories are unrelated, and you're adapting the aesthetic to serve different content and interactions.

What crosses the line is cloning another product's interface when you're building something in the same category. If you're building a social media app and you copy Instagram's exact layout, color scheme, and iconography, that's a problem , both ethically and legally.

A practical approach: ask yourself whether your app would be confused with the inspiration source. If the answer is no, you're probably in safe territory. If the answer is yes, you need to push your design further in a different direction.

Prototyping with Claude Design

What is Claude Design and what makes it useful for prototyping?

Claude Design is an AI-native design tool that lets you generate interactive mockups from natural language prompts. It's included with a Claude subscription and offers several features that make it particularly well-suited for rapid prototyping:

Clarifying questions , After receiving your initial prompt, Claude Design asks clarifying questions before generating mockups. Questions like "Whose taste profile should the example show?" or "What sections should appear on the public profile?" force you to think through your design requirements in detail. This is a genuinely useful feature that many other AI design tools lack.

Variations , You can request multiple visual variations of the same screen simultaneously, allowing you to explore divergent design directions before converging on the strongest one.

Direct editing , You can click directly on elements within the mockup and edit them inline, removing text or elements you don't like without rewriting your entire prompt.

Chat feedback , You can open a side panel and give written feedback on the mockup, and the AI will iterate on the design accordingly.

File export , Designs can be exported as HTML files or zip files, making it easy to pass them along to coding tools or preserve them as documentation.

For prototyping, Claude Design can be used with the Opus model for most tasks,it's more cost-efficient and perfectly capable of producing high-quality mockups for most product types.

How do I write an effective initial prompt for Claude Design?

The quality of your initial prompt directly determines the quality of the mockups you receive. A strong prompt includes several key elements:

Product name and purpose , Tell the AI what you're building and what it does. For example: "Tastemaker is a web app where people showcase their favorite movies, TV shows, and games on a single public profile page."

Reference to the design.md , Mention that you have a design.md file and reference its key principles. This grounds the AI in your established visual direction.

Specific screens , List the exact screens you want mocked up. "Create a landing page and a public taste profile page" is much more actionable than "design my app."

Number of variations , Specify how many variations you want. "Generate 3 variations of the profile page" gives you options to compare.

Target platform , Clarify whether this is a web app, mobile app, or something else. This affects layout decisions, navigation patterns, and responsive behavior.

Content guidance , If you have specific copy or content you want included, provide it upfront. Otherwise, the AI will generate placeholder text that you'll need to replace.

How do prototype variations help in the design process?

Requesting variations allows you to explore divergent design directions before committing to one. When asked for variations, the AI might produce, for example:

Variation A: A row-heavy layout with larger, more spacious cards that prioritize browsing comfort.
Variation B: A grid-style editorial layout that packs more information into the same space, with more condensed presentation of lists and collections.

Seeing multiple directions side by side helps you articulate what you actually prefer about each approach. You might realize you prefer the light theme of one, the layout of another, and the navigation structure of a third. You can then iterate,either through direct editing or written feedback,to converge on a hybrid approach that incorporates the strongest elements of each.

This divergent-then-convergent flow mimics what professional designers do when they explore multiple directions before settling on one. The advantage with AI is the speed: where a designer might take days to produce several mockups, Claude Design can generate them in minutes.