The Journal of mHealth Vol 2 Issue 4 (August) | Page 28
Designing mHealth Apps: Five Areas Not to Miss
Continued from page 25
the amount of text will also determine
the layout of the screens and placement
of calls to action or other action related
buttons.
As an example, we created an app to
allow consultants to book ad-hoc theatre
space for patients. The page contained
several paragraphs of text advising on
the process preceding the ‘book theatre’
space button.
On an iPhone 5 and above, this posed
no issue, but on an iPhone 4s, the button wasn’t visible and the last paragraph
ended perfectly right (unintentionally)
at the bottom of the screen – because
of this, it wasn’t obvious for the user to
scroll down.
Once the content is in place, make sure
that it reads well, is relevant to the app or
screen and that there are no spelling mistakes. When we develop mobile apps for
healthcare professionals, we check and
double-check the spelling and grammar
and then check it again.
Here is a great example: Which one looks
correct and would you notice instantly?
‘general practitioner’ or
‘general practioner’
Some may notice instantly but on the
whole and according to research at Cambridge University2, the human mind
does not read every letter by itself but
the word as a whole. The sentence could
be a total mess but you could still read it
without issue.
I urge you to check and double check
and get somebody else to do this also.
My view is that spelling mistakes like this
can be embarrassing and lose you hard
earned credibility, especially if you are
targeting a general practitioner!
And on the note of content, make sure
you have all of the pop-ups covered
too. Aspects such as no connection or
returned server error messages should
be clear, well written and simple to
understand. Here are a few examples
where they missed that point totally; to
the user, they provide nothing but
confusion and irritation.
26
August 2015
5. Prototype it
Waiting for the app to be programmed
to gain feedback is a waste of time. You
could gain feedback really quickly by creating a non-functioning prototype that
just allows you to validate the user journey with the end users.
Providing feedback to something on paper
is very different to having it in your own
hands, using it and providing feedback–it’s
a whole different setup and mind-set.
Whilst prototyping may add cost initially,
certainly in the early stage of the project,
it’s definitely going to save you further
down line.
There are many ways to prototype an
app. We are big advocates of Form (www.
relativewave.com/form) and inVISION
(www.invisionapp.com). They both allow
you to build a small section of your app
prototype, gain feedback and then rapidly make a change before signing off.
Prototyping will help to make sure that
you have the most commonly used elements in the right place (such as key
action buttons - at the bottom to the
right) and aspects such as placing the
back or cancel button in the top left, as
this is furthest point away from where
the hand rests. Additionally, prototyping
will help to determine the page depth of
the app. Generally, users shouldn’t go
any further than three pages into the app
before having to press ‘back’.
Summary
We could have listed several more points
in this post but for us, these are the most
common points in designing an app that
are missed. In summary, what we have
listed here isn’t really rocket science and
it isn’t anything new. It doesn’t need to be.
It’s all too easy to forget about why the
app is being created, end up changing
lanes and move in a direction that is going
to take you on a completely different
route. If you do this, you’ll miss the objective and wonder why engagement is low.
Of course, you can’t please everyone
but do you need to? Facebook releases
updates to its app every two weeks. But
Facebook has the vast cash reserves to
do so and a phenomenally broad user
base of varied ages, demographics and
social backgrounds.
For the healthcare space and for you
reading this post, that doesn’t apply. But
equally it doesn’t mean that you must
forego spending more time on design discovery than any other part of the project.
References
1. http://www.adweek.com/socialtimes/
mobile-users-spend-86-time-apps-32gaming-17-facebook/146991
2. http://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/
About the Author
Scott Hague is Development Director
and Owner of London based Digital
Healthcare Agency Integrated Change.
Working with the likes of NHS England,
Parkinson’s UK and Europe’s largest Private Hospital, The Wellington Hospital,
Integrated Change specialise in designing and developing mobile applications
exclusively for the healthcare industry.
@integratedchg
[email protected]
www.integratedchange.net n