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 scott@integratedchange.net www.integratedchange.net n