The Webflow + AI Workflow I Use on Every Client Project (Step-by-Step)

Fotografia de Homem careca com camisola preta e com oculos, sobre um fundo cinza
Valter Rosa
Designer & Webflow Developer
Minimalist illustration of a website wireframe on the left connected to a component tree on the right through a central AI node, representing a Webflow and AI design-to-development workflow.

Before AI, this took me half a day

When a new client project landed in my inbox, the first few hours were always the same: reading the brief, asking clarifying questions, trying to figure out what pages were actually needed, sketching a rough structure on paper, second-guessing myself, and starting over. Not because I didn't know what I was doing — but because translating a client's ideas into a clear, buildable architecture takes real mental effort.

Now that process takes me under an hour. Not because I've found a shortcut that skips the thinking. But because I've built a workflow where AI handles the heavy lifting of the early stages, so I can focus on what actually requires my judgement: the design decisions, the UX logic, and the client relationship.

This is the exact process I use on every project. Prompts included.

What this workflow assumes

Before I get into the steps, a quick note on context. This workflow assumes you have:

  • A client brief (even a rough one — an email, a call summary, a few bullet points)
  • Access to an AI assistant (I use Claude, but this works with ChatGPT or Gemini)
  • A Webflow account where you'll build the site

That's it. No special tools, no paid add-ons. Just a smarter sequence.

Step 1 — Feed the brief to AI and extract the real structure

Most client briefs are written from the client's perspective, not the user's. They describe what they do, what they want to say, and what they're proud of. What they rarely articulate clearly is: what should a visitor understand in the first 10 seconds, and what should they do next?

Before I open Webflow — before I sketch anything — I paste the brief into Claude and use this prompt:

Prompt 1 — Brief analysis:
"You are a UX strategist and web designer. I'm going to share a client brief with you. Based on it, identify: (1) the primary goal of the website, (2) the target audience and their main pain points, (3) the single most important action a visitor should take, (4) the tone of voice and brand values implied by the brief, and (5) any gaps or missing information I should clarify with the client before starting. Here's the brief: [paste brief]"

The output is almost always sharper than what the client gave me. It surfaces assumptions, flags gaps, and gives me a clear starting point. I review it, correct anything that's off, and use it as my project foundation.

💡 Pro Tip: Don't just copy the AI output. Read it critically. Clients often write briefs that emphasise what they're proud of rather than what the user needs. Your job is to close that gap — the AI helps you see it faster.

Step 2 — Generate the sitemap

With the brief analysis done, I move to information architecture. I use this prompt:

Prompt 2 — Sitemap:
"Based on the analysis above, suggest a sitemap for this website. List the main pages, the purpose of each page in one sentence, and the key sections each page should contain. Keep it lean — prioritise pages that serve the user's journey, not pages that serve the client's ego. Format it as a simple numbered list."

I typically get a clean list of 5 to 8 pages with a clear rationale for each. I then filter it: anything that isn't essential for the first version gets marked as "Phase 2" and noted in the project scope. This protects the timeline and gives the client a clear sense of what they're getting.

This step alone saves me at least 45 minutes of back-and-forth thinking — and it gives me something concrete to show the client early, before any design work begins.

Step 3 — Create the content skeleton (section by section)

This is the step most designers skip — and it's the one that prevents the most revisions. Before I design anything, I create a content skeleton: a rough text version of every section on every page.

Not finished copy. Not polished headlines. Just enough to know what goes where.

Prompt 3 — Content skeleton:
"For the homepage of this website, write a content skeleton. For each section, provide: a working headline, 2–3 sentences of placeholder copy that explains what should go here and why, and a note on what visual element would support this section (image, icon, testimonial, etc.). Write it as if you're briefing a copywriter — clear, purposeful, not final. Sections to include: [list your sections from Step 2]"

The result is a document I can share with the client before touching the design. It makes the structure visible and discussable without the distraction of visual choices. Clients can say "I want more emphasis on X" or "this section isn't right" — and that feedback happens at the right moment, not after I've built three pages.

Step 4 — Set up the Webflow foundation before any design

Now I open Webflow. But I don't start designing pages. I start with the system.

