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