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