The 10-step preparation checklist
A useful project brief is not dozens of screen drawings; it is a problem definition that enables decisions. With these 10 outputs ready, a software team can discuss scope, risk and delivery order in the first meeting.
| Step | Output | Why it matters |
|---|---|---|
| 1 | One-sentence problem | Fixes the need rather than the solution |
| 2 | Primary user | Prevents designing for everyone |
| 3 | Single primary flow | Defines the working core of the MVP |
| 4 | Out-of-scope list | Stops silent scope growth |
| 5 | User roles | Shapes permissions and the data model |
| 6 | Integration inventory | Makes external dependencies visible |
| 7 | Content and data source | Clarifies who supplies what |
| 8 | Success criterion | States what launch will validate |
| 9 | Account ownership | Keeps stores and infrastructure with the client |
| 10 | Acceptance criteria | Defines when delivery is complete |
Define the problem without a feature list
The problem sentence should identify the user, current behaviour and obstacle. “We want a mobile app” is not scope; “the field team cannot complete a service record before returning to the office” produces design and engineering decisions. Features come after that sentence.
A good problem statement does not prescribe the solution; it states which user cannot complete which job and why.
Write the primary flow and exclusions together
For an MVP, the primary flow is one chain from opening the app to seeing a verifiable outcome. In DrapeAI that chain was upload a photo, choose a garment and see the result. Social sharing, advanced profiles and secondary filters were unnecessary for the first validation.
- Describe the primary flow in no more than 5-7 user steps.
- For every extra feature, ask how it contributes to the tested assumption.
- Do not lose excluded ideas; keep them in a separate out-of-scope list.
- Do not automatically treat an admin panel, multiple languages and advanced reporting as mandatory.
Roles and integrations drive scope before screen count
User roles and external integrations are the two fastest scope multipliers in a mobile app. If an end user, administrator, field worker and business owner see the same record differently, you need a permission matrix. If the app uses payments, maps, ERP, identity or an AI service, document accounts, quotas and failure paths upfront.
| Integration question | Expected answer |
|---|---|
| Who owns the service? | A client account or explicit responsibility |
| Is there a test environment? | Sandbox access and sample data |
| What happens when a request fails? | A user-visible fallback path |
| Is there a quota or usage cost? | A monthly limit and warning threshold |
| Which data is shared? | Explicit fields and a retention decision |
Separate success from acceptance criteria
A success criterion evaluates the product assumption; an acceptance criterion evaluates delivery. “Test users complete the primary flow without help” is a success criterion. “The form must not lose data offline and must submit after reconnection” is a testable acceptance criterion.
Who should own store and infrastructure accounts?
Apple Developer, Google Play, domain, analytics and cloud accounts should be opened in the client's legal or individual name. The software team receives role-based access; passwords and ownership are not transferred. This keeps control of publishing and data with the client even when teams change.