How to Write a UI Design Requirements Confirmation

“Design an admin system with approximately 30 screens” sounds specific. Once work begins, mobile adaptation, five roles, imports and exports, exception states, and a design system may appear. Neither party was dishonest; they simply never agreed on what “one screen” includes.

A requirements confirmation should serve as the scope appendix to a contract or quote. It does not need every business detail found in a PRD, but it must define objectives, boundaries, deliverables, responsibilities, and change handling well enough to execute.

01 Part One: Define Project Objectives, Not a Vague Vision

The objective explains why the design project exists, whom it serves, and which problem comes first. Write “Redesign the core quote-creation workflow for sales representatives to reduce duplicate entry and errors,” not “Improve user experience and build a world-class product.”

Also define how improvement will be measured and which problems are outside the current release. Explicit exclusions prevent scope from expanding indefinitely during discussion.

02 Part Two: List Roles, Platforms, and Usage Environments

One product may serve administrators, operators, reviewers, visitors, and customers, each with different screens and permissions. Specify Web, mobile Web, APP, tablet, or large display, plus any required browsers and devices.

If every permission cannot yet be defined, at least mark open questions and their owners. Do not assume the designer will infer them independently.

03 Part Three: Connect the Screen Inventory to Features and States

Screen names are only a directory. For each item, record primary features, roles, key states, whether it is new, whether existing components apply, and which platforms are delivered. Repeated templates can be counted by type, while complex screens need separate notes.

Charging for every modal, drawer, empty state, and error state as a separate “screen” may not be appropriate, but these states must be in scope. Otherwise, the static screen count appears unchanged while the actual work keeps growing.

04 Part Four: Define Deliverables Down to Files and States

Specify whether the scope includes information architecture, flows, wireframes, UI, a component library, responsive design, motion notes, development specifications, design QA, and testing. Also define which Figma team receives editable source files and how fonts, images, and icons are handled.

If the engagement covers UI only, do not let the client assume that PRDs, user research, and frontend code are included. If it includes a design system, specify whether that means foundational components or a complete business system.

• Final screens and key states;
• Scope of desktop, mobile, or other platform adaptations;
• Editable Figma files and components;
• Prototypes, flows, and interaction documentation;
• Font, image, icon, and asset inventory;
• Number of development-support, design QA, and acceptance rounds;
• Excluded research, copywriting, development, and operations work.

05 Part Five: Define What Counts as One Revision Round

One revision round should mean one consolidated client response to one stage. Before direction approval, structure and style can be discussed. A request to replace the entire direction after approval is a scope change, not an ordinary revision.

Also document feedback deadlines, handling of delays, decision-makers, and how conflicting opinions are resolved. The number of revisions alone cannot solve fragmented decision-making.

06 Part Six: Assign Ownership of Materials and Dependencies

Brand assets, real copy, product rules, APIs, sample data, legal text, and device information can all affect design. The confirmation should state the provider, due date, and handling rule for missing inputs.

A complex table designed with placeholder data can break when real long text and exception data arrive. Provide at least one realistic sample dataset.

07 Part Seven: Start the Schedule When Conditions Are Met, Not Only on a Date

Projects usually begin after the deposit is received, the contract is effective, and critical materials are complete. Agree in advance on schedule extensions caused by delayed feedback, added scope, third-party dependencies, or project pauses.

Milestones such as wireframe approval, visual-direction approval, complete UI, and design QA are more controllable than one final delivery date.

08 Part Eight: Close the Loop Between Acceptance and Change

Acceptance should follow the screens, states, deliverables, and platform scope in the confirmation—not only “client satisfaction.” When something is missing, first determine whether it was omitted from the original scope or is a new requirement, then decide whether to correct it or initiate a change.

Record the content, reason, impact, cost, schedule, and approver for every change. A one-page table is sufficient for a small project; the point is to preserve a shared version.

1. Submit the change and explain the business reason;

2. The design team assesses the effect on screens, components, development, and schedule;

3. Both parties approve cost and new milestones;

4. Update the requirements confirmation or add a change order;

5. Continue execution and acceptance under the new scope.

09 Allow “To Be Confirmed,” but Give It a Deadline

An early-stage project cannot define every rule at once. Mark items as approved, to be confirmed, assumed, or excluded, then assign an owner, deadline, and schedule impact to each open item.

If an English launch has not been decided, for example, the team can complete the Chinese structure first but require a decision before visual expansion. If the deadline passes, continue with the Chinese-only scope and treat later additions as changes.

This is more honest than pretending every detail is known and more actionable than saying “subject to final requirements.”

Frequently Asked Questions

How Is a Requirements Confirmation Different from a Contract?

The contract defines overall rights and obligations. The requirements confirmation defines project scope, screens, features, deliverables, and acceptance in detail and can serve as a contract appendix.

Can We Sign Before the Screen Count Is Final?

Yes. Contract for discovery or wireframing first, then approve full design after scope becomes clear. Avoid using one vague fixed price for unknown work.

Are More Revision Rounds Always Better?

No. Decision ownership, stage approval, and feedback quality matter more. Unlimited revisions often conceal unclear direction and scope.

What If Requirements Change Mid-project?

Use change control to assess effects on design, development, cost, and schedule, then update the shared scope after approval.

Can WeChat Approval Replace a Signature?

Consult a qualified professional regarding legal enforceability. For project management, preserve a traceable record that both parties clearly approved.