Here at Everyday People, we’ve had our fair share of teasing mobile app briefs in order to help our developers submit a detailed application and an accurate quote. Today, we have a guest blog post from Paul Jervis founder of York-based software development company Twelve Oaks Software, on how to improve your mobile app brief, which was originally posted on Twelve Oaks blog.
Over to Paul and Veronica…
A sparse specification can be problematic. Developers need to know what is expected of them so they can give accurate estimates of cost, time and possibility.
Follow these handy tips on how to write a technical specification for a mobile app project.
1. Provide as many details as possible
When setting out your project, think about what you want it to do. Break each step down and consider what it will involve. Say your company wants to develop an app that plays music at different volumes, connects to an online server to download new music, and shows visual patterns according to each file.
This raises a number of questions, does the app need to:
- work on both Android and iOS?
- work on different versions of the software? How far would these need to date back?
- work on tablets?
- be integrated with any other services (e.g. social media, Google Analytics)?
- be built from scratch, or improved from a framework?
- pull information from a database?
- be designed?
- have written content created?
- have visual content created?
- be localised into different languages?
- have a database of downloadable music curated?
- utilise downloaded songs on the device it works on?
- connect to a server with designated endpoints, or have those decided by the developer?
- take into account submission timelines (e.g. Apple App Store, Facebook Approval, etc.)?
- be tested by the freelancer, the business, or a third party? Which one?
Give as much information as possible in order to make a freelancer feel confident about the scope of your project, as it shows that you understand the role you’ve hired them for. If possible, show your specification to a known developer before you start, so they can give you feedback on what else you may need to include.
You should also try to avoid using project specification templates. They are a useful way to get ideas about the type of information to include but don’t rigidly adhere to a template that doesn’t fit with your specific project.
2. Say what’s already been done
Nobody likes the prospect of extra work hanging over their head or unforeseen costs. The easiest way to avoid that is by explaining what parts of the project have already been completed, as this can answer many questions that a developer has.
Let’s take our music app again. Maybe you’ve gone over it with a consultant, and they’ve given you a page count that gives a scale for the app (which gives an idea of how much work a developer will have to do). You’ve also hired a designer, who has done all of the visual design, decided how the user interface will look, and what buttons will go where. Perhaps you have an existing web service and you have another person hired who can code in Android, so all you need is the iOS app developer.
3. Break it down (into different projects)
Depending on how your company works, the easiest way to complete a project may be to split it up into multiple, smaller tasks. The music app project could be outsourced to at least four different people.
Our music app will need to be coded in both iOS and Android: that could be done by one person with knowledge of both operating systems, or by two people working on their specialities. The design could be done by the developer, but you may get better results faster from a dedicated designer. And do you want to leave testing entirely in the remit of the developers, handle it internally, or outsource that to a different freelancer?
Content creation may also need to be outsourced to a copywriter, as the crossover of professional developers and professional content creators may be fairly slim. In general, if any aspect of a project has to answer different questions, then it might be better off delegated to a different professional freelancer.
This way, you can give your designer and copywriter information on target demographics, end user experience, tone and feel, without having to bog down your developer specification with superfluous information.
So what have we learned?
Make each project specification as targeted as possible. It’s better to give too much information rather than too little. It may take a little more time at the start, but it’s bound to pay off further down the line.
Thank’s Paul and Veronica. To find out more about Twelve Oaks Software take at look at their website.
16 Marketing Blogs from Yorkshire to Write Home About
Over the past month, I’ve reached out to Yorkshire’s business community, asking them to recommend their favourite marketing blogs, next time we’ll take a look at the top 16.
If you’re looking for someone for a current project, tell us about it
and we’ll find you great people to work with.