The first thing I configure on every project:

  • Colour variables — Primary, secondary, accent, neutrals, and semantic colours (success, error, warning). I define these in the Variables panel before touching a single element.
  • Typography — I set up global classes for heading sizes (H1 through H4), body text, small text, and captions. Consistent naming: .heading-xl, .heading-lg, .text-body, .text-small.
  • Spacing scale — I create utility classes for common spacing values (8, 16, 24, 32, 48, 64, 96px). These become the padding and margin language of the entire project.
  • Grid and container — One container class with a max-width, one grid class with standard column setup. Everything else adapts from here.

This takes about 20–30 minutes. It feels slow. It is not slow — it's the investment that makes every hour of design work faster and every client revision easier to implement.

💡 Pro Tip: Name your classes with intent. A class called .section-padding-lg tells you exactly what it does and when to use it. A class called .div-block-47 tells you nothing and will haunt you three months later during a maintenance call.

Step 5 — Build components before pages

With the system in place, I build reusable components — not pages. I start with the smallest, most repeated elements and work outward:

  1. Buttons — Primary, secondary, and text variants. All styled from the same base class with modifiers.
  2. Cards — Whatever card pattern the project needs (service cards, blog cards, testimonial cards). Built as Symbols so a change in one place reflects everywhere.
  3. Navigation — Desktop and mobile states, with all link states properly styled.
  4. Footer — Built once, used on every page.
  5. Section wrappers — A standard section structure with consistent padding, background options, and container alignment.

Only after these components exist do I start building pages — by assembling components, not designing from scratch.

This is the single biggest efficiency gain in the entire workflow. When a client asks to change the card design two weeks into the project, I update one Symbol and it's done. Without this approach, that same change requires touching every page manually.

Step 6 — Present the wireframe before the visual design

At this point I have: a content skeleton (from Step 3) and a basic wireframe assembled from the components I built. It's not pretty. It's not supposed to be.

I present this to the client before going anywhere near visual design. No colours beyond the brand palette I've defined, no custom imagery, no animations. Just structure and content.

I frame it like this in the presentation: "What you're seeing here is the architecture of your website — what's on each page, in what order, and why. We're not looking at design yet. We're making sure the structure is right, because changes at this stage cost minutes. Changes at the design stage cost hours."

Clients almost always appreciate this. They give feedback on structure and content, not on visual choices. The result: fewer revision cycles, cleaner feedback, and a much shorter path from wireframe to final design.

💡 Pro Tip: Record a short Loom video walkthrough of the wireframe rather than sharing a static link. Walking through it in your own words, explaining the reasoning behind each decision, builds trust and reduces misunderstandings significantly.

The full workflow at a glance

  1. Brief analysis with AI — Extract primary goal, audience, CTA, tone, and gaps. (10 min)
  2. Sitemap generation with AI — Define pages and their purpose. Filter to what's essential. (10 min)
  3. Content skeleton with AI — Working copy for every section, shared with client before design. (15 min)
  4. Webflow foundation — Colour variables, typography, spacing, grid. Built once. (25 min)
  5. Component library — Buttons, cards, nav, footer, section wrappers. Built before pages. (45–60 min)
  6. Wireframe presentation — Structure review with client before visual design begins. (30 min + client call)

Total time from brief to wireframe presentation: under 3 hours, including the client meeting. Before this workflow, that same process took me a full day — sometimes more.

What AI doesn't replace

I want to be clear about something: AI handles speed and structure in this workflow. It doesn't replace judgement.

The prompt outputs are starting points, not finished work. I review every sitemap suggestion and cut what doesn't belong. I rewrite content skeleton copy that misses the client's voice. I make design decisions that no prompt can make for me — because design decisions are always about the specific person using the site in a specific context.

What AI gives me is mental bandwidth. By offloading the structural thinking to a tool, I can spend my cognitive energy on the things that actually matter: the UX logic, the visual choices, and the relationship with the client.

That's the point of this workflow. Not to work less. To think better — on the things worth thinking about.

Conclusion

The gap between a good designer and a great one isn't talent. It's process. Having a repeatable, reliable system means you show up to every project with clarity — not just on what you'll build, but on why, in what order, and what you'll present to the client at each stage.

If you try this workflow on your next project, I'd genuinely like to hear how it goes. What worked, what you adapted, what you'd add.

And if you'd like help setting up a Webflow project with this kind of system baked in from the start, feel free to get in touch. 😉