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

Designing mHealth Apps: Five Areas Not to Miss
stantly visible and we can refer back to it
at all times. This helps us to avoid veering off track.
Almost 8 years ago, when I was first
getting involved in mobile app development, a situation where one of our
designers asked a member of the sales
team;
“Why is the client creating this app?
It seems pointless.”

Once you have the profile defined
(remember you could have several key
profiles), consider starting a workshop.
We’ve just finished an app workshop
with a UK government agency and
recently conducted two app workshops
with the National Children’s Bureau and
The Anna Freud Centre, a leading mental health charity for young people. (you
can read more about how to structure a
workshop at www.integratedchange.net/developing-a-healthcare-app-for-young-people)

The response was, frankly, inadequate.
He simply responded that the client
knew what they wanted. And perhaps
the client did know what they wanted.
But they had failed to take into account
what their customer wanted. And that
brings us onto point 3.
3. Profile, workshop, refinement
user with quick and easy access to the
most common functions of the app.
The lesson here is to make sure that you
keep your designers talking to your developers, clients talking to your account
managers and project managers talking
to everyone. No silos should ever exist.
2. Know the objective and know the
problem
This is one of my favourite aspects of
what I call the design discovery stage.
When we start working with a healthcare client, we validate exactly why they
want to develop an app. Yes, people will
say that they know but once you start to
fire off some direct questions, it soon
becomes apparent that really, they don’t
know. There’s often a significant difference between what a client wants and
what they need and it’s our job to understand the objectives and align these.
Digital can ease, and in some cases solve,
many healthcare problems, from workflow and patient engagement to administrative inefficiencies. But if there isn’t
a problem to solve, why bother? You’ll
simply amass costs and spend a lot of
time on a project unnecessarily.
You have to make sure that the objective
or problem is very clearly defined and,
just like in point 1 above, that everybody
is aware of it. We often pin the core
objective to the wall, so that it is con-

Persona profiling seems to be used as a
fancy buzzword these days but in actual
fact, the concept has been around for
centuries. It still amazes me however,
how little is known about creating a profile of your end user. In a sales environment, if you didn’t have a buyer persona
or ideal customer profile, you would be
flying blind trying to gain business.
The same goes for design. It’s no different. Creating a profile doesn’t have to be
a complex task but you must know who
your end user is, what they want, why
they want it and how they want it to be
delivered.
We have some free templates that you can
use for this exercise for free download
(www.integratedchange.net/webinar-recordinghow-to-write-your-healthcare-app-brief).

At Integrated Change, we are big fans
of workshops. They provide a wealth of
rich information and insights, which you
wouldn’t normally get from other exercises. Once the workshop is complete,
analyse and retest your app design plans.
Then implement what you know and
keep validating. Running a second workshop can help with this.
4. Content
This is such an important part of the
design process and, going forward could
be a key element in helping to get your
app discovered. The actual level or volume of content must be determined
early, along with the tone and language
that you should have determined from
point 3 above.
You don’t want to force users into scrolling endlessly to read huge volumes of
text and you should bear in mind that
Continued on page 26

The Journal of mHealth

25