Tell me if you’ve heard this one before: A customer comes to the programmer and asks “How much would a food ordering app cost?”, the programmer answers “from 10 thousands to half a million”? - I know, that’s not funny at all.
The thing is that companies like ours get multiple similar price inquiries every week. Customers, which is not surprising, are not aware that it’s almost impossible to give any sort of approximate cost based on such an inquiry. It would be like asking: “How much is a car?”. But what car? How much horsepower? Automatic or manual gearbox? What equipment?
Exactly.
A good brief is detailed enough to enable the valuer to understand the concept of an inquiry and the customers needs. This information makes it possible to define approximate and reliable price ranges. Those ranges can then be considered in a funding application, business plan or factored into an investor budget.
I have already written an article about valuing projects in software houses here: www.jcd.pl/project-valuation - today I will show you how to write a good Mobile App brief.
You can fill it out online here: https://forms.gle/kJkdPCk8DWysqyCRA
1. A summary description that allows us to put further information in a proper context
First, tell us about your idea . What functions does the app fulfill? What problems does it solve? How do you imagine it? The app designation is important, as various kinds of applications may require various technological solutions, and therefore may generate various costs. For example, an app or a game requiring the use of a 3D engine enforces the usage of native technologies, otherwise - a web view or a hybrid solution compiled to a native one is enough.
2. Your business goals
We approach our customer’s projects like they are our own. That’s why it’s so important for us to understand your business goals while making a valuation. One of the first questions a good brief should answer is: what do I expect from the app as an initiator and an entrepreneur? How can it help the company? What business needs can it fulfill? Increase sales? Spread the reach? Reach other market segments? Support PR activities? Which business model did you choose for your app? Understanding the goal will allow us to pave the way to achieve it.
User - who will the application be for?
That’s an important step, which determines technological and visual aspects of designing an app. It is important that our knowledge of prospective users is as accurate as possible. It allows us to design an app that fully meets their needs. Describe your target group and it’s values, possibilities and limitations by using a persona tool. Creating a persona is a way of analyzing and presenting information about a typical, desired user. How old is he? In what situations will he use the application? Is he familiar with new technologies - does he freely use them, what mobile devices does he use? Each target group requires a different approach when designing an application. It must be done differently for teenagers using smartphone all the time, professionals using it for work, truck drivers, young mothers and so on...
4. User experience.
Describe app functions from the user perspective - the most convenient way is to use user stories according to the scheme shown below:
| “as [user/admin] I do [what?- action] to [goal, result, problem to solve]”. |
For example, user stories for a food ordering application can be shown like this:
- as a user I filter the list of available restaurants by their delivery time to choose the quickest delivery;
- as a user I add the restaurant to my “favourites” so I can easily return to selected restaurants from the main screen later;
- as an admin I manage the restaurants features/attributes (time, delivery price, type of cuisine) to update important information about the restaurant;
- as an admin I download a daily order report to analyze sales, archive data and optimize the work of the restaurant.
To design an attractive, but also functional product, we need to know and predict how users can use the application, so that we can offer them the most satisfying experience.
What’s important for the valuation - we can estimate the number of screens to be designed and coded, as well as pre-evaluate the functional complexity on the basis of user stories.
5. User interface:
The interface is a secondary issue to the user’s experience. The designs role is to enable the user to use the application efficiently. Usability, providing a positive experience, maximum intuitiveness and ease of use - these are main goals set before UI designers. Good design has to be based on excellent understanding of the user’s needs and customer’s business goals (ordering party). Initiators come to us often with a specified idea: colouring, examples of similar projects, a moodboard or even an overall view of the final outcome. By combining all this information we can provide designers with the perfect fuel for the creative process.
Sometimes, customers have their mock-ups or graphic designs already done - this step is good for such information - as it can change the valuation even by up to 30%.
6. Budget
The question of budget can be inconvenient for some customers. A budget can be too broad or not finalized (as you are still making a business plan for the investor) in both cases it is hard to make a decision at such an early point in the process. Sometimes, customers prefer not to specify their maximum budget, in fear that this will fix the valuation at such a borderline, for their company, level.
However, we ask about the budget for another reason - knowing your budget allows us to find the most optimal solution; i.a. if the valuation exceeds your budget - we can suggest, which elements should be replaced or removed to reduce costs without significant changes in user experience, while keeping in mind the most important business goals of your app.
7. What do you already have, what else do you need?
At this stage you should also think about other elements (besides technological and graphic ones) - that are required to put the app on the market. Some elements are necessary at the coding stage (such as microcopy for buttons), others can be put off until the application is published - however, the product’s premiere may be significantly delayed if any element is missing. Including this information in a brief improves cooperation and helps in following and keeping the schedule.
So, have you already planned:
- copywriting, especially microcopy or UX copywriting - all those phrases and hints placed on buttons and in search fields;
- descriptions for stores (Appstore, Google store);
- landing page - a website with information about the app;
- regulations, GDPR clauses, legal audit;
- planned date of implementation and schedule of marketing actions?
8. Technical stuff
It’s time for technical issues. The perfect specification consists of two parts, the first describes everything that has to do with functionality, while the second is all about the technical side. Such a document is prepared or supervised by the programmer, and should comprehensively describe technical standards and specific functionalities.
|
The functional specification contains:
The technical specification includes issues such as:
|
-
a customer has a complete specification - simple situation, we read the document and send the valuation back;
-
a customer has a functionality plan and user paths - based on that, we can define needs and requirements, suggest specific technological solutions and put them in a detailed specification;
-
a customer has a general ideaas a part of design workshop, supported by a programmer and a UX specialist, we work together on a final specification, including a list of views to be designed.
Do you have an idea for an application? Please contact us for a non-committal conversation.
Newsletter
No spam - only valuable content!:
