Towards a mobile development process that works

April 26, 2016

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.

  1. Know your customer. Get as much information from your customer as possible. What kind of projects he did before, experience with other developers, amount of users of the products in the market, etc. This information will help you figure out the kind of person you are willing to work with and also his expectations toward the services you will provide.
  2. Is it necessary building a mobile app at all? Many customers will knock your door asking to build an app for them. From all these customers, a notable amount will feel the artificial need of having an app for their business, just because nowadays having an own app is the trend. In this situation, it is your duty to inform your customer and maybe let him know about other alternatives that could suit him better. Don’t think of doing this as a way of loosing a potential project, but rather as a way of gaining the trust of your future customer and building a rich customer relationship. This will bring you better profits in the long term.
  3. At this point, you and your customer know that a mobile app is the way to go in order to solve the problem or build a specific product. Now is the time to dig deeper and suck as much information from the domain problem as possible. Don’t forget to keep the different users in mind, because they will decide in the end when and how to use your solution.
  4. Forget about the code. Try to organise the information that will be handled by the app and create a first interaction map for the different screens. You can use paper or a software tool for building a map. The output of this step should give you a first idea of how to navigate the information and the usability of the app.
  5. Once you have an initial idea of the information flow, you can start focusing on the different screens. Try to think about the information that should be displayed and how the user should interact with the functionality. A very quick method of materialising ideas is by using sketches or wireframes.
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!