Project Readiness Checklist
You do not need a polished brief to begin. But a few pieces of context can make the first conversation dramatically more useful.
Useful inputs before the first conversation.
What should be different afterward?
Describe the outcome in practical terms. A rough target is enough to start.
What exists now?
Share the current site, documents, workflow, research, drafts, screenshots or other material that already exists.
What is getting in the way?
Name the bottleneck, confusion, delay, missing capability or quality issue that prompted the project.
Who needs the result?
Identify the people who will use, read, approve, maintain or rely on the finished work.
What cannot be ignored?
List deadlines, platform limits, compliance needs, technical restrictions, budgets or dependencies that may shape the approach.
What systems are involved?
Note any websites, hosting, files, software, shared drives or other platforms that may need access or coordination.
Who approves direction?
Knowing who has final approval helps prevent circular review and conflicting feedback.
What matters most?
If speed, depth, polish, preservation of existing work or another factor matters most, say so early.
How will you know it worked?
Define the practical result: a clearer site, better workflow, usable research system, launch-ready asset or another concrete improvement.
Do not overprepare.
You do not need perfect language, a giant requirements document or every answer in advance. A useful first message can be as simple as: what exists, what is wrong, what you want instead, and anything that makes the project unusually constrained.
