Turn a written brief into a first UI draft

Which tool fits the first draft you need?

Choose a local app builder such as Dyad when you need a working interface in a code folder and can review generated changes. Use Penpot when the immediate task is a screen design, a clickable prototype or a shared design handoff rather than AI-generated application logic. Onlook is relevant when you want visual changes connected to a codebase; its current README advertises early access, so check access and setup before scheduling work around the hosted product.

These choices replace different parts of a workflow. A polished prototype does not establish working authentication, a database or secure permissions. A generated React screen does not establish a maintained production application. This guide recommends a small local prototype first: one main user task, synthetic example records and no real account or payment connection.

What should the written brief contain?

Write down the user, the task, the required information and what success looks like. For a support dashboard, the task might be finding an overdue request and assigning it to the correct teammate. Specify the fields, filters, primary action, empty state and error recovery. Name the desktop and phone widths you will inspect. Include readable labels and keyboard behavior rather than only a color preference.

Keep non-goals explicit. For the first draft, use local sample records and a simulated save confirmation. Exclude sign-in, production APIs, customer data, tracking and billing until the interface has been reviewed. If the design must match an existing system, supply the actual font names, color values and spacing rules you are allowed to share. Ask the builder to list unresolved requirements instead of making them up.

How do I set up Dyad for a local draft?

Download Dyad through its official website for a supported platform. Open the installed application and complete the setup requirements shown on its home screen. The documented quickstart requires Node.js, the runtime used by generated apps, and access to a model. Use the provider's Node.js help if setup fails rather than copying an unrelated installation command.

Choose a model connection you understand. Dyad documents API-key providers and local-model connections. Add an API key in Settings under Model Providers when using that route, then select the intended model. A local model requires a separate working runtime and adequate device resources; installing the editor alone does not install every model. Start a disposable project before importing an important codebase.

What does the free workflow actually cost?

Dyad offers a free local edition, while the checked Pro page starts at USD 20 per month with a separate credit allowance. The free editor does not include unlimited paid-model inference. With your own API key, the provider's usage prices and limits apply. A local model avoids a hosted inference bill for those local requests but still uses your hardware, memory, storage and electricity. Hosting a finished app or adding a database is another decision.

The repository distinguishes Apache-2.0 content from the src/pro directory, which has a separate Functional Source License. Check the relevant edition before describing all code as open source. Penpot and Onlook have their own hosted plans and setup conditions. Compare those current pricing links on the tool profiles; a free design application does not include third-party stock artwork, every model or a managed deployment.

What prompt can I use for a first UI draft?

The following is an original example brief, not a claim about a tested output. Replace the workflow details with your own requirements before submitting it. Keep the first version small enough to inspect in one review.

Build a support-request dashboard for a team coordinator. Show twelve synthetic requests with subject, owner, status and due date. The main task is finding an overdue request and assigning an owner. Include a text search, status filter, request detail view and a clearly labeled assignment action. Use a readable table at 1440px and a usable narrow layout at 375px. Include loading, empty, no-results and save-error states. Support keyboard navigation and visible focus. Use the existing project's components and design tokens. Use local sample data only. Do not add sign-in, real APIs, analytics, payment or external uploads. First explain the proposed screens, then make the smallest change that implements this draft. List any missing requirements.

In Dyad's documented flow, submit the brief through the chat input, inspect the proposed changes and approve only the changes you intend to run. Its quickstart describes a preview after approval. Generated code runs on your computer: a preview is a reason to review the changes, not evidence that the code is safe or correct.

How do I review the result before another prompt?

Read the builder's change summary and inspect the affected files. Compare the output with the brief: can a user identify an overdue request, find its owner and understand the result of assigning it? Look for fabricated integrations, extra dependencies, hardcoded secrets and unrelated file changes. Keep the data synthetic while making these checks.

At 1440px and 375px, check that names and prices remain readable, actions do not overlap, and a table either adapts or has an understandable scrolling region. Use the keyboard to reach filters and actions. Try an empty result, a long request name and a failed save state. These are suggested checks for your own draft; this article does not report results from executing the sample application.

How can I improve the design without restarting?

Request one bounded correction at a time. For example: keep the data and routing unchanged; make the owner and status columns readable at 375px, preserve the assignment action and show which files will change. Compare that result with the previous version before combining it with another feature. In Dyad, chats for one app share the codebase, so starting a new chat does not create an isolated project.

Use version history before large changes. Dyad documents versions and reverting, but a second copy or repository backup of important work is still useful. If you move into Penpot for manual design review, make the handoff explicit: record the component, spacing, state and interaction changes needed in the code. If you evaluate Onlook, follow its current access and codebase instructions. The artwork accompanying this guide is an upstream Onlook toolbar detail, not a screenshot of a Dyad-generated result.

What privacy and release checks come next?

A local editor can still send prompts and code context to a remote model. Read the selected provider's data terms, retention policy and account settings before submitting client material. Do not paste secrets into a brief. Free model tiers can have different data-use terms from paid services; the editor being installed locally does not determine those terms. Verify the endpoint and model when using a local connection.

Before publishing, replace fake interactions with reviewed application behavior, validate inputs, check authorization at the server boundary, verify dependency licenses and remove sample secrets. Inspect the deployed version separately from the local preview. Keep a rollback copy. A successful first draft is a useful design artifact, while production readiness needs its own code, accessibility, security and operational review.

What should I do if the draft or preview fails?

Separate setup, model and application failures. If the app cannot start, check Dyad's Node.js help and the actual diagnostic. If a model request fails, inspect the provider, key, quota and rate-limit message before repeatedly retrying. For a broken preview, save the error text and ask for the smallest relevant correction; do not grant access to additional services merely to make an error disappear.

If a conversation repeats the same unsuccessful edits, keep the current files and try a fresh chat with the intended behavior, the exact error and a narrow change request. A new chat still operates on the same application. Record the model and application version when reporting a problem. Do not claim a working deployment until you have verified the complete user task on the deployed site.