A brief is the text you give a developer or agency to explain what you are looking for. You need no technical knowledge for it. Describe your problem and your work, because you know more about those than anyone, and leave the solution to the people who build it. One or two pages in plain language is enough.
I ask most of the questions below myself when I sit down with a founder. If you already have them on paper, that first conversation can go straight to the details.
What do you need, and why?
Say it in your own words, in one or two sentences. Then write down why. A tool meant to save your team time looks different from an app meant to bring in new customers, even if the features seem alike at first sight.
How do you do it now?
Describe how the work runs today, step by step. Manually? In Excel? By email and phone? Write down the exceptions as well, and the tricks nobody has ever written down, such as the customer who always gets a separate invoice. Add why you want to move away from it.
Send what you have: the Excel file, a screenshot, a photo of the paper form. Take out the names and other details of real customers first, or replace them with made-up examples. If the idea is sensitive, ask for an NDA first, an agreement in which someone promises to keep your information secret. I sign them gladly.
Which words do you use?
Make a short list of the words that mean something specific in your business, with one sentence of explanation per word. Ordinary words can go on it too. Is a “customer” the shop that orders or the person who buys in the shop? Differences like that otherwise only surface once something has already been built.
When is it a success?
Write down what should be different if it works. It can be simple: fewer phone calls, fewer errors in your admin, customers using the app without your help. Note too what can be cut and what is non-negotiable. Those two lists help later when you choose what goes in a first version.
Who uses it, and how?
Name the people who will use it: your customers, your team, a driver on the road, you at the counter. Then go through the steps for each person. If you press this, this pops up. You do not have to draw anything, though a sheet of paper is of course fine. Think too about the moments when it goes wrong: what happens if someone makes a mistake, or if there is no signal?
Those steps work better than a list of features. “Managing appointments” can mean something different to you than to the person building it, and writing out the steps brings that difference to the surface.
What else to mention
Name the software you already use, such as your till, your accounting or your calendar, even if you do not know whether it matters. A connection can save a lot of double work, and the developer can check straight away whether it is possible.
If there is a real date, such as a trade fair, an opening or the start of a season, mention it, with the reason. If there is none, say that too. You can be open about money. If you have a limit in mind, write it down, and “I have no idea what this costs” is also a good answer. With me that conversation starts with what “a lot of money” means to you. What makes an app expensive or cheap? explains what sets the price.
What you can leave open
You do not have to choose a programming language or a database. Whether it becomes an app, a web app or a website can stay open too: that comes up in the conversation, and this article helps with it. Just write “I don’t know” if you do not know something. That tells a developer more than a guess, because they may take a guess as fact.
If you do have a firm preference, for example because your team only works on iPhones, write it down, with the reason.
An example
Say you have a hair salon with three hairdressers. Your brief could look like this:
What we need: customers should be able to book an appointment online themselves.
Why: the phone rings while we are cutting hair. We do not always answer, and then the customer sometimes rings another salon.
How it works now: appointments are in a paper diary at the till. Each hairdresser has their own column. Regular customers sometimes text their hairdresser’s mobile, and we copy that over.
Our words: a “treatment” is a cut, a colour or a combination. A colour takes longer, and while the colour is developing a hairdresser can cut someone else’s hair.
When it is a success: fewer phone calls during work, and no more double bookings.
What can wait: gift vouchers and paying in advance.
What is non-negotiable: each hairdresser sets their own hours.
The customer’s route: I open the page on my phone, choose a treatment and a hairdresser, see the free slots, choose one and get a confirmation. The hairdresser sees the appointment straight away in the diary.
What we already use: a till system, and Google Calendar on one hairdresser’s phone.
What we do not know: whether this should be an app, and what it would cost.
A developer gets a question for the first conversation straight out of this: how does an online diary deal with a hairdresser who cuts someone else’s hair while a colour develops?
Read next
What's your idea?
Tell me what you're trying to build. I try to reply within one working day.