Figma Make for Web Designers: Client Prototypes and Where It Breaks

Yes, a web designer can use Figma Make to produce a clickable client prototype from a prompt or a Figma design, and it suits early concepts well. It falls short on design-system fidelity, code you can ship, precise interaction detail and credit cost, so treat the output as a concept to refine, not a deliverable.

That framing matters because a Make prototype looks finished. It runs in a browser, has working buttons and real-looking content, and a client can click through it on their phone. The risk is the client concluding the website is nearly built. Your job is to use the speed for the part it is good at, which is getting a reaction early, and to be explicit about the gap between that and a production build.

Follow me on Instagram@sagnikteaches

The plan and feature facts below come from Figma's own pricing page and help centre, read in November 2026. I have not tested every Make feature on live agency projects, so where I describe a likely failure I say what to test, rather than claiming a result.

Connect on LinkedInSagnik Bhattacharya

What Figma Make is, in the terms a designer cares about

Figma Make takes a text prompt, and optionally design context, and builds a working prototype or small web app you can preview, edit and publish. Figma's help centre groups the features into a few areas that matter to client work:

Subscribe on YouTube@sagnikteaches

• Creating and editing: create a Make file, edit it with follow-up prompts, use plan mode to agree an approach before it builds, and edit the code directly.
• Design systems: Make kits and guidelines let you bring a design system package into Make so it builds with your components.
• Sharing: publish, update or unpublish a file, embed a prototype in a slide deck, board or design file, and copy a preview back as design layers.
• Developer routes: push to GitHub, use Git with code layers, and work in a local codebase.
• Backend: the help centre lists adding a backend to a prototype, and the pricing page mentions Supabase support.
• Model choice and credits: you can select an AI model, and the help centre has guidance on optimising credit use.

Names and menus change quickly in this product, so use the help centre category for Figma Make as your reference and expect the interface to shift.

What it costs: plans and credits to verify

Figma's pricing page, read in November 2026, listed these seat prices and Make allowances. Confirm them yourself, because both change.

The page also showed Dev and Collab seats at 500 credits a month each. Professional has a Monthly/Annual toggle, and the $16 Full-seat figure is the price the page shows with Annual selected, which is how it loads. Switch the toggle to Monthly to see the month-to-month rate before you budget a seat or quote a client. Organization and Enterprise prices are marked as billed annually, so compare like with like. For a freelancer or a small agency, Professional is the likely fit. The thing to learn early is how fast your own prompts consume credits, because the pricing page gives allowances, not a count of prompts. Run one real prototype and see what share of the month's allowance it used before you plan a workflow around it.

Seat type matters as much as plan. Figma's Make FAQ says Make is included on the Full seat; people on Dev, Collab or View seats can try it in drafts, but those files cannot be shared, so whoever builds client prototypes needs a Full seat. The free Starter plan can explore Make too, with two limits that bite on client work: it cannot bring style context from team libraries, and it can publish to the public web only by also publishing to the Figma Community, which is no place for a client's unannounced site.

The prompt-to-prototype flow I would use

1. Start from the brief, not the tool. Collect goals, audience, pages and content first. Our client questionnaire tutorial covers how.
2. Write a structured first prompt. Name the business type, audience, one primary action, the pages or sections, the tone and any constraints such as colours and fonts.
3. Use plan mode if available. Ask Make to outline the page structure and components before it builds, and correct the outline.
4. Build, then refine with short prompts. One change per prompt, such as "make the booking button the primary action on mobile", to keep control of what changes.
5. Check on a phone-sized preview. Clients will open the link on their phones, and generated layouts often need the most correction there.
6. Replace placeholder content. Swap invented text and stock images for the client's real material before showing it.
7. Publish a share link or embed it, and label it as a concept prototype.

A pet shop's booking-led homepage from one prompt

Illustration. Say a freelance designer is pitching a homepage for an independent pet shop that wants more grooming bookings. They have a one-page brief and want a clickable concept for the first client meeting, rather than static mock-ups.

Build a responsive homepage prototype for a small independent pet shop. Goal: get visitors to book a grooming appointment. Audience: local dog and cat owners on mobile. Sections: header with phone number and Book grooming button, hero with one-line promise, three grooming packages (Bath, Full groom, Puppy intro), opening hours and map placeholder, three customer review placeholders, footer. Style: warm, friendly, rounded shapes, forest green and cream, large readable type. The booking button opens a simple form with name, pet type, preferred day and a submit confirmation. Use placeholder text and clearly label it as placeholder.

Illustrative result of a first pass: a plausible single page with the sections in order, a working form with a confirmation message, and a green and cream palette. Illustrative problems: the three packages have invented prices, the phone number is a placeholder, the hero text makes claims the shop has not made ("the best groomers in town"), and on a narrow screen the package cards stack with oversized padding. The designer's second and third prompts fix the padding and strip the invented claims. They then replace content with the shop's real prices and photos.

The value is in the meeting. The client clicks the booking form on their own phone and says "can the pet type be a dropdown?" in the first minute, which would have taken days to reach with static frames. That is feedback you can price and plan from. The cost is the time the designer spent cleaning invented content, plus the credits.

