How to Write an Effective Web or Mobile App Brief

So, you have an idea and some direction (or have been tasked) to start a new web app or mobile app, but aren’t sure where to go next. While you might think a brief isn’t necessary, it is usually an integral component in defining the goals and constraints of your project.

Digital project briefs come in a variety of shapes and sizes, and there’s more than one right way to tackle them. Some are huge – flying in the face of the word “brief” – and some are tiny. Some demand alllll the details, while some demand only a high-level view. One indisputable fact, though, is that app briefs are integral to the success of the project. Whether it’s for your internal project team, or you’re hiring an outside agency, a brief will force you as a project owner and your team to really be intentional about why and what you’re setting out to do.

Web app and mobile app briefs are not the only step, but they are the first in the project discovery phase. So if you’re looking at starting a project, be it a web app, a mobile app or even additional functionality for existing properties, you’re in the right place. With that in mind, let’s talk about why we need them first before we get into what they look like (spoiler alert: we have a free app brief template for you to use a bit further down!)

Why Should I Bother with a Brief?

You wouldn’t buy a house without outlining what you need, would you? I mean, if you just called up a realtor and said, “Yo, gimme a house” and hung up, who knows what you’d end up with? You could get a cardboard box, a mansion with two butlers, or anything in-between – because no thinking went into the purchase and no parameters were given to the realtor. The same reasoning applies to web and mobile apps (with some costing just as much, or even way more, than your house).

That’s why we need project briefs. We need them to force us, as project owners, to think about and validate the key pieces of information that go into a project. It requires us to think about the why, the what, the how, and the when of a project that could carry a bunch of risk (and hopefully, reward). It gives a home to information required for project validation and discussion – be it with your boss, your internal team or an agency – and ideally gives all stakeholders direction throughout the life of the project. It might seem silly, but it’s easy to get a few degrees off course when you’re deep in the forest; then, miles later, you end up in entirely the wrong location. Oops.

A properly executed and maintained project brief will avoid that.

How & When to Use a Web or Mobile App Brief

There are three key situations where project briefs are mega helpful:

1. Pitching a project to your superiors or coworkers. Spend some time creating a thoughtful, informed, and concise brief, and you’ll be able to state your case for your project efficiently to your (busy) boss or teammates.
2. Procurement. If you have the green light for the project but need to hire expertise to tackle it, then a project brief will give agencies or internal teams a good starting point in the discovery phase. From there, both sides can raise informed questions and further project discovery can commence.
3. Throughout the life of the project. Project briefs are not documents to be cranked out at the start of the project and then left to rot in your Dropbox or Drive folder. Instead, they should be continually referred to throughout the entirety of the project. They serve as a guiding light for project success, historical decision-making (yes, they should be updated with notes), and additional information as the project discovery phase marches on.

What Content Goes in Your Brief?

There’s no hard-and-fast set of requirements for what goes into a project brief, but they usually contain information such as:

1. Company Overview
2. Project Summary
3. Timeline
4. Budget
5. Business Goals
6. Success Criteria
7. Key Performance Indicators
8. Challenges

Sometimes project briefs will include items like User Personas, Technical Requirements (and/or Specifications), and sometimes even Information Architecture or Journey Maps. These are all important steps in any sort of web app or mobile app discovery phase – whether or not they end up in the brief or in separate documents doesn’t really matter.

Some of this content is dependent on other steps being complete. For example, you can’t have effective Information Architecture without understanding your Users. So, with that in mind, we suggest separate documents for items like Personas and Requirements so you can progress throughout the discovery phase without being hung up. Remember though, all of these project documents – be they Project Briefs, Personas, Information Architecture, or something totally different – should be viewed as living documents that can and should be updated throughout the life of the project. They are not written in stone.

The key takeaway on what type of content to put into a web app or mobile app brief is that it should describe what needs to be built, why, for whom, when it needs to be done, and how much it should cost. What each section is called doesn’t really matter, but there’s no real reason to not use the outline mentioned above. (Which is the same format in the free downloadable app brief template below.)

1. Company Overview

This section is simply a summary of your business or organization, though if your organization is large enough, it could also be used to outline the branch of the business that the web app or mobile app is specific to. Here’s an example:

[Company] is a pharmaceutical tech company located in Los Angeles, California, that specializes in research and development for cutting edge pharmaceutical products. With over 500 employees, [Company] is established in their field, having been in business since 2001. More information can be found on their website at www.url.com.

2. Project Summary

This section is a summary of the project/type of work required, and why. Here’s an example:

[Company] is in need of a new mobile application: planning, strategy, prototyping, design, development, content, QA/UA testing — the works. Many of [Company’s] users are in the field, which makes accessing the resources and billing management that they need via desktop or the existing unresponsive website cumbersome. [Company] moved to a new CRM in 2016, which will need to be integrated with the new mobile app.

*Note: this is a summary, not to be confused with specific project requirements, which is a whole other part of a proper web app or mobile app discovery phase.

3. Timeline

This part of the brief can just be a high-level summary of the project timeline. If you want to get into details about timelines for specific deliverables and phases, feel free, but usually there are too many assumptions this early in the game. That’s why we suggest a high-level timeline at this point. It can just read something like this:

The mobile app must be tested, stable, and launched on the production server by [date] in order to fit within this fiscal year and line up with the key dates in [Company]’s marketing plan.

4. Budget

This section is as it sounds – it’s just a description of the project budget, which hopefully you’ve got in place.

[Company] has allotted a budget of $XXX,XXX for this project (inclusive of all taxes, services, licensing etc.), and a budget of $XX,XXX for one year of post-launch hosting, support, and maintenance.

5. Business Goals and Outcomes

The Business Goals and Outcomes section should answer the question, “What goals for the business/organization will this project help meet?” Here’s an example:

[Company] has three primary goals for the next two years that this project will help meet:

1. 20% growth in customer share YoY
2. 10% reduction in manual onboarding processes in year one (post-application launch)
3. Development and launch of Innovation arm of business

6. Success Criteria & Key Performance Indicators

How will the success of this project be measured? Key Performance Indicators (KPIs) are a great way, if established at the outset, to prove value in the work once it’s complete. Here’s an example:

The success criteria and KPIs for this project are as follows:

• Launched by [date]
• No project budget overages
• Average of 100 app downloads/month for the first year
• 100% automation of client requests into CRM via mobile forms
• 20% decrease in manual onboarding time against benchmark

A great way to think about KPIs is to ask yourself: what data would I be excited to report back to my stakeholders or include in a case study?

7. Challenges & Considerations

This section should outline the key challenges and general considerations to note. Here’s an example:

There are a few key challenges to note on this project. First, the scope of content to be audited, organized, and written is considerable. Second, the CRM integration is technically complex despite the existence of a well-documented API. Third, client relationship managers must be able to track their customers journey through the software without development aid. Finally, communicating to our audience exactly what we do without over-simplifying or conversely coming off too complex has proven to be a challenge.

My App Brief is Done – What’s Next?

It’s important to note that your App Brief is never really ‘done’. You should often come back to it to reference key points and update it with new information as the project progresses. However once you’ve completed your initial brief, it’s time to share it with the other project stakeholders — whether that’s your boss, your digital agency or your team.

Assuming you have the approval to go ahead with your web app or mobile app project, the next step in an effective web app or mobile app discovery is to really dig into your users. After all, your users are the people who matter most. The best way to tackle that is by researching and writing up some detailed user personas that relate back to the project brief you’ve just created.