11 days, 14 hours, 48
minutes and 19 seconds
till my Churchill Trip - 11th May - 13th July 2012
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
