Website design with AI: an editable layout and state checks

Start with a result you can edit

Assess Figma AI by the structure of its resulting file rather than the impact of the first screen. A designer’s result might be a request form: fields remain separate elements, labels can change, repeated buttons look consistent, and errors and successful submission can be shown separately. A picture of a similar form does not solve this task: its structure cannot be properly checked or its elements reused.

We will examine a fictional bicycle repair service called Spitsa. It needs a diagnostic request layout for desktop and phone. We are not creating an operating service, sending data, or performing a real agent run here. This is a complete educational assignment and a way to check the resulting design. If your goal is a working form, the next stage concerns app development and verification.

Compile a short brief before generation

The request has one purpose: a visitor provides a name, contact, and fault description. In this example, contact is entered as free text and an additional photo is optional. We do not promise repair prices, response times, or mechanic availability: the client has supplied none of that information. An acceptable button is ‘Submit a request’; an acceptable message after illustrative submission is ‘Request received in this educational example’.

Specify four states: empty form, completed fields, required-field error, and confirmation screen. For the layout, choose widths of 390 and 1440 pixels, a calm neutral background, and one accent color from the project library. These are our example’s conditions rather than universal Figma requirements. If the company already has components, use them instead of a random new style.

Choose a tool and check file access

Current Figma documentation describes an agent working in Figma Design files: it helps create and modify designs using selected layers and attached materials as context. File-editing capability depends on the user’s seat and access rights. Figma distinguishes this agent from Figma Make, intended for interactive apps and prototypes. Do not treat these products as the same output.

Before a large assignment, make an educational copy and check that you can manually change text and field placement. Open documented agent controls in the file available to you. If your account lacks the feature, do not search old guides for a similar button or pay blindly: clarify access and terms separately. The exercise can be completed manually from the same brief.

In the current Figma Design interface, select a layer and open Agents beside it, or use Cmd/Ctrl + Enter. The Agents sidebar in the left navigation supports longer conversations. Access to editing a particular file depends on permissions; start in your own educational Draft file rather than the team’s working design.

A complete agent assignment

Copy the assignment with its inputs: ‘We are working in an educational Figma Design file. Create an editable bicycle diagnostic request layout for a fictional service called Spitsa. The user enters a name, contact, and fault description; a photo is optional. Do not invent prices, deadlines, reviews, or company advantages. Prepare versions 390 and 1440 pixels wide and four states: empty, filled, required-field error, and confirmation. Use existing file styles and components; if none exist, first propose a small set of typography, color, field, and button styles. Show required-field names and clear error messages. Use separate editable layers and reusable elements. Do not add payment, an account, chat, or real submissions. First list screen structure and unresolved questions. Then create the layout and explain which elements are components and what requires manual checking.’

An unresolved question is not a failure here. If the agent asks which contact format is accepted, choose the rule before the next iteration. For example, the educational field accepts text while format validation remains undefined. The model must not depict implemented phone validation when its behavior is absent from requirements.

Check structure rather than appearance alone

In the resulting file, try changing the button label in one place and check corresponding variants. Rename the fault description with a longer phrase. Insert a long name and contact. If text disappears, is clipped without reason, or breaks neighboring placement, fix the layout structure before choosing decorative details.

Also check state distinctions. An error message must identify a specific field and explain the user’s action. A red outline alone is insufficient. The confirmation screen should show what happened in the scenario without promising a server connection. A design file shows intended behavior; its operation still needs proving in the app.

Acceptance table for the educational layout

This is a table for checking your file rather than a report of a completed Figma run. Start with one state at one width. If it fails, subsequent versions only multiply the same error. Successful structural checking supports continuing the design, but does not prove accessibility of the finished website.

Fix one observable defect at a time

Instead of ‘make it prettier’, write: ‘In the 390-pixel version, a long description overlaps the button. Preserve the other elements and field order. Fix placement so the description can occupy several lines; show short and long values.’ After the change, check the empty and error states again. Fixing one screen may break another.

Clarify the error text separately: ‘Contact is required. Show “Enter a contact method” beside the relevant field; do not change other labels.’ That is the expected action for our form. If the agent adds phone checking against an unspecified pattern or changes the primary color, revert the change and narrow the request. Save the previous working version before the next iteration.

Hand off the design with clear boundaries

Before handing it to a developer, label states, sizes, and field rules. State that the photo is optional and the contact format remains undefined. Attach the acceptance table and list unresolved questions: network errors, data storage, file restrictions, and real submission confirmation. This avoids falsely implying that difficult parts are already implemented.

Repeat the check through another person’s eyes: can they find where the request begins, which data is required, and how to return after an error? Ask them to follow the layout scenario without the author’s hints. Record difficulties as observations rather than percentage improvements. One viewing does not prove high UX quality but can reveal a specific unclear label.

Also agree on the change process. If the client adds time selection, that is new behavior rather than a cosmetic adjustment. Decide where the list of times comes from, what counts as booked, and how confirmation changes. Clarify those answers first, then expand the layout. The simple starting example is useful precisely because it shows the cost of each additional interface promise.

The final output should be an editable file, clear states, and implementation questions. Websites, calculators, and apps need other checks described in neighboring exercises. Do not call a design a finished product merely because a drawn button can be clicked.

Sources

• Figma: agents working in design files

Frequently asked questions