Describe the problem, not the screens
The most common mistake in a brief is designing the solution in it: a list of pages and buttons. It feels thorough, but it hides the most useful information, which is what is going wrong today and who it is going wrong for. A good agency will design better screens from a clear problem than from someone else's sketches.
What to put in a brief
- What the business does, in two sentences. Plainly, as you would tell a friend.
- What happens today. The current process, step by step, including the spreadsheets, the inbox and the person who knows how it all fits together.
- What goes wrong. Where time is lost, where customers drop out, where mistakes creep in. Examples help more than adjectives.
- Who uses it. Customers, staff, drivers, partners. What device they are on, and where they are when they use it.
- The rules. Capacity, timing, pricing logic, who is allowed to do what, the exceptions. This is where your business is different, so it is the most valuable part of the brief.
- What it connects to. Payment provider, accounting, email, existing data, any feeds you rely on.
- What must be true on launch day. The few things without which it is not worth launching. Keep this list short.
- What success looks like. Fewer hours on admin, fewer failed payments, more sign-ups from a particular place. Something you could check six months later.
- Constraints. A date that matters, a budget range if you have one, systems you cannot change.
What to leave out
- A full specification before anything has been tried. It will be wrong in places, and everyone will be bound to it.
- A technology choice, unless you have a reason. If you need to stay compatible with something, say so. Otherwise let the agency propose and explain.
- Every idea you have ever had. Put the nice-to-haves in a separate list. They are useful for planning later releases, and dangerous in a first quote.
Questions a good agency should ask you back
- Can we see the process happen, or talk to the people who do it?
- What is the riskiest part, and can we prove it works first?
- Which existing data has to come across, and what condition is it in?
- Who will look after this once it is live?
- What is the smallest first release that would be genuinely useful?
If you get a fixed quote for a complex platform without any of these questions, be careful. Either the agency has made assumptions it has not told you about, or it plans to discover the job at your expense.
What you should get back
A written note that shows the agency understood the problem, a proposal for what to build first and what to leave until later, the risks they see, how they will look after it, and a price for the first release. We quote per project, and we will tell you if we think part of the job is better bought than built.
Ready to send yours? Start here. A few lines is plenty to begin with; we will ask for the rest.