The Requirements Template That Reduced Our Client Revisions by 60%

We Were Drowning in Revisions

A few years ago, the agency I worked with had a revision problem. Every project went through three, four, sometimes five rounds of client feedback before anything shipped. Timelines ballooned. Margins shrank. The team was frustrated because they kept rebuilding things that “weren’t what the client wanted.”

The problem wasn’t our design or development quality. It was that we started building before the client and the team had the same picture in their heads.

We rewrote our requirements template from scratch. Within two quarters, average revision rounds dropped from 4.2 to 1.7. Here’s the template and why each section matters.

The Template

Section 1: Project Goals (What Success Looks Like)

Most project briefs start with “build a website” or “create an app.” That’s a task description, not a goal. We start with outcomes.

What we write:

• “Increase online appointment bookings by 40% within 3 months of launch”
• “Reduce customer support calls about order status by half”

Why it works: When the client signs off on goals, every design and development decision has a filter. “Does this help us hit the goal?” If not, it’s a nice-to-have, not a must-have.

Section 2: User Stories (Who Does What)

We list every user type and what they need to accomplish. Not technical specs. Simple sentences.

Format: As a [user type], I need to [action] so that [outcome].

Examples:

• As a new patient, I need to book an appointment online so that I don’t have to call during office hours.
• As a clinic admin, I need to see all bookings for the week so that I can plan staffing.

We typically write 10 to 20 of these for a mid-sized project. The client reviews them and often says “you forgot about [user type].” That’s exactly the point. Better to discover that now than during QA.

Section 3: Acceptance Criteria (How We Test It)

For each major feature, we write testable statements.

Example for online booking:

• User can select a date from a calendar showing available slots
• User receives a confirmation email within 60 seconds of booking
• Admin can cancel a booking, which sends the patient a notification
• System prevents double-booking the same time slot

This section kills ambiguity. “Make the booking experience smooth” means nothing. “User can complete a booking in under 3 clicks” means something specific.

Section 4: Constraints (Timeline, Budget, Tech)

We list every constraint explicitly:

• Timeline: MVP launch by March 15, full feature set by May 1
• Budget: Fixed at £X, with £Y contingency for change requests
• Technical: Must integrate with existing Salesforce instance; hosting on AWS required by IT policy
• Regulatory: GDPR compliance required; accessibility to WCAG 2.1 AA

Constraints that aren’t written down get forgotten. Then they surface mid-project as surprises.

Section 5: Out of Scope (What We’re NOT Building)

This is the section that changed everything. We explicitly list features and work that are excluded from this engagement.

Examples:

• Mobile app (web responsive only for v1)
• Migration of historical data from the legacy system
• Ongoing SEO or content creation post-launch
• Multi-language support (English only for initial release)

Before we added this section, clients assumed things were included that we’d never discussed. “I thought the redesign included migrating all our old blog posts?” That single misunderstanding could add two weeks of unplanned work.

The out-of-scope section reduced revision rounds by roughly a third on its own. Not because it prevented feature requests, but because it set expectations before anyone started building.

How to Use This

You don’t need to copy this template exactly. The principle is what matters: write down what you’re building, why, how you’ll test it, what limits exist, and what’s excluded. Get the client to sign off on all five sections before design starts.

The 2 to 3 hours spent writing this document saves 20 to 30 hours of revisions later. Every time. We’ve run this template across 40+ client projects now, and the pattern holds.

Revisions aren’t a design problem or a client problem. They’re an alignment problem. Fix alignment upfront, and the rest of the project runs smoother than you’d expect.