We all love a good project no matter what hat we’re wearing. Client, user, developer, we all like projects to go smooth and be successful, but have you wondered what’s the first step of a good project? It’s the brief. Yes, the project brief, that document you send us before we start a collaboration is the most important of them all. Let’s see what makes a good project brief, how to write one, and why it is so important.
Common mistakes and misconceptions
You’ve got an idea! That is awesome. Let’s say your company wants to launch a new product and you need support from a software development partner to make it happen. How do you approach it? We often get clients telling us a complex idea, verbally, but when the project brief arrives, so much of what we think is crucial is left out and that’s easy to happen.
A poor brief can even make a software company reject your project. It’s the first document we get before we start a collaboration and it’s maybe the most important one. If the brief is not well written, it can indicate a lack of effort in the early stage of the project which can escalate into poor communication and even a project failure. There are also cases when the brief is dense but still doesn’t give us a clear picture. Some clients who focus mostly on describing their product requirements forget to tell us who their customer is. Others focus too much on the tech side but don’t tell us what their budget is.
Knowing the tech side is not even mandatory when your write a project brief, because that is mostly our job. What clients need to do is write down a description of the product they need while keeping in mind that we might not know anything about their business field, their company history, or even the size of the market they want to address. It’s like walking into a shoe store and asking for pair of red shoes without telling the size, the fabric, the occasion, or the price you’re willing to pay for it.
First, you need to know who you’re building it for.
Who will use this product? How can we make it appealing to them? Where can we find them and how much time do these people have on their hands? Knowing your use persona is always important, but especially important when you reach out to a software developing company. Your brief should offer a clear image of your user persona. We wouldn’t want to build an app that works only on iOS when your customers are mainly Android users. Also, it is important to know what type of users will access the product: users, admins or contributors for example. Check out this table providing an example of user permissions.
What do you need your product to do?
Things are cool when they’re useful and efficient so always make sure you tell us what you need your new product to do. Make a list of user requirements and check it twice to be sure you’re not leaving anything out. It’s better to overthink it than to leave too much of a developer’s imagination. We can optimize things, propose simpler solutions to achieve what you want, but we can never come up with something that was on your mind and you forgot to tell us. We’d need magic to do so.
What problem are we trying to fix?
You’ve told us what your product needs to do, but we know that products generally serve a higher purpose too. They don’t just work a certain way, but they fix an issue. When the client tells us what the large purpose of the product is, this opens us a door to get involved, come up with ideas and elevate the project. We’re partners in this so the more details you give us on the problem you’re trying to fix the better we’ll develop it having that purpose in mind. It’s like coming up with a new ice-cream flavour: the requirements are the same of all existing ice-cream, but the purpose is to surprise the consumers.
Here is an example of a list of requirements for an e-learning platform a client shall include in their brief for us.
Tell us when you need it, honestly
Sometimes your project can be more exciting for us than you think so we’ll try to outdo ourselves and really go over the top with it. But when you’re bound by a tight deadline, we’ll have to be more cautious with the timeframe. Maybe we’ll need to readjust our strategy or to bring more people on the project to be ready in time, and that’s alright. We just need to know from the start how much time we have on our hands so that we can plan the best strategy and deliver your new product right when you need it.
And what’s your budget
We all know the money talk is sensitive and it scares most customers, but it doesn’t have to be this way. Price is key when you’re launching a project and it’s as important for the developers as it is for yourself. Some requirements take up more time than others and some technologies take more steps to be implemented. If we know what’s your budget then we can come up with a solution to fit it. There’s never just one answer to a question, so different providers will give you different solutions according to their expertise and your price. When the budget talk is transparent and upfront from the beginning, both the client and the developer are able to negotiate and find the best fix for your asking.
Is there anything else on your agenda?
A good project brief is comprehensive, but it can never be exhaustive. Is there anything else you have in mind that the developers should know? Are there any other goals your product should meet? Sometimes clients request an MVP or a proof of concept. Other times they become interested in the scalability of the product right after we’ve picked our process strategies. And sometimes not much change can be done in order to still meet the set deadline and budget. So tell us everything you hope for your product so we can plan ahead and pick the best road to success.
Project brief checklist
If you scrolled until here, we’ve got a takeaway gift for you! Here is Qwerty Bit’s checklist of what should do in your project brief. Read it, fill your details in and send it to us! Maybe we’ll work together on your next project.
- Project user requirements
- Customer persona
- Timeline
- Budget
- Project goals
- Integrated or standalone
- UI / UX design requirements
- Platform of choice
CREATIVE DIRECTOR
Creative with an Advertising MA in London, constantly developing writing superpowers as an advertising professional
