The most successful mobile apps make millions a month, so it’s no surprise the competition levels are high: a lot of people want to get in on the action!
If you’re going to achieve success when building an app, though, you’ll need to have a perfect brief in place.
But how do you go about creating one?
Here, we’re going to take a look at everything that goes into a mobile app brief, from what to ask clients – assuming you’re not building the app yourself – to plotting the app’s visual layout.
A mobile app brief is just like any professional document, in that it contains a range of standard sections ordered one after the other.
Here’s everything you’ll need to include.
What is the aim of the app?
This is the biggie, and by far the most important part of the brief. (Even if you might be surprised how many supposedly ‘pro’ briefs miss it!)
What is the app for?
Broadly speaking, there are two types of apps:
- Apps that sell and offer services. These apps are the equivalent of a high-street shop. Apps that sell, whether its digital media (iTunes, for instance) or physical products (Amazon’s store.), or apps that enable customers to do things, such as check their bank balance or book a hotel.
- Apps that entertain. This is a pretty wide umbrella term, and includes everything from full games (such as Temple Run) to those that are ‘social’ but are really just entertainment in another form. (Facebook, Twitter, YouTube and so on.)
Your app is going into one of those two camps, whether you like it or not!
Now, you might think that – if you’re building a business app – you’re automatically going to be working in the first category.
Don’t count on it! In an age where every company wants to jump on the digital bandwagon, many big businesses – especially those with deep pockets – consider having an app essential for ‘brand building’. As a result, they’re happy to jump into the entertainment market.
At this stage, it’s worth being honest and asking if an app is really necessary. Will you actually benefit from one, or is it a bit of a waste at this point?
To find out, head back to the age-old S.M.A.R.T check.
Will you be able to set objectives for the app that are:
- Specific
- Measurable
- Attainable
- Realistic
- Timely
For instance, a measurable goal might be ‘to generate an extra $500,000 in sales this year’ or ‘to receive 5,000 extra holiday bookings within six months’.
You don’t actually have to set your goals here: the key is that you could if you wanted to.
If you’re unable to come up with a measurable, feasible goal for the app, the chances are it’s not worth building one. Even games have measurable goals: ad revenue generated, number of sign-ups and so forth.
As long as you’ve got measurable goals that the app can meet, you’re good to go.
What is the key customer base?
Or, more simply: who’s going to download this app?
Like any business product, you need to have a firm customer base in mind: a specific group of people whose problem you’re going to solve.
A lot of ‘brand-building’ apps fall down here. Why? Because if an app doesn’t have a purpose, it’s less likely to find an audience of any kind.
For example:
A holiday booking app has an in-built target audience: mobile savvy people with disposable income who love going on holiday!
Because the app serves a purpose, a sub-section of people have a need for it.
An app that’s just the equivalent of a five-page company website? Not so much. Who’d download it?
Find what problem your app will solve, and you’ll find your audience: they’re the people that have that problem!
It’s often a good idea to create a user persona. This is an old-school marketing technique, but it’s still in use – and with good reason!
Essentially, you visualize your ‘ideal’ customer. If you were to ensure your app reached ONE person – the person who it would benefit the most – who would they be?
- What profession would they work in?
- How old are they?
- How comfortable are they with technology?
- What income bracket do they fall into?
- Why do they need the app?
- What’s likely to frustrate them about it?
And so on. For a splendidly detailed guide on personas, we’d recommend this piece.
As with any marketing plan, the more detailed you can be here, the better: the more specific your audience, the better you can target your advertising.
(For more on mobile app marketing, check out our guide here.)
Specifically list your features
So, you know what your app is for and you know who you’re marketing it to.
Now, you need to look at your specifics. Exactly what will your app need to do?
Yes, you need a list, and expect it to be quite extensive. Even simple apps have more features than you might think:
- If you’re selling goods, you need to have a secure checkout feature.
- If you’ve got a customer login feature, you’ll need to have a database in which to store their details
- If your app is for customer service, you’ll need to have the relevant e-mail forms set up.
And so on.
Remember, create a comprehensive list. You don’t want to miss out anything that’s relevant, or else your app will take a lot longer to build.
Why do this now?
The most effective apps are simple. You’re creating a list of features you NEED, not features that ‘might be nice.’
It’s for this reason that you have to specify the purpose of the app first. Once you’ve got the purpose in mind, it’s easier to create the feature list.
Your aim is to make a simple, clean app that does exactly what it’s supposed to do. If you overloaded it with unnecessary rubbish, you won’t achieve this.
Which platforms are you going to target?
There are two main stores to focus on: Apple and Android.
Which should you choose?
Well, a lot of it comes down to your aims as a business.
If you’re purely focused on additional revenue – and there’s nothing wrong with that – then getting on the Apple store is essential. Apple users simply have more money to spend.
Why can’t I publish to both platforms?
You absolutely can, and many of our customers at Iconic Solutions do.
However, many of them choose to ‘stage’ publishing their app. As in, they upload to one market first, allow time to fix any teething problems and then publish on the other.
There are a few benefits to this approach:
- As we mentioned above, it lets you iron out any issues. Rather than fixing on both platforms, you can fix on one and have a trouble-free installation on the other. (Barring the standard bugs.)
- You can obtain early feedback, take the advice and tips offered by your customer base on one network and use them as guidance for updating the app BEFORE you make the second install.
- It minimizes risk. Any major app development has the potential to go wrong, whether through security issues or simply bad marketing. By publishing on one platform, you minimize this risk.
How do you choose which platform to go with first?
Simple:
Go back to your customer base. (See? There’s a reason this brief is in order!)
Assuming you’ve got a firm demographic in mind, you’ll be able to work out which platform that demographic is more likely to use.
(The biggie will often be which area of the world they’re in: Apple gear is a lot more common in affluent regions, for example.)
Will there need to be any database or data integration?
Not the most exiting section title, we’ll concede, but that doesn’t make this less important.
A LOT of modern apps need to be linked up to databases.
- Stores need to hook up to stock information
- Customer service apps need to keep a record of communications
- Booking engines need to access both customer and venue information
- Fitness apps need to access relevant video and audio content
And so on.
This needs to be looked at early, simply because the app may need to be designed around the existing structure of the database.
And, unfortunately, some databases are BADLY organized.
This may mean you have to jump through more hoops to link the database up to the app, or that you have to tidy up the database before you even start the app’s construction.
Don’t ever assume that the database the app requires access to will be clean and well-structured: it could cause you serious headaches later on.
(It’s also worth checking that the database is owned by the client and they have copyright: this isn’t always the case, believe it or not!)
Define the look
If you’re a graphics nut, this is definitely the fun part of the brief.
Think of the app market as a dating website: you live or die on how good you look!
Luckily, there’s a magic tool that’ll allow you to easily shoot ideas back and forth with your client or simply come up with ideas by yourself.
What is it? A pen and paper!
It might seem a bit cave man, but in the very early days it can be really beneficial for clients to take this approach. It’s a lot less formal and far quicker. (Though there are a number of software options if you’d prefer that approach.)
Remember that your color scheme will often be dictated by the existing brand if you’re working with a client.
Once again, there’s a reason we’ve left this point until after the database check – the database layout MAY affect how the app can look visually, though this isn’t a guarantee.
Be sure to specify both the colors, fonts and image filters at this point: just as you would with a website design, you’ll want a firm style guide in place before you start creating the app.
Who will be responsible for the content?
Now that you’ve got a swanky design in mind, you’ll need to clarify the next point: who’s actually going to provide all the stuff that’ll fill the site?
If you’re thinking ‘well, the client, obviously’ don’t be so sure: some clients automatically assume that any text, images and videos required by the app will be supplied by the developer!
(If you’re solely a developer, it’s worth having a copywriter and a video editor in your contact list in case this occurs: you want to be able to supply the content if you’re asked to.)
Many briefs actually exclude this point and suffer inevitable problems later on: usually the problem of both teams looking at each other thinking ‘I thought you were doing that!’
Who’ll be providing the hosting?
You’ll need to specify where any relevant information – such as databases or content – will be stored.
Most modern apps don’t contain a lot of information in of themselves, which is why they’re able to remain relatively small in terms of storage. Instead, they pull their content and data from a hosting network, hence why most of them require an internet connection to work.
It’s important to be clear in the brief who will be responsible for hosting the relevant databases and content. There’s nothing wrong with the client doing this – they’ll be able to provide you with remote access – but again, like the content it’s very easy to end up with an ‘I thought you were doing it!’ problem if you don’t clarify this in advance.
Who will be responsible for ongoing support?
Apps aren’t a ‘set and forget’ project: ongoing maintenance will always be required.
As long as they’re happy with the initial build, most clients will want to start some form of support contract with you, where you continue to carry out bug fixing, hosting and compatibility with software updates.
Again, specify this in the brief. You want to ensure you’re available to carry out any requested ongoing work after launch.
Now we’ve specified what needs to be contained in the brief, we’ll take a look at the other key things you’ll need your client to tell you before you start building the app.
Is there a firm deadline?
This might seem obvious, but you’d be amazed how many clients don’t mention a deadline until about four weeks too late!
If the client has a firm deadline in mind, they need to tell you about it at the brief stage. This will allow you to start at that date and work backwards to ensure you’ve got enough time.
Remember, you’ll need to take testing and submission into account: it’s not just a matter of the build.
What problems are you likely to encounter?
It’s best to consider Murphy’s Law here: if something bad CAN happen, it probably will.
Try to address all potential problems before you begin the build, and give responsibility for managing these problems to specific people.
Problems can be anything from a chaotic database that requires sorting to the marketing for the app being handled by an incompetent third party! Issues can come from anywhere, which is why it’s important to take as many of them into account as you can.
What’s the budget?
Aaaah, the big awkward question that many developers avoid.
Don’t be one of those developers!
It’s important to establish very early on what sort of budget the client has. All the meetings, design briefs and pen and paper doodles won’t be much use if the client can’t afford your services.
Pricing can be a bit of a poker-face game, especially if you’re working with a new client. However, it’s important to get to a ballpark figure as soon as possible. If the client doesn’t have a big budget, you need to manage their expectations.
(Don’t forget to budget for ongoing support, bug fixing and hosting once the app is live and for any extra content you’ll be supplying.)
Who’re the key stakeholders?
Who are you going to be answering to during the build? Who is actually responsible for making decisions to the other end? Who do you need to report any problems to?
This is more important than you might think: if your client is a decent-sized company you may find yourself getting held up by red tape. It’s all very well being in constant communication with the marketing manager, but if you have to wait three weeks for the CEO to approve every minor change you’re going to suffer a lot of delays.
(It’s entirely possible your key stakeholders will also end up on your problems list!)
What is success at each stage of the process?
You need to clarify exactly what constitutes success at each stage: the initial brief, the back-end build, the front-end design, the launch and the post-launch.
This might seem a bit red tape-y, but it’s important: you need to have clarity in what both parties are expected to deliver. It can save a lot of stress and anxiety later on.
Are there any competitors?
By this, we’re talking about app competitors: other apps solving the same problem you’re attempting to solve.
This isn’t just a matter of market competition. A local parenting store might be the first in their local area to build a bespoke app, but that doesn’t mean they don’t have competition: for starters, they’re competing against Amazon!
Remember to focus on the need you’re fulfilling, rather than just what your app does. Facebook and YouTube aren’t the same, but they’re filling the same need: stimulation.
Know how to meet the needs of your userbase
What design constraints and considerations are there?
It might be the app has to work within certain corporate guidelines. (This is common when working with larger businesses.)
How strict is the company’s branding? Will it, for instance, allow you to link to external sources? Will the screen layout have to mimic the company’s existing website, or their catalogue?
Ensure you’re aware of any design or function limitations in advance.
Are multiple releases a possibility? Is there an MVP?
We’ve already mentioned building a comprehensive feature list, but there’s another thing to bear in mind here: what is the Minimum Viable Product?
Some clients become torn between creating an all-singing, all-dancing app and the time required to build that app!
If a client wants a feature-packed product but doesn’t want to wait for two years, then the MVP is an option.
This is the Minimum Viable Product. What is the simplest app the company could build whilst still solving a real need?
Say a major high street retailer wants to build an app that delivers food and drink, but also promotes their other products, such as clothes, or home furnishings.
Rather than spend three years building an app that does everything, the company can start with an app that just focuses on their furniture business, and then slowly add the other features over the next couple of years.
They still get the brand exposure, but are also able to get at least one app on the market in less than a year.
What information will the client require post-launch?
In asking the client what they define as success, you should also ask them to specify what information they’ll require once the app goes live. Will they want to track just revenue and downloads, or will they also require more detailed information such as:
- How frequently the app is being used
- Which features are the most popular?
- How many users are activating push notifications?
- How long is the app being used for?
And so on. Again, this needs to be specified in advance: you need to know what to track!
Iconic Solutions are specialists in creating apps that get results. Whether you want to provide a better service, improve awareness of your brand or simply increase revenue, we can help.
Give us a call today.
