Very often you get new customers requiring your services for building a mobile app from scratch. Apart of the technological difficulties, the worst enemy of this kind of projects is transforming your customer’s idea into a tangible product. Unfortunately, in most of the cases your customer doesn’t really know what he wants to build (the IKIWISI effect or “I’ll know it when I see it”). Therefore it is your job to guide him and collaborate closely in order to make a good app. This, of course, requires time and effort, which increases the cost of development and should be communicated straight ahead to your customer. Take the chance to show your costumers that you aren’t a code monkey, but rather an engineer and as such you care about the stuff you are building.
Very rarely you will be getting projects for which your customer knows completely beforehand what kind of app and the functionality that needs to be built. For those cases, the project will mostly consist on migrating an existing app from one platform to another or maybe just adding a little functionality extension to an existing codebase. For the majority of the cases, in which customers do not really know what they want to build exactly, you will learn that in order to improve the quality of the final product and the level of satisfaction of your customer you should implement a development process that involves the potential users of the app from the beginning.
In this post we share with you the process we have implemented at 6020 peaks. It does not mean this is the best development process for making mobile apps, but it is one we have built after interacting with customers coming from different domains. In fact, it is a changing process that we try to improve every time we learn a better way of doing things.
If a multi-platform solution is required and you go native, then focus on one platform first. So, let’s say you focus on Android, start by creating wireframes of the different screens and pay attention to the user interaction. You can use a resource like <a href="http://www.interfacesketch.com" target="_blank">interface sketch</a> as template for your wireframes. 6. If you know the structure of the different screens, you can start thinking on design: what colours, styles, fonts, graphic assets, etc. Think about the potential issues of requiring a design for multiple screen sizes. If that’s your case, then focus on one kind of device, i.e., a mobile phone or tablet. Once you get a clear overview of the screen flow for one kind of device and it has been validated by the customer, then you are in a good place to replicate the design to other devices. 7. It should be clear that steps 4, 5 and 6 are iterative and therefore you need to refine the outcome as much as possible together with your customer and ideally with users. A good way of facilitating the discussions and try to get more feedback before coding is to build a prototype that puts together all the information collected in the previous steps. For this purpose we rely on <a href="http://www.axure.com" target="_blank">Axure RP</a>. This tool helps us creating a HTML interactive prototype that we can share with our customer and refine the product in a very early stage. 8. Now we can start developing! In this phase, our customer has validated the prototype and we are all in the same page when referring to what kind of product will be released. Note that the idea is to build little chunks of functionality and get feedback from your costumer and users as soon as possible. For doing so we rely on <a href="https://en.wikipedia.org/wiki/Scrum_(software_development)" target="_blank">Scrum</a>.
At the end of the process we guarantee that the product we release suits the expectations of our customer. This is only possible if he knows what is going on at every stage of the development.
Do you use a different approach for building mobile apps? What kind of tools are you using? We look forward to hearing from you in the comments!