How to write a mobile app specification
I have come across many such questions from entrepreneurs, and people who are just getting familiar with mobile apps development. I can definitely understand how confusing it can be at first when asked for ‘app specifications’ as the word itself is ambiguous especially if not encountered earlier. The problem is that a poorly written app development spec is likely to prevent you from getting your mobile product on time, on budget and matching your initial vision, and from correlating your expenditures with a development budget and creating an environment of a shared product vision with your development partner. Some clients have also described an idea to me and then immediately proceeded to ask how much it would cost. As much as I try to be helpful, most of the time I usually don’t know. Hence, the reason for writing this article to help clear the air and help you approach your mobile app concept more confidently and professionally.
Before even building an app, two crucial people analyze the concept before development even begins, they are: the project manager and the lead developer (in some instances the CTO). They go through what the app entails in terms of technology required, timeline, complexity and the flow. Any good process worth its salt focuses attention on what needs to be done next — and then puts a premium on actually completing them. Why? Because breaking things down into small, discrete components and prioritizing them is the fundamental secret to getting both big and small things done.
At this stage, you should expect frequent meetings and calls between the client and the team with a lot of to-and-fro focusing on design, timelines and functionalities.
Making a mobile app development spec is neither difficult nor complicated at all. Just stick to the suggested sequence below while writing your next app’s spec and you’ll be able to properly envelope your ideas and vision for your development partner.
- First off, explain all definitions, acronyms and abbreviations to be used in the document (this can be done as a last step when writing a spec, but should always be placed on top of the document)
- Describe your app’s goal
- Describe your app’s target audience
- List and prioritize all mobile platforms your app is intended for
- List and prioritize OS versions your app is intended for
- List all technologies that should be used for building your app (I suggest you always make your own research before getting provider’s response and asking for suggestions)
- List major milestones (from analysis, prototyping, and pre-release to app store placement), their due dates and/or desired timeframe for proof of concept/delivery
- Specify your project’s budget
- Usability and design (screens, view modes, menus, etc) and UI -If you don’t have this then no fuss about it. Our graphic designer can prepare a few layouts and mockups.
- Social media integration (list all social media channels you want your mobile app to interact with)
- App’s collaboration with the server, including detailed description of the app-server interaction mechanism, protocols and likewise data
- Data caching for offline work if required
- In-app purchasing if applicable (specify what type of content will be sold to users inside the app)
- Geo-location services and push notifications
- Compatibility/sync with other engines, internal CMS and other systems
- Provide your market research details and links to / description of all rival / similar apps
- Express your concerns, limitations and special wishes for the service provider to have a complete picture of your future app and its role in the marketplace
- List all points of contact within your organization and briefly describe your vision of how communication between your company and your app developer should be handled throughout the project
Also remember that a killer mobile app development spec should be truthful, consistent, verifiable and modifiable. Try to stay away from generic requirements such as “the app should never crash” or “the app should respond quickly to a user query” and provide quantitative requirements instead such as “each button push should provide a response within 100 ms”
For developers, an important rule of thumb in application development is to always make your code scalable. This would mean setting up a scalable architecture from the very beginning. It might be good idea to make space for some expansion in your architectural decisions as one should not assume that the application will scale up to a certain level.
I’ll revisit each of the items under functionality separately over the next posts.
Let me know your thoughts or comments!
To read more, feel free to visit our blog