“Build a corporate website” or “design an app” may sound clear, but execution quickly raises questions about page counts, user roles, languages, admin systems, motion, and integrations.
The less precise the scope, the harder proposals are to compare—and the easier it is to confuse normal clarification with a new requirement during the project.
01 Replace a Single Page Count with a Page and Template Matrix
List each page name, template type, desktop and mobile requirements, language, content source, and whether it needs a distinct design. For dynamic detail pages, separate the template count from the volume of data.
Similar pages should not be assumed to reuse everything, nor should they be priced twice without justification.
02 Define Inputs, Rules, and Outcomes for Every Feature
Forms, search, memberships, payments, and admin tools are more than feature names. Specify users, fields, permissions, states, notifications, failure handling, and where the data goes.
Also list any third-party service accounts and fees.
03 Include Roles, States, and Edge Cases in Scope
What each role can view, edit, and approve can significantly affect design and development. Agree on loading, empty, error, disabled, timeout, and insufficient-permission states.
Estimating only the ideal happy path leads to under-scoping.
04 Assign Content and Asset Ownership by Person and Date
State who provides copy, images, translations, legal text, and product data, and who enters, reviews, and gives final approval. Define how content delays affect the schedule.
Placeholder content is not the same as final delivery.
05 Clarify Deliverables and Account Ownership
Cover design source files, code, the CMS, deployment, documentation, font and asset licenses, domains, servers, and third-party accounts.
The timing of source-file delivery and its relationship to payment milestones should be explicit.
06 Allow Reasonable Adjustments Through Change Control
Record why a new item is needed, what it affects, its cost, and its schedule impact before an authorized decision-maker approves execution. Small adjustments can use an agreed contingency instead of requiring a major contract amendment every time.
Maintain one authoritative version of the change log.
Six Tables for Confirming Scope
Table | Minimum Content |
|---|---|
Page matrix | Pages, templates, devices, languages |
Feature list | Rules, roles, states, data |
Content list | Owner, format, deadline |
Integration list | Systems, APIs, accounts, fees |
Deliverables list | Source files, code, documentation, deployment |
Change log | Requirement, impact, approval, version |
Frequently Asked Questions
What is the difference between a requirements specification and a contract?
The requirements specification describes the scope in detail, while the contract defines rights and obligations. They should usually reference each other and take effect together.
How should page count be calculated?
Distinguish unique templates, repeated data pages, interface states, and device layouts instead of counting URLs alone.
Should small revisions incur additional fees?
You can define included revision rounds and a reasonable contingency. Reassess only changes in direction or additions to the agreed scope.
What happens if client materials are delayed?
Agree on schedule extensions, resource reallocation, and conditions for restarting work.
Can the project still be optimized after scope is locked?
Yes. Use the change-control process or a later iteration instead of allowing the scope to expand informally.
Service | View |
|---|---|
Related services | |
Related reading | View details |
Design work | |
Project inquiry |
Link copied