Where it breaks on client work

These are the failure points to test on your first real job. They follow from how generated prototypes work and from what Figma's help centre documents, not from a lab result.

Design-system fit

If the client has a brand system, Make's output starts generic. Figma's help centre describes Make kits and guidelines for connecting a design system package, which is the route to better fit, but it takes setup: packaging components, writing guidelines, testing. For a one-off pitch, you may do better prompting with explicit colour and type values and fixing the rest in Figma Design.

Code quality

The prototype is real code, which tempts clients and developers to ask for it. Review before reuse: semantic structure, accessible names and focus order, how state is handled, dependencies, and whether anything is hard-coded. A developer should decide whether to adopt, rewrite or discard it. Never promise a client that the prototype is the website.

Precision and consistency

Repeated prompting can change things you did not ask to change. Keep a short list of what is approved, check earlier screens after each edit, and use Make's version history, which the help centre says lets you go back and edit earlier versions of the app. Fine control, such as exact spacing tokens, is usually quicker in Figma Design.

Content and claims

Generated text invents offers, awards and statistics. Remove or replace all of it before a client sees it, or label it clearly. An invented testimonial in a shared prototype is a problem even if it is marked as a placeholder.

Accessibility

Do not assume generated pages meet accessibility standards. Check contrast, keyboard use, labels and headings. See our tutorial on AI accessibility audits for what automation can and cannot catch.

Credits and scope creep

Each iteration uses credits, and a client in a live meeting can ask for ten changes. Decide beforehand how you handle live edits. If clients start treating the prototype as a free first build, use a change process; the change order tutorial covers it.

Backends and data

Figma's pricing page lists backend support through Supabase, for logins, stored user data and private APIs, and says Make can now scaffold a Payload backend with a database and admin panel. A prototype with a working form or login can tempt you to collect real data in it. Do not. Use test data, keep the file private or unlisted, and check what the backend stores and who can see it. A concept prototype is the wrong place for a client's real customer details.

Five client scenarios and how I would handle each

A pitch for a new client

Use Make freely to produce a concept, label it, and price the real build separately. Your proposal should say the prototype demonstrates direction, not scope. See our proposal template tutorial.

An existing client with a brand system

Set up a Make kit if you will do this repeatedly for the client, and otherwise design the key screens in Figma Design and use Make for interaction concepts only.

A client who wants to see a booking or checkout flow

Make is good at a clickable flow with form states. Keep the data fake, state what is not connected, and do not suggest payment or personal data handling is built.

An internal tool or dashboard concept

Prototype with invented data to agree on screens and filters. Expect to redo the data logic and permissions in the real build.

A landing-page test for the client's marketing team

Fine for a concept. Before it goes live, rebuild it in the client's actual stack or review the generated code properly, and run your accessibility and performance checks.

A second case: a retained client with a brand system

Illustration. A designer looks after a garden centre's website on a monthly plan. The brand has a palette, two fonts, button styles and a spacing rule, all held in a Figma library. The centre wants a concept for a spring plant-sale landing page and a click-through of a plant-finder quiz.

Starting from a blank prompt would give generic styling, so the designer spends the first hour on the design-system route that Figma's help centre describes under Make kits: preparing the components and writing short guidelines that say how buttons, cards and spacing should be used. The guidelines are plain statements such as "primary buttons use the deep green; never place text over photographs without an overlay; cards have 24px padding". The designer then prompts for the landing page and the quiz, and checks that the buttons and cards match the library.

Illustrative outcome: most components come out right, the quiz works as a four-step flow, and two things still need correction: a heading level skipped from H2 to H4, and a card grid that ignores the spacing rule on tablet widths. The designer fixes them by prompt or by copying the preview back into Figma Design as layers and adjusting by hand. The first job costs setup time, and later jobs for the same client reuse it, which is when the kit pays back. If a client is a one-off, the setup rarely does.

Credit budgeting with a quick sum

Because allowances are monthly, budget them the way you budget hours. Illustrative figures only: suppose the Professional Full seat's 3,000 monthly credits are what you have, and your pet-shop pitch used 450 credits across 25 prompts, about 18 credits a prompt on average. At that rate a month gives you around 165 prompts of similar size, or roughly six pitches of that scale, with nothing left for anything else. Your own numbers will differ, because larger prompts, model choice and the size of the file all change the cost. The method is the point: run one real job, divide credits used by prompts, and then decide how many prototypes per month the plan supports.

Ways to spend fewer credits, in line with the guidance Figma's help centre offers on optimising them: agree the structure in plan mode before building, make one change per prompt, avoid asking for a full rebuild when a small edit will do, and do fine adjustments by hand in the editor.

Moving a Make prototype back into your design process

A prototype is rarely the end. Three routes are worth knowing, all of which the help centre describes.

1. Copy the preview as design layers. You bring the layout into Figma Design, where you can tidy spacing, rebuild components and apply your tokens. This is the quickest way to turn a concept into something you control.
2. Hand to a developer through GitHub or a local codebase. The developer decides what to keep. Brief them honestly about what was generated, what was edited by hand and what was never tested.
3. Keep it as a reference only. Use it in the meeting, record the decisions, then design and build from scratch. This is often the safest route for sites that will be around for years.

Whichever you choose, write the decision on the project: "Make prototype is a concept; production build starts from the approved design". That sentence prevents the argument six weeks later about why the launch needs a build budget.

Checklist before you show a Make prototype to a client

• All invented prices, claims, reviews and statistics removed or labelled as placeholders.
• Real logo, colours and fonts applied, or a note that they are not yet applied.
• Tested on a phone-sized preview and on a desktop width.
• Every button either works or is clearly marked as not connected.
• Forms use test data only, and nothing collects real personal details.
• Link shared as private or unlisted, and unpublished after the review if no longer needed.
• Concept label at the top, plus a sentence in the proposal about what the prototype stage covers.
• Credits left in the month checked, in case the meeting leads to live edits.

Pricing the prototype stage honestly

Clients sometimes expect a cheaper project because a prototype took an afternoon. Explain what the afternoon bought. A sensible way to price is by what you deliver: a concept stage with a fixed number of revision rounds, then a separate design and build estimate. Illustration: if the concept stage takes three hours of your time and the tool's credits are a small part of a subscription you already carry, charge for the thinking, the testing and the cleanup, not for the tool minutes. Then the build quote covers the work the prototype does not do: responsive refinement, accessibility, performance, content, testing and deployment. If you have a monthly plan, the maintenance plan tutorial shows what to offer after launch.

Reading the prototype with a developer's eye in ten minutes

Before you tell a client the prototype could become the site, ask a developer, or look yourself, at five things. Is the heading structure logical, with one H1 and no skipped levels? Do interactive elements have visible focus and accessible names? Are images given alt text or marked decorative? Is the layout built with flexible units, or fixed widths that break on a small phone? And does anything call an external service you did not choose? Illustration: a quiz prototype that quietly loads a third-party script for its animation is a privacy and performance decision you have not made yet. Each answer goes into a short note on the project, so the build estimate reflects what a real developer would have to fix, not what the demo seemed to promise.

Telling the client what they are looking at

A short note at the top of the prototype link avoids misunderstandings. Illustrative wording: "This is a concept prototype. It shows layout, flow and tone. Text, images, prices and form handling are placeholders. Nothing here is connected to real data, and the final site will be built and tested separately. Please tell me what feels right and what does not." Pair it with a sentence in your proposal about what the prototype stage includes and how many rounds of changes you will make in it.

A good test of whether Make belongs in your process is simple. Take your next pitch, time the old route against the new one, and count how many client comments you got at the first meeting. If the prototype sped up decisions and you did not spend longer cleaning up than you saved, keep it. If you would like help fitting this into a wider process, that is what a 1:1 call covers, and you can reach me here. Verify plan details on Figma's pricing page before you quote costs to anyone.

Questions designers ask about Figma Make

Is Figma Make free to use?

You can try it on the free Starter plan, which Figma's pricing page showed with 150 AI credits a day, up to 500 a month, in November 2026. Starter cannot use team libraries for style context and can publish to the public web only via the Figma Community, so it suits trying Make, not routine client work.

Which plan do I need for client prototypes?

A paid plan with a Full seat is the sensible starting point. Figma's pricing page listed the Professional Full seat at $16 a month with Annual billing selected, plus 3,000 AI credits a month, in November 2026; toggle to Monthly for the month-to-month rate. Confirm on the page and test with one real project first.

Can I hand Make code to a developer?

Treat it as a prototype, not production code. Figma's help centre describes editing the code, pushing to GitHub and a local codebase workflow, so a developer can take it further, but the code needs review for structure, accessibility, performance and security before anything goes live.

Will it use my client's design system?

Only if you set it up. Figma's help centre describes Make kits and writing design system guidelines so Make works with your components and packages. Without that, expect generic styling that you then have to correct, so budget time to set the kit up properly.

Should I show clients the Make prototype directly?

Show it with a clear label that it is a concept prototype. A clickable prototype can look finished, and clients may assume the build is nearly done. State what is real, what is placeholder content and what still needs design and development.

Further reads

• AI Wireframe Generator for Web Designers: From Brief to Clickable Draft — Going from a brief to a clickable draft with other tools.
• AI Website Builder or Web Designer: What Each Really Costs — What an AI builder costs against hiring a designer.
• AI Tools for Website Design: Accessibility Checks Before Handover — Checks to run before anything goes to a client.
• Free Web Design AI: What a Freelancer or Small Agency Can Use — Free tools a small agency can combine with Figma.
• Website Development by AI: What Agencies Can Ship and What Needs Review — A review checklist for AI-built client sites: what an agency can ship quickly and where a human check is mandatory.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Figma pricing page (figma.com/pricing), the Figma Make help centre category, Explore Figma Make and Figma Make FAQs on help.figma.com, read 4 November 2026. Plans, seat prices and credit allowances change; confirm on the vendor pages.