Communicating your vision and ideas for an app to a designer or development partner can be a hard task, and failure to get your message across can result in disappointment with the final result. It doesn’t matter if you need a mobile app, desktop app, web application or other software, you need to formalise your thoughts in a way that can be easily understood by multiple parties.
A software design brief is the perfect way to do this, it captures your intention, your ideas and your needs and communicates it in a simple format for your development partner to consume. You can also use it as a reference document during the design and development of your application.
Your software design brief is a vital way to ensure that you and your development partner have a shared understanding of what it is you want, so the more you can prepare yourself, the better.
What is it and why is it being built?
First things first, begin with a couple of sentences on what your app is. This should frame your app in terms of your business and its context in the market, so the designer understands how you see yourself fitting into the existing market. Include your strongest competitors and how you will differ from them if you can, to give the designer some information on what you are expecting from the end product.
Once you have introduced the app, you need to discuss its features and functions. Is it designed to provide information in the form of content, or will you want the user to interact with it and input their own data? This affects the design of the app, and how visual it is, so your designer will want to know what the functional areas of the app are, as well as details of any complex functions.
At this stage, however, keep it simple. The design process your development partner uses will uncover all the details, you just need to summarise what you want it to be able to do. Stick to high level bullet points like; read articles, manage a to-do list, book appointments, etc.
Who are the users and the customers?
We’ve said it before, and we’ll say it again, and then we’ll keep saying it. Your users are the key to your application’s success. Your users will drive functionality, design, change and features, so they must be clearly understood up front.
You should know who your users are, what they are going to do in the application, what they’ll want to achieve by using it and the type of experience they are expecting.
It can help to imagine them as people, and describe who they are. You can write up a description of who they are, what their current problems are, and how your software will help. Then try to think about what they’ll be expecting of your app when they use it.
Your customer may well be the same person as your user, but sometimes they are not – consider who gets the benefit from your application. For example, who is paying the subscription fee? Who receives the output of the application? Who will benefit from this software?
What will it do?
Obviously your application will need to do something, and therefore has requirements. At this stage there is a very serious danger of getting too detailed. There is no point in thinking about what the icons will look like, or what the email text will contain, or even that it will send emails. Keep it simple, and in easy to read bullet points. Call out the main areas of the application, like making a to-do list, or saving files, and then the key wants / needs you have under those.
It might be worth thinking about what your priorities are here, so when you are writing up features, think carefully about whether you MUST have these, SHOULD have them or COULD live without for now. This is helpful information to your designer when they are creating your user experience.
What is the experience of the app?
This part is a bit more subjective than requirements. Instead of thinking about what it must do, describe what you want it to be like, how it should feel to the users. Should it be corporate and formal, or casual and comfy? Do you need it to be accessible, should it support colour blind or visually impaired people?
We often just have our clients describe what they imagine it to be like using descriptive sentences, like they are describing a home or a place. Then we can pick up on what style and feel the application should have. As well as starting to consider the UX copy, which is an important part of the overall experience.
What content will it have?
There will be something in your app. It might be stuff the user adds (like a to-do list), it might be items they can look at (like a clothes shop), there might be things they can read (a blog), or even things they can create (like jigsaws). You should think carefully about what it is and where it comes from. The design will be affected significantly by what the data is and where it comes from, so you should consider what your application will have and provide as much detail as possible.
What should it look like?
Probably the most exciting part of the brief! Collect ideas, screen shots, animations, and thoughts in one place. We often use InVision boards to share our ideas, and our customers love being able to scroll through the thoughts and themes we have come across that are used to inform the design. Even if you only include a few screenshots of things you’ve seen that you like, this can be helpful to your designer to make sure they understand what you like.
What is the budget?
We always offer our clients the option for independent discovery, design and development phases, so that they have the option to go as far as their budget allows before getting further investment or continuing with the project. You should consider what budget you have available to fund the project, and how far you would like it to go. For example, do you want to deliver the entire thing, or just get a prototype together that will allow you to get further investment. A good development partner will work with you to create a scope that will deliver what you need, within your budget, as best they can.
What is the timeframe?
Alongside your budget, you should consider whether the work can be completed in a reasonable time for you. Of course you may not know what can be done from a technical perspective, but you should be aware of deadlines you might need to impose, like meetings or conferences, that would affect the designer or developers. Discussing this upfront will allow your designer to feedback to you what is possible, and help them to prioritise the work packages appropriately.
Summing up
The brief is a very important part of your project, but not one that you have to do by yourself. You may be happy to create it yourself; or ask your development partner to help; or let them do it and you can just amend or approve it.