Before you build: five decisions that make a better brief.
You do not need a technical specification to start a conversation. You do need a clear view of the problem.
1. Start with the task, not the feature
Describe what someone needs to accomplish. “Our customers need to book and change appointments without calling us” is more useful than “we need an app.” A task gives the design and development team something to evaluate.
2. Decide who the first release is for
A product for everyone is difficult to prioritize. Name the first audience, the context in which they will use it, and the most important task. Later audiences can belong in a separate release.
3. Know what needs to connect
List existing systems, data sources, and account owners. An integration may depend on an API, a vendor agreement, or access that needs time to arrange. Find those dependencies before promising a launch date.
4. Separate constraints from preferences
A trade-show date may be fixed. A particular animation probably is not. Mark the requirements that cannot move and the decisions where the team has room to recommend a better approach.
5. Plan for the day after launch
A live product needs someone responsible for content, access, support, and maintenance. Include those responsibilities in the brief so the handoff becomes part of the project.