Bespoke systems
What makes a useful brief for bespoke software?
A list of screens tells a developer what to draw. A useful brief tells them what the business must be able to do.
Published 25 September 2026
A team asks for a case dashboard. Most cases move directly to completion; some pause when two reviewers disagree.
The brief must say who resolves the disagreement, what evidence they see and how the final decision is recorded. A dashboard sketch alone cannot answer that.
Bring cases people recognise
Describe the trigger, the people involved, the information they need and the point at which work is complete. Include an ordinary case, a difficult exception and a recent mistake. These expose more design requirements than a long feature wishlist.
List the existing systems and identify the source of each important fact. Say who can see, correct and approve it. Access and correction are part of the product, not details for the final development sprint.
Separate constraints from habits
A statutory record or safety control may be non-negotiable. A familiar screen layout may not be. Tell the designer which is which and where you need them to challenge the request.
Define success as a change someone can observe: a case no longer disappears at hand-off, an approval can be audited, or staff stop maintaining a duplicate spreadsheet. A count of shipped features is not a business result.