Here is a very common scenario, which I am sure we have all come across in some point of our careers.
Client – I’ve got an idea for a mobile app – how much will cost?
Account Manager – Do you have a brief?
Client – Nope
Account Manager – Urgh
There are some people who may fall into the trap and provide a cost to the client based on this conversation. Even though it’s heavily caveated as ‘ballpark only’, the client will merrily wander off in either disbelief or excitement. If they are excited, they may wish to come in and see you at which point you will whole heartedly agree and possibly arrange for one of your developer or designer colleagues to be present.
The problem here is that for a start it is not qualified and you will be wasting your colleague’s time. Secondly, you are wasting your own time and thirdly, the client doesn’t even know what they want. It’s a fail on all accounts.
I used to fall into this trap as well. To avoid this messy situation entirely and to clean up your sales pipeline, you must not commit to anything without either seeing or helping to construct a brief. The later, you could charge upfront consultancy for but make sure you interpret what value this will deliver to the client before doing so.
So, here are 12 items to help clients and agency bods make sure the mobile app brief is water tight and creates the right foundation for pre-sales activities to commence.
Oh, and just to be clear this isn’t about sales qualification (although some of the aspects do lend itself well to this) nor about the different processes that make up app development. Now that’s clear, lets start with the first one…
1. Should we progress?
First and foremost, do they really need an app? Do they need a native app or would the clients project better suit a mobile web app. We are assuming that they have done their research, understand their customer, validated their market and conducted SWOT or competitive matrix analysis. If you think it won’t be viable or the client doesn’t need an app then be honest and don’t waste any more time.
“I’ve got an idea that’s not been done before” – this is highly unlikely and most probably just an evolution of another idea. Don’t be surprised however if parts of what they are saying is true. We’ve been involved in a few projects recently that have in parts been revolutionary.
Once you have got past this, the brief must specify what the client is trying to achieve? Why are they trying to do this and what specific problem does it solve? Do they even know? In the back of our mind, we are always checking if the objectives are SMART (Specific, Measurable, Attainable, Realistic and Timely).
If the client has deep pockets and considers this a ‘branding exercise then firstly qualify that this would be waste of time and secondly define what marketing plans they have behind this to promote the brand. An app doesn’t provide brand awareness on its own.
3. End-user scenarios
Following on from the objectives, can the client frame scenarios of usage or customer events? These will be helpful to the development team to understand the potential customer use. Is the end-user likely to be out-and-about, sat on the sofa, in the car, demonstrating the clients company products to the client, in the wilderness and so on.
Defined customer events will come into play early in the development process, feeding into the architectural blueprint and wireframe phase of the process. They will also become invaluable when creating a testing plan.
4. Features and the Minimal Viable Product (MVP)
In front of you, is a mammoth list of features that the client is intent on been included within the app from day one. This is great and very encouraging but what you must do is two things:
1. Categorise which feature is app, desktop or backend CMS. This makes it easier to scope out each feature and separate the costs. Depending on the project, the app can sometimes become the smallest part of the development.
2. Define, which features, are going to meet the objective or solve the key problem on day one. Forget about all of the nice to haves and build the MVP.
Once you have agreed and documented the features, make sure that this is adhered to. When development starts, feature creep is a project killer for everyone concerned and is a seriously demoralising experience. Agree on the features and stick to them.
Once you have done this, you will then be left with a whole host of other features floating around without a home. This is a great time to build a road map of feature updates for the app, generally spread out throughout the next 12 months. End users like to know new features are planned and on the way so make sure the client specifies this in their app store description.
Ultimately, simplicity is the key to a successful app. It doesn’t mean that it should provide next to no features and if they are complex and ‘musts’ for version 1.0, then package them up in a beautiful and elegantly deigned interface. If you have a look at an iPhone app on the app store called London: Coffee(in)Touch, you will see what I mean.
5. Platforms and people
In terms of mobile operating market share, it’s a two horse race. That is Apple and Android. Clients will therefore choose these platforms and they would be wise in doing so. Where problems can arise is if the client wants both platforms launched on day one. It is always advisable to ’stage’ the development platforms, one after another. Here are a few reasons: –
1. Any problems that have arisen from developing the first platform will be avoided for the second.
2. Feedback from just one platform can be transferred to the second platform before development has begun. They can then launch a new platform and also a host of new updates on the existing platform.
3. The risk the client is taking is minimised by developing on one platform. If the app is struggling, changes and investigations only need to focus on one platform.
So, which should come first? iOS or Android? This depends on whom the app is targeted at. A good start is for the client to survey their existing customer base and ask which device they use. Alternatively, the client can create a simple poll on their Facebook page.
Demographics and targeted segmentation play an important role in choosing and advising the right platform and technology the client should adopt. In other posts on our website, we’ve talked about the significance of the role of User Experience in the development cycle and it certainly plays a large part in helping to shape the brief.
Once the platform has been chosen which operating system to target will then need to be decided. Will the app work on an iPhone 4 orwill it have to start from a 4s and above? Should Android 4.0 and above be the target – the designers and developers will need to know this. Can the app support lower versions of Android? If it does, then this is likely to cost extra.
Designing and developing the app is one aspect, what actually goes into the app is another. Don’t assume that the client will provide the editorial content for the app; they may be under the impression that this is part of your service. If the client isn’t happy with their content writing, are you able to provide a copywriter to oversee and modify their work? We’ve done this several times and it works really well.
7. Screen layout
A very simple and effective method is just to use pen and paper. Ask them to sketch out some ideas on paper and work with them on this. It doesn’t have to be a fully blown mock-up.
We ask our clients to download a free app called POP. This allows the customer to take a picture of their drawings and then assign actions to the buttons. It’s a really cool app and works very well. It also helps the development team to understand what is going to be on each screen along with any possible transitions between screens and menu items for example.
Another important point to remember is that the client may assume that landscape and portrait modes of the app just happen and everything fits into place automatically. This isn’t the case.
8. Database and data outputs
If the client has their own database outputs that require integration into the app, then include samples of the database structure or output files for the developers to inspect. If the database structure is totally hideous, then there could be extra costs to integrate or even tidy up its structure. It could be the case that the client is using a third party company for the database so again, be clear on who has ownership.
I’ve seen this destroy many projects in the past so make sure this highlighted early and included in the brief.
This often catches out many clients so make sure that this is specified in the brief. If the mobile app is pushing, pulling and storing data from a database of some kind or requires integrating to an external data source or environment then some form of hosting is required. The hosting will either be for the database of the API that the developers will build.
If the client is providing the hosting and the app has to connect into their hosted environment, then make sure this is specified in the brief. Ask for the framework type (.net) and security governance and data.
If the client is going to be providing a service and doesn’t have a support mechanism in place to either a) accept feedback b) listen to and respond to feedback then they will be in trouble.
In addition to this, the mobile app is going to need supporting technically. Ideally you need to provide this to client and charge accordingly. Support items will cover aspects such as bug fixing, hosting and compatibility with new versions of software. On this note, you should also be clear what mobile operating system version the app will support. Will it be Android 4.0 and above and iOS6 and above.
Apps don’t promote themselves and whilst not a concern of the development team as such, the brief should at least highlight the marketing channels that will be used to expose the application. This isn’t necessarily a ‘must’ for the brief but could open up an opportunity for you to help the customer and provide marketing services on top of development. It’s what we do at Integrated Change.
12. Time Frame
It frustrates me greatly when I see a brief that specifies the ‘date to be live’ without an actual reason behind it. This assumes that they have somehow hacked into your development timetable and have conveniently helped themselves to a spare time box.
Has the client got a compelling reason why they want the app live? Maybe they have PR lined up or plan to make a big splash at an event? If they have, then you wonder why they have organised this without prior knowledge of mobile app development lead-times.
It happens, but if they want it delivered on a certain date then the client must be prepared to pay extra for the privilege of additional resources. Alternatively, they go somewhere else.
So there we have it: The 12 items that should be incorporated into a client’s mobile app brief.
Ensuring that you capture these will make for a very happy developer-client relationship. It will also help to minimise any nasty surprises when design and development begins. What else could be included – let us know what you think.
We will be checking that you have read this blog post when we next receive your mobile app brief!