What is different in developing applications for mobile devices?

11 days, 14 hours, 48 minutes and 19 seconds
till my Churchill Trip - 11th May - 13th July 2012

Is there a difference in the way we develop applications for mobile devices?

Some would say no, but I believe that the whole process of mobile application development has started to change in quite a big way. I don't believe that it just a matter of better delivery of content and function of larger screen devices to work in a smaller foot print. As Steve Jobs said many years ago "Think different".

We are now starting to see the whole concept of User Centric Design take a far great role in this area. Companies are tired of systems that require major levels of training, it is a major cost and keeps people form doing their work. Technology was supposed to make our lives easier, in most cases it has created even more complexity. More of today's mobile application development and design philosophy is creating application that are simple and intuitive. This has resulted in less training and freeing people to do more of what they need to do in getting their work done. 

For many years business has abdicated its responsibility in this area. Sighting that it was two complex and that the technical people or developers knew best. Well the developers did know their stuff in the area of application development but there were not many that understood business and how critical the proven and tested processes and practices made their business sustainable.

I remember an experience where I was reviewing systems that ran many functions a local government body. One of those processes was to register a dog. A simple task I hear you say. Well in this application it took no lest that 72 steps. To register the owner, then register the dog against that owner. There were so many different areas and places to navigate and then you could not simple move on you had to reverse up to then dig down into another area. Does this remind you of any application you have had to use?

We hear the stories when these systems are installed that entire business processes which have been proven and tested over the years are having to be changes to align with the technology. In some cases this has been good for a business, especially when there were no defined processes. But in other cases good solid practices and processes have been thrown out for the sake of technology. Business had thought that it must be good, because it was the latest and other companies or organisations had done it. 

The good news is the tide is turning in many ways. Once we have seen that it can be made easy and intuitive. Apple has shown this with their designs and how their applications work together. They require little if any training and people are up and working with the technology. The most interesting part is that the technology has become transparent. If you talk to owners of iPhone's and iPad's they will talk to you about what they do and how they create things. There is no discussion on the underlying technology. They just use it. 

I always try to have systems pass the "mum test". If I can get my mother to look at a system and explain to me how it works then it passes. No, I don't live with my mother but it is the analogy I am trying to get across. Systems need to be designed with the idea that the end user most of the time does not understand the technology, systems or applications. All they want to do is their job quickly and efficiently. They have a job to do and need to get it done. 

So designing systems that are aligned with their current practices and processes makes far greater sense. Understanding the processes which an end user is familiar with and then designing around that reduces the need for training. How? Well if the processes are well founded and structure when they get to use such a system designed around those processes they already know the next step.

So you ask; how do we do this type of application development?

This I believe requires a re-think in our approach to gathering the information for this type of development. We need to engage in the science of Usability and User Centric Design (UX). We need to analyse and use the skills of Business Analysis. If there is one role which many developers don't appreciate and understand it is the role of a good Business Analysis. 

First up let’s put a definition of what is not a Business Analyst. That is someone who has been in software development or technology and woke up and decided to refer to themselves as a Business Analyst, and then express their years in the industry as years of experience as a Business Analyst. This IS NOT a Business Analyst . 

A Business Analyst is a specialised skill set. A Business Analyst can work in many different fields and usually has extensive business process experience. The skill they bring to the table is understanding processes, identification of those processes and being able to articulate them in such a way that both the business and developers understand what is to be achieved. 

This skill set is transferable across many industries and as the industry content is not what is being reviewed and documented. The most important skill is their ability to raise questions that the business did not know needed to be asked or answered. 

Now that we have an understanding of what I believe is a Business Analyst, the next part in mobile application development is understand the processes. I believe this to be paramount in the cycle and have often been neglected. That is talking to and understands the end user. Identifying who they are and what and how they currently do their work. Having a true understand of their current processes, then working with those processes to clarify, document and if needed streamline. Once this exercise has been done when the application is finally ready to deliver there is less resistance to change and adoption of the new application.

Many time developer tend to try and change the inefficiencies they perceive via the application.  If these are identified then they should be feed back to the Business Analyst to go back to the process to clarify and confirm, adapt and change then modify the application. Doing this in the application without end user involvement results in resistance to adoption and a breakdown of the relationship.

The process of making changes via the application and not via the physical process has been the practice in the past and is still practices by some developers. 

Business in the past has ended up accepting this process and way of application development because they did not feel empowered enough to push back. We times are a changing and business is starting to question the so call experts. 

How much easier would it have been if these modifications were identified and proven in the field so to speak, before pushing them through with a new application. It would have reduced resistance, adoption and training as they would already have been in place.

The other area in mobile application development is the logic of processes. Some processes require an order some don't. The main thing is change is inevitable. Locking a system down which required costly expense to modify just creates conflict. The whole idea of process and flows is the need to remember that applications do a number of things. The collect data and then apply business rules or flows. Again in understanding the processes currently in place application developers can take valuable lessons and apply them. 

So if we identify the containers and then apply the business rule or process, keeping these distinct we can then always modify. The problem comes when systems are written in such a way that the containers, business rules and processes are so intertwined they become very expensive to manage and maintain. And when it comes to the time to upgrade and improve the underlying systems business finds that it is required to start again and rebuild. But that is not until they have forked out considerable expense in obtaining the system in the first place.

What happens under the cover the users usually does not care. To some developers that can be distressing, well as the business or end user is paying I think that some developers need to get a thicker skin. 

From the end user perspective if it looks right and the output is delivering the expected result, the process is aligned to a proven and practices process which reduces training then I believe you will have far more success in the delivery of business Mobile Application Development. But most importantly change is inevitable and any system that cannot adapt with that change is a waste of money.

There are three questions that business should always apply to any technology to understand if it has any value for their business. They are:

1. Does it save me time?

2. Does it save me money? or 

3. Does it save me time and money.

Anything else is just a gimmick