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?
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
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.
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.
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...
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]”.|
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.
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%.
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.
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:
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: