SERIES: AI-POWERED DEV WORKFLOW · POST 4 OF 10
Clients do not read BRDs. Some will tell you they did. What they actually did is open it, read the first paragraph, scroll to see how long it is, and close it. I have had clients sign off on a 15-page BRD, then show up at the design review and say “I didn’t know it was going to look like this.”
The problem is not the BRD. The problem is that a BRD is written for people who already understand software projects. Your client probably does not. They need a one-page plain-English summary, a design walkthrough, and a clear process for raising changes. That is what this post is about.
We are going to use Claude to: create a client-friendly project summary, generate a design review checklist, handle an incoming change request, and produce a sign-off document. All for ClientHub.
Step 1 — Create a Client-Friendly Project Summary
Before any design review or sign-off conversation, send the client a one-page summary they can actually read. No technical terms, no jargon, no FRD structure. Just: what we are building, what they are getting, what is not included, and what you need from them.
PROMPT 1 - Client-Friendly Project Summary
Read the BRD in docs/ClientHub-BRD-v1.md.
Rewrite it as a 1-page client-friendly project summary.
The audience is a non-technical client stakeholder.
Include:
- What we are building (1 short paragraph, plain English)
- What they are getting in Phase 1 (bullet list, 5-7 items max)
- What is explicitly not included (3-5 bullets)
- Proposed timeline (high level)
- What we need from them to proceed
No jargon. No technical terms. No passive voice.
Write it the way you would explain it in a 10-minute meeting.Here is the summary Claude produced for ClientHub. I changed three words and added the UAT timeline. That was it:
ClientHub — Project Summary for Client Review
What we are building
ClientHub is a secure web portal where your team and ours work on projects in one shared space. You log in to see project progress, review and approve deliverables, raise change requests, and view invoices — all without email attachments or status-update calls.
What you are getting in Phase 1
- Secure login for your team members (client accounts) and our team (PM and developers)
- A project dashboard showing all active projects and their current status
- Deliverable uploads with your ability to approve or request revisions
- A comment trail on every deliverable so feedback is documented
- Email notifications when something needs your attention
- Invoice viewing (invoices sent directly through the portal)
What is not included in Phase 1
- Mobile app (web browser only)
- Time tracking or resource scheduling
- Payment processing (invoices are view-only; payment handled separately)
- Third-party integrations (Slack, Jira, etc.)
Proposed timeline
- Phase 1 build: 8 weeks from sign-off
- Client UAT: 2 weeks
- Go-live: Week 11
What we need from you
- Sign-off on this summary and the attached full BRD
- Attend a 1-hour design walkthrough this week
- Nominate one person on your side as the primary approver for deliverables
Send this — not the BRD — as the pre-read before your design review. The client comes in understanding what they are approving. The conversation is completely different.
Step 2 — Generate a Design Review Checklist
Before you show the client any mockups or wireframes, run a quick internal check. Does every FRD feature have a screen? Are all user roles accounted for in the designs? Are error states there? Catching these before the client session saves you from a “what happens when I type the wrong password?” question that you cannot answer in the room.
PROMPT 2 - Design Review Checklist
Read docs/ClientHub-FRD-v1.md.
Generate a design review checklist I can use before showing
designs to a client. For each FRD feature, I want to confirm:
1. Is there a screen or UI element covering this feature?
2. Are all user roles shown (what PM sees vs Client vs Developer)?
3. Are error states and empty states designed?
4. Are validation messages visible?
5. Is the user flow complete (start to finish, not just happy path)?
Format it as a checklist I can go through before each design session.Design Review Checklist — ClientHub (Claude output, condensed)
- Login screen: shown for all roles. Error state for wrong credentials. Empty state if no password entered.
- Dashboard: PM view vs Client view are distinct. Empty state when no projects exist yet.
- Project creation: PM flow only. Confirmation screen after save.
- Deliverable upload: file type and size error states shown. Success state after upload.
- Deliverable approval: Client view with Approve / Reject buttons. Comment field shown. Validation if Reject submitted without comment. Developer view is read-only.
- Notifications: email template designs included.
- Invoice view: Client view only. “Paid” vs “Outstanding” states.
- Audit log: Admin view only. Confirm this screen is in designs.
Go through this before every design review. It takes five minutes and prevents the kind of design gaps that only get spotted when the developer tries to build them.
Step 3 — Handle a Change Request Without Losing Your Mind
You are in the design review. The client has seen the mockups. Then they say: “Can we add a page that shows all outstanding invoices with filters for status — paid, unpaid, overdue?”
This was not in the BRD. It was not in the FRD. It is a new feature, mid-review, delivered casually. And if you say “sure, no problem,” you have just agreed to scope that will cost you three days and nobody will remember you agreed to it for free.
Here is how I handle it with Claude.
Prompt A — Assess the Impact First
PROMPT A - Impact Assessment
The client has requested a new feature during the design review:
"A dashboard page showing all outstanding invoices with status
filters: Paid, Unpaid, Overdue."
This is not currently in the BRD or FRD.
Assess the impact:
1. Which existing FRD features does this touch or depend on?
2. What new UI and backend work does this require?
3. Is this a minor addition or a significant scope change?
4. What questions should I ask the client before committing?Claude Impact Assessment (summary)
- Touches: F6 Invoicing (read/filter), F7 Dashboard (new sub-page)
- New work: invoice list API endpoint with filter params, new frontend page with table and filter UI, pagination if list is long
- Scope: Moderate — 2–3 days of backend and frontend work
- Questions to ask before committing: Should overdue invoices be calculated automatically or manually set? Does the client need to export this list (CSV)? Is this for all invoices across all projects, or per-project?
Now you go back to the client with those questions instead of a vague “we’ll look into it.” That is a better conversation. Once the answers are in, update the docs:
Prompt B — Update the BRD
PROMPT B - Update BRD with New Requirement
The client has confirmed the following for the invoice dashboard:
- Overdue = any unpaid invoice more than 30 days past the due date
- No CSV export in Phase 1
- Shows invoices across all projects (global view)
Add this as a new requirement in docs/ClientHub-BRD-v1.md.
Place it under the Invoicing section.
Keep the same style and format as existing requirements.
Version the document to v1.1 and note the change at the top.Prompt C — Add the FRD Spec
PROMPT C - Write FRD Entry for New Feature
Now write a full FRD entry for the Invoice Status Dashboard.
Confirmed scope:
- Global view: all invoices across all projects for this agency
- Filter by status: All / Paid / Unpaid / Overdue
- Overdue = unpaid + due date more than 30 days ago
- No CSV export in Phase 1
- Client role sees this page; PM and Admin also see it
- Developer role does not see invoices
Use the standard FRD structure. Add it to docs/ClientHub-FRD-v1.md
and update the table of contents.Three prompts. Both documents updated. The change is specced, scoped, and documented before the design review is even over. No sticky notes, no “I’ll email you the details,” no forgotten requirements.
Step 4 — Get a Formal Sign-Off
Once the design review is done and all change requests are logged, get it in writing. Not because clients are untrustworthy — but because memories fade and details blur. A signed document protects everyone.
PROMPT 3 - Sign-Off Document
Generate a formal project sign-off document for ClientHub.
Include:
- Approved features list (pull from the current BRD)
- Out-of-scope items (explicitly confirmed)
- Change request process (brief — 2-3 sentences)
- Signature lines for client and PM
Keep it to one page. Plain language. No legal jargon.
This is a working agreement, not a contract.Here is the sign-off template Claude produced for ClientHub:
PROJECT SIGN-OFF DOCUMENT
Project Name: ClientHub Client Portal
Date: _______________________
Approved Features (Phase 1)
- User authentication with role-based access (PM, Client, Developer, Admin)
- Project creation and management
- Deliverable upload, versioning, approval and rejection workflow
- Email notifications for key project events
- Project dashboard with status overview
- Invoice generation and client-facing invoice view
- Compliance audit logging for all user actions
Out of Scope (confirmed)
- Mobile application
- Payment processing
- Time tracking / resource scheduling
- Third-party API integrations
Change Request Process
Any changes to approved features or scope after sign-off must be submitted as a formal Change Request. Each request will be assessed for timeline and budget impact before acceptance. Changes are not automatically included.
Client Signature: _______________________ Date: ___________
PM Signature: _______________________ Date: ___________
Send this as a PDF after the design review. Most clients will sign it without pushback — it is short, clear, and does not feel like a legal trap. And once it is signed, any new request that falls outside it is a formal change request with timeline and budget implications. That conversation is much easier to have when the boundary is already agreed in writing.
What Is Next
Documents are signed. Requirements are locked. Now the team needs access to everything — in one place, structured, searchable, and not buried in someone’s Google Drive.
Post 5 covers how to use Claude to auto-generate Confluence pages directly from your BRD and FRD. The whole project knowledge base, structured and ready for the team, in about 20 minutes.
Next in this series: Post 5 — Auto-Generate Confluence Pages from Your BRD and Functional Docs
Got questions? Drop them in the comments — I read every one.