The Journal of mHealth Vol 2 Issue 4 (August) | Page 26

Designing mHealth Apps: Five Areas Not to Miss

Designing mHealth Apps:
Five Areas Not to Miss
By Scott Hague

ect should be invested in design.

Studies suggest we spend 2 hours and 42
minutes each day using our mobiles, with
some 86% of that time being spent using
mobile apps1. With so much time spent
using applications, it’s no surprise that
users are becoming savvier and savvier.

So, in this post, I’m going to share with
you 5 of the basics that are so often overlooked when designing a mobile app:

Users are no longer new to mobile.
It’s been almost 9 years since the first
iPhone came along and more than 5
years since the first iPad was launched.
Users have seen countless applications in
this time and numerous changes to their
mobile operating systems. With constant
improvements to these mobile operating
systems and apps becoming increasingly
intuitive, it comes as little surprise that
the expectations of users are getting
higher all the time.

First up is getting your teams and stakeholders all lined up, working as a super
slick machine.

That’s great news for me personally. It
means we simply have to keep working
hard to provide the very best user experience designed to meet the objectives
of the end users. If the user experience
isn’t aligned to the user objectives, an
app will quickly fail and there’s the added
potential backlash of a slew of negative
reviews on the App Store and on social
media channels.
Bad user experience design is estimated to
cost users 30 minutes a day. It’s lost time
that users don’t appreciate losing and can
result in lost revenue and brand exposure
for the company behind the app.
There’s a misconception with app development that the development itself is
the most important part of the project. It might be the most expensive, but
it’s by no means the most important in
terms of ensuring the success of your
app. Getting the UX design wrong can
spell disaster for a mhealth app – or any
app for that matter.
Design is about how the app works, not
how it’s programmed. It’s about the people using it, not the code. Development
makes the design a reality. But given
the importance of how an application
works, a significant part of the proj-

24

August 2015

1. Link up your teams and remove
the silos

Developers will need to see the wireframes and any potential graphical mockups produced for the app. What we do at
Integrated Change is produce these first,
before fully committing to any programming cost.
You see, what may look simple could
actually turn out to be a major piece
of development work. For example, we
developed an iOS and Android app for
The Wellington Hospital in London. On
Android however, the style of the various pop-ups and calendar pickers that
were displayed to allow users to perform an action varied between devices;
in some cases massively, as shown below.

What we also discovered is that some
date and time pickers on some Android
devices are separate, whereas we wanted
to combine them both, into one single
pop-up.
Our objective was to create a consistent
and ‘familiar’ brand experience across all
Android devices, essentially forcing our
own pop-ups into the code and bypassing those from the handset manufacturer’s Android layer. This meant that
we had to design and develop custom
pop-ups for Android. Sounds straightforward, right?
Well, it was actually a major piece
of development work, which wasn’t
planned, meaning we had to realign
some of the project milestones.
The result however (as shown above),
is a pop-up that is attractive, easy to use
and consistent across all Android devices
and operating systems.
Custom
ups for
hospital
Android

designed and developed popAndroid allowed a consiste nt
brand experience across all
devices whilst providing the