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 she wants to build (the IKIWISI effect or “I’ll know it when I see it”). Therefore it is your job to guide her 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 to your customer. However, taking this step is necessary to warranty an acceptable level of quality.

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 live 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 they 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 their expectations toward the services you will provide.

2. Is it necessary building a mobile app at all?

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 them know about other alternatives that could suit them 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. Know your customer’s domain

At this point, you and your customer know that a mobile app is the way to go in order to solve the problem or to build a specific product. Now is the time to dig deeper and get 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 (for now)

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. Think about UI/UX

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 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.

6. Iterate and refine

It should be clear that steps 4 and 5 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.

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 coded. Note that the idea is to build little chunks of functionality and get feedback from your costumer and users as soon as possible.

At the end of the process we guarantee that the product we release suits the expectations of our customer. This is only possible if she 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.