At the start of a project we often hear: “I’m not sure how to describe it exactly.” That’s fine. A brief doesn’t have to be written by a programmer and doesn’t have to be technical. Its job is to help developers understand your business so they can propose a solution that makes sense. Here is an approach that works well for us.
Start with the problem, not the features
Instead of a list of buttons and screens, describe what is bothering you today. For example: “We copy orders from e-mails into a spreadsheet by hand and some of them get lost.” A sentence like that tells a developer far more than “we want an order form”. It often turns out that the best solution looks different from what you originally expected.
Describe who will use the app
A customer on a phone, a sales rep in the field and an accountant at a desk have completely different needs. List all user groups and what each of them needs to do. An estimate of how often they will use the app and on which devices helps too.
Write down the main scenarios
A scenario is a short story: who does what and why. For example:
A customer picks a time slot and pays for the booking online.
The receptionist sees all bookings for the week and can move an appointment.
Every Monday the owner receives a summary of last week’s sales.
Five to ten scenarios like these are usually enough to make it clear what the app should do.
Decide what is essential and what would be nice to have
Split your requirements into three groups: what the app makes no sense without, what you will add in the next version and what is just an idea for the future. The first version should contain only the first group. You will reach users sooner and can steer further development by real feedback rather than guesses.
Don’t forget about integrations
Write down what the app needs to work with: accounting software, an e-shop, a payment gateway, a warehouse or the spreadsheets you use today. Integrations with other systems are the most common source of surprises, so it is good to know about them from the start.
Add examples and materials
A screenshot of an app you like, a sample invoice, a data export or a photo of a paper form. Every piece like this saves hours of back-and-forth. They don’t have to be perfect, they just need to show how things work today.
Define what success looks like
What should change after launch? Less manual work, fewer errors, faster order processing, more enquiries from the website. When you name the goal up front, you can keep coming back to it during development and decide which features take priority.
We’ll fine-tune the rest together
A brief is a starting point, not a contract set in stone. In the first consultation we will go through the scenarios with you, add anything that was missed and propose a technical solution and a step-by-step plan. If you don’t have a brief yet, that’s fine. Send us a few lines about what you are planning and we will start from there.