What does a designer need from a PRD?

Five things: the problem and who has it, the user stories or jobs in priority order, testable acceptance criteria, the known constraints (data, platform, permissions, legal), and an explicit out-of-scope list. With those, a designer can build the screen list and the states without guessing. Our complete PRD guide covers every section of the document.

Do designers write PRDs?

Usually the product manager owns the PRD, but designers should co-write at least one section: the design requirements, which covers flows, the screen list, states, accessibility targets and UI acceptance criteria. On small teams and at startups without a PM, the designer often writes the whole thing.

What goes in the design requirements section of a PRD?

The user flow or flows, a named screen list with one line of purpose per screen, the states each screen must handle (empty, loading, error, partial, success), accessibility and responsive targets, content and microcopy rules, and links to the prototype and design system. Keep it to a page; detail belongs in the design file.

How do you turn a PRD into UI designs?

Extract the user stories and acceptance criteria, map them into a user flow, turn the flow into a named screen list, add the states each screen needs, then wireframe before moving to high fidelity. AI tools shorten the middle steps: in UXMagic you can design from a document and approve a screen plan before any screen is generated.

What are UI acceptance criteria?

They are pass or fail statements about what the interface must do, usually written as Given, When, Then. For example: given a user with no invoices, when they open the invoice list, then they see an empty state with a Create invoice button. Good UI criteria describe behaviour and states, not colours or pixel values.

What is the difference between a PRD and a design brief?

A PRD defines what the product must do and why, for the whole team. A design brief defines the design problem, audience, tone and constraints for the design team. Many teams fold the brief into the PRD as its design requirements section so there is one source of truth.

Can AI generate designs from a PRD?

Yes. UXMagic reads an uploaded PRD or brief, proposes a screen plan you can edit, and then designs the screens on one shared theme. Reading the document is free; only the screens designed from it use credits. Its AI PRD generator can also draft the PRD and matching screens together if you are starting from notes.

Why do PRD-to-design handoffs fail?

Mostly because of missing states and vague language. Requirements like make it simple cannot be tested, and edge cases such as errors, permissions and empty data are left for engineering to discover. Writing UI acceptance criteria and a state matrix before high-fidelity design removes most of that rework.

PRD for Designers: Read, Write and Design From a PRD

TL;DR: A PRD tells the team what to build and why; a designer's job is to turn it into flows, screens and states that engineering can build without guessing. Read the PRD for stories, constraints and acceptance criteria, co-write a one-page design requirements section, add UI acceptance criteria for every state, and keep the PRD and the design linked through design handoff. If you want a head start, UXMagic can design from a document: upload the PRD, approve the screen plan, and get a consistent multi-screen flow. For the definition and a full template, see the PRD guide linked below.

A product requirements document (PRD) is the shared description of what a product or feature must do, for whom, and why, written before the build starts. That is the whole definition you need here; our PRD guide and template covers the sections, the history and examples in depth.

This guide is about the other side of the document. It is for designers who receive PRDs, product designers who are asked to co-write them, and founders who do both jobs at once. We will cover how to read a PRD for the things that actually shape the interface, how to write the design requirements section, how to express UI acceptance criteria, how to plan edge, empty and error states, how to hand off without the spec and the screens drifting apart, and where AI now removes the most tedious part of the job.

We are the UXMagic team. We build an AI design tool that turns requirements into screens, so we have a view on this; where we mention our own product we stick to what it documents in its help center.

What a designer needs from a PRD

Most PRDs are written for alignment: they persuade stakeholders that a problem is worth solving and record what was agreed. Designers need something narrower. You need the parts of the document that decide structure, and you can safely skim the rest.

PRD section	What the designer extracts	Design output it drives
Problem and audience	Who the user is, their context, their current workaround	Persona notes, tone, entry points
Goals and success metrics	The one behaviour the design must make easy	Primary action and hierarchy per screen
User stories / jobs	Tasks in priority order	User flow and screen list
Acceptance criteria	Testable rules and edge conditions	States per screen, validation, copy
Constraints	Data, platform, permissions, legal, performance	Layout limits, disabled states, fallbacks
Out of scope	What will not ship in this version	What you deliberately do not design
Open questions	Decisions not yet made	Variants to test, flagged areas

If the PRD you received has no audience section, lean on a user persona template to fill the gap before you design. If it has no success metric, ask for one: without it you cannot decide what the primary button on each screen should be. And if the out-of-scope list is missing, that is how feature creep enters through the design file, one "while we're here" screen at a time.

How to read a PRD as a designer

Read it twice. The first pass is for understanding the problem. The second pass is an interrogation, pen in hand, looking for three kinds of gap.

Vague requirements

"Simple onboarding", "a clean dashboard" and "make it intuitive" are wishes, not requirements. Nobody can test them, so everyone interprets them differently and the design gets blamed later. Rewrite each one into something checkable and send it back to the PM:

"Simple onboarding" becomes "a new user reaches their first project in three steps or fewer, with no required fields beyond email and password."
"Fast search" becomes "results appear as the user types, with a loading indicator after 300ms and an empty state when nothing matches."
"Accessible" becomes "meets WCAG 2.2 AA contrast and every action is reachable by keyboard."

Our accessibility heuristics checklist is a good source of concrete wording, and if you generate UI with AI, the guide to prompting for WCAG 2.2 accessible UI shows how to carry those targets into the prompt.

Missing states

PRDs describe the happy path because that is how people explain features. Designers get paid for the other paths. For every user story, ask: what does this look like with no data, too much data, a slow network, a failed request, a user without permission, and a user halfway through? Most of the rework in a typical sprint comes from states nobody wrote down.

Hidden feasibility constraints

Ask engineering early what the backend can and cannot do: whether search is server-side, whether a list is paginated, what the API returns on error, which fields are optional, and whether anything is real-time. A designer who learns these after high fidelity designs the screen twice. The human-in-the-loop design workflow we describe elsewhere makes the same point about AI: the decisions that matter are made before anything is drawn.

Turning a PRD into flows and screens

Once the gaps are closed, translation is a sequence. Skipping steps is what produces beautiful screens that do not connect.

List the jobs in priority order

Pull every user story into a list and rank it using the PRD's own priorities. If there are none, a quick RICE score is enough to separate must-have from nice-to-have. Only the top group gets designed in the first pass.

Map the user flow

Draw the path a user takes through each job, including decision points and exits. A user flow diagram is the right artefact here, not a screen. If you need the emotional layer too (where users hesitate, where they drop off), extend it into a customer journey map with wireflows.

Turn the flow into a named screen list

Give every screen a name and one line of purpose: "Invoice list: find and open an invoice, or create a new one." This list is the most useful thing a designer can add to a PRD, because it makes scope visible. If it passes fifteen screens for a first release, you are probably designing two products; our MVP design guide explains how to cut it back.

Add the states to each screen

For each screen on the list, write down which of the states in the matrix further down it needs. This is where acceptance criteria turn into design work.

Wireframe, then raise fidelity

Settle structure in greyscale before you touch colour. Our comparison of low vs high fidelity covers when to switch, and the roundup of the best wireframing tools covers what to use. An AI wireframe generator can produce the whole flow in low fidelity from the screen list.

A checkout flow in UXMagic's wireframe mode: greyscale Shipping and Payment screens on the canvas with the chat panel open

Prototype the riskiest path

Link the screens into a clickable prototype and test the one journey the success metric depends on. If you are unsure what level of prototype to build, our explainer on what a prototype is in UX design and the guide to wireframes vs mockups vs prototypes help you pick.

Turn your PRD into a screen plan

Upload a PRD or brief to UXMagic, review the proposed screen list, and generate the whole flow on one shared theme.

Try UXMagic free

How to write the design requirements section

Designers are increasingly asked to own one section of the PRD. Keep it to a page and link out to the design file for detail. A template that works for most features:

Flows covered. One line per flow, with a link to the flow diagram.
Screen list. Named screens with one line of purpose each, marked new or changed.
States. For each screen, which of empty, loading, error, partial, success and no-permission apply.
UI acceptance criteria. The testable rules, written as Given, When, Then (next section).
Content and microcopy. Terminology, tone, and any strings legal or support must approve. Our UX microcopy framework is a useful reference.
Accessibility and responsive targets. Contrast level, keyboard support, breakpoints and which devices are in scope.
Design system. Which components are reused and which are new. If you do not have a system yet, the guide to building a design system from scratch covers the minimum.
Open design questions. Variants you plan to test and decisions waiting on research.
Links. Prototype, design file, and research.

Two habits make this section far more useful. First, name the screens in the PRD itself, not only in the design file: engineers and QA search the document, not your canvas. Second, write down what is deliberately not designed. "No bulk edit in v1" saves an argument in every review.

If you are the PM rather than the designer, the spec-driven design workflow for product managers shows how to write the whole document so it can feed design tools directly.

UI acceptance criteria that designers and QA can test

Acceptance criteria are how a PRD becomes checkable. Most are written for backend behaviour; designers should add the ones that describe the interface. The Given, When, Then format keeps them precise:

Given a user with no invoices, when they open the invoice list, then they see an empty state that explains what invoices are and shows a Create invoice button.
Given a slow connection, when the list is loading for more than 300ms, then a skeleton of the table is shown instead of a blank page.
Given a failed payment, when the user returns to checkout, then their entered details are kept and the error names the card field that failed.
Given a viewer-role user, when they open a project, then edit controls are hidden, not disabled, and a banner explains how to request access.

Weak UI criterion	Testable version
The form should be easy to use	Every field has a visible label; errors appear inline on blur
Show a nice empty state	Empty state has a one-line explanation and one primary action
Handle errors gracefully	Network errors show a retry action; the user's input is preserved
Work on mobile	All flows complete at 375px width without horizontal scroll

Criteria like these also make design review faster: instead of debating taste, reviewers check boxes. The form UX playbook has more field-level rules worth turning into criteria.

Edge, empty and error states: the state matrix

The simplest way to stop states falling through the cracks is a matrix: screens down the side, states across the top, and a tick or a note in every cell that applies.

Screen	Empty	Loading	Error	Partial	No permission	Success
Invoice list	First-use prompt	Table skeleton	Retry banner	Paginated	Read-only	n/a
Invoice detail	n/a	Field skeletons	Not found page	Missing line items	Hidden actions	Paid badge
Create invoice	Blank form	Save spinner	Inline field errors	Draft saved	Blocked	Toast plus redirect

Each filled cell is a screen variant someone has to design and someone has to build. Counting them is also the most honest way to estimate design effort from a PRD. For the empty cells specifically, our guide to empty states in UI design covers the patterns that turn a dead end into onboarding.

Blueprint of a standard empty state layout: illustration area, headline, short explanation and a primary action button

Three kinds of feature need extra rows:

Authentication and security. Adding two-factor login sounds like one screen. In practice it means setup, the code entry, a wrong code, too many attempts, lost device and recovery codes, and a settings toggle. If the PRD only says "users verify with SMS or an authenticator app", ask for the rest before you start.
Data-heavy screens. Dashboards need rules for no data, one data point, huge numbers and slow queries. Designing with realistic data rather than placeholder charts exposes these early; our dashboard UI design guide covers the patterns.
AI features. Output from a model varies, so the design needs states for low confidence, a refusal, a slow response, an undo, and a way to give feedback. The AI chat interface design patterns post lists the ones that stop users abandoning.

Handoff: keeping the PRD and the design in sync

Handoff fails for one main reason: the PRD and the design diverge during iteration and nobody notices until engineering builds from the stale one. A few rules prevent most of it.

One source of truth per question. Behaviour and scope live in the PRD; layout and states live in the design file. Each links to the other.
Change log in the PRD. When a review changes a requirement, the PM updates the PRD the same day and the designer updates the affected screens. Version history on both sides makes this auditable; UXMagic keeps versions and history for every screen.
Review in context. Share a clickable preview rather than static exports, and collect feedback on the screen itself. In UXMagic that means sharing a preview and using comments and feedback.
Hand off code, not only pictures. Engineers need spacing, tokens and component names. Our explainer on what a design handoff is breaks it into three layers, and the comparison of design handoff tools covers the options, including Figma Dev Mode alternatives.

Using AI to go from PRD to screens

The slowest part of the traditional workflow is the blank canvas between reading the PRD and seeing the first screen. That gap is where AI now helps most, as long as the tool designs a flow rather than a single pretty screen. We covered the general pattern in how to design UI with AI and why blank-canvas syndrome is mostly a sequencing problem; here is how it applies to a PRD.

Design from a document in UXMagic

UXMagic's design from a PRD or brief feature reads your requirements before it designs anything:

Open your project and upload the PRD to the project's documents area, or attach it in the prompt box.
Ask for what you want built, for example: "Read the PRD and design the screens it describes. Start with the plan."
The AI reads the document and uses it as the source of truth for screens, content and terminology, then proposes a screen plan: a named list of screens with a one-line purpose each.
Approve the plan, or edit it by renaming, reordering, adding or removing screens. Only then does it start designing. The flow mode and screen plans article explains why this checkpoint is the cheap place to fix mistakes.
Flow Mode designs the whole journey on one shared theme and navigation structure, and screens appear on the canvas as they finish.

UXMagic canvas with a generated landing page and the chat panel start options, including Upload document, Clone a Website, Image or Sketch to UI and Import from Figma

Three tips from the help center match the advice earlier in this guide. Name your screens in the document, because a PRD with an explicit screen list produces a far better plan than one that only describes behaviour. Point at the section you mean ("design the screens in section 4 only") rather than the whole document at once. And keep the document in the project, so later requests still have the original requirements.

On cost: listing and reading documents is free, and only the screens designed from them use credits. Proposing a plan costs 1 credit and each new screen costs 3, per how credits work, so fixing the plan before approving it is the biggest saving available. Plans and limits are on the pricing page.

If you want structure first, switch to wireframe mode for a greyscale pass, then ask for missing states in plain language ("add an empty state for the invoice list and a forgot-password screen") through chat editing. Colours and type come from themes and style guides, which you can seed with the AI style guide generator.

When there is no PRD yet

Designers at startups often get a Slack message instead of a document. UXMagic's AI PRD generator takes a plain-language description (the concept, user goals, requirements and constraints) and produces a structured PRD with user stories and acceptance criteria alongside the matching screens. When you change a requirement with a follow-up prompt, the related screens update with it, which is exactly the drift problem handoff usually suffers from. If you are comparing dedicated PRD writers, our ChatPRD review and the roundup of AI tools for product managers cover the alternatives.

Handing off what AI produced

Generated screens still need a designer's pass on hierarchy, copy, accessibility and the state matrix. When they are ready, export to Figma as editable layers for team review, or export code in HTML or React for engineering; the design to code generator page explains what comes out. Teams working in an IDE can pull screens into their coding agent through the UXMagic MCP server. If you are evaluating the wider category, see our list of AI design-to-code tools.

Where AI does not replace the designer

AI is good at the scaffolding: the screen list, the first layout, consistent components across a flow. It does not know which requirement is politically fragile, which edge case support gets tickets about, or whether the success metric is the right one. Those judgments are still the designer's job, and the argument in why AI is not replacing UX designers holds here. Treat generated screens as a draft to interrogate against the PRD, the same way you interrogated the PRD itself. For a wider view of where AI fits in the process, see AI in the UX design workflow and our guide to prompting for user flows, not screens.

A one-page checklist for your next PRD

Before you open a design tool:

The problem, audience and success metric are written down.
Every vague adjective has been rewritten into a testable rule.
User stories are ranked; the first-release set is agreed.
Out-of-scope is explicit.
Engineering has confirmed the data and API constraints.

Before handoff:

Every screen on the list has a name and purpose in the PRD.
The state matrix is filled and every cell is designed.
UI acceptance criteria exist for each state.
Accessibility and responsive targets are met and noted.
The PRD, prototype and design file link to each other, and the change log is current.

If you are validating an idea before any of this, start with how to validate a product idea and the plain-English guide to what an MVP is. If you would rather prototype the core flow straight away, the AI MVP builder and AI prototype generator start from a description, and our website and app templates give you a starting layout.