Product Designer

Medical app


The problem

Melon health's application has existed for a number of years. However, the iOS version of the application was notably our weakest product. Due to a shakey codebase we put a feature freeze on it, and users the iOS application grew to have a less-and-less up to date and buggy version of our product.

The problem presented a great opportunity to the team. We took the failings of the iOS application as an opportunity to redesign the entire application from scratch. and look critically at what it does and how it works.

Redesigning a health application

The core purpose of the application is for people with chronic conditions to self-manange their health. We cater to a variety of chronic conditions that more or less use the same design and flow.

The core fundament of the application is:

Helping people help themselves.

In terms of features, this includes things such as:

  • condition-specific medical tracking, and displaying of tracked medical values in a useful way
  • ability to chat and video call with a medical professional within the application
  • ability to engage in a private community of people with the same chronic condition as you
  • ability to set reminders, enter which medication you're taking, upload and view medical records, list your medical team, etc.
  • ability to learn about my condition through a structured or unstructured programme of content
  • ability to get urgent help or tips in dealing with a crisis
  • other secondary features such as user profiles, notifications, activity, about the application, legal, etc.

The application also has different 'power' features for admin-level users, such as coaches or nurses who monitor the community.

The app has always existed in the form of native mobile applications (iOS, Android) plus a responsive web app. The idea is that the user should be able to access the same content and have a great experience no matter what device they're on. This is especially essential for things like medical tracking, which often have to be done throughout the day.


Constraints and opportunities

There were some pretty significant constraints in what the iOS application had to do. As we were rebuilding an application that was already actively being used by users in the middle of various medical trials, any significant feature changes were out of the question.

The application also had to integrate with existing Android and web applications, and talk to the same API.

The was, however, a lot of a great opportunities to rebrand and improve the UX of the application in general. For the first time, the iOS was going to lead rather than follow.

The most important opportunity was the ability to test the new look and feel and UX in the isolated environment of iOS and learning before rolling it out to Android and web.


First steps: information architecture

The first steps I took in the re-design is an audit of all the features and functionalities divorced of screens.

I evaulated that many of our features do not especially support the core mission of helping people help themselves. Other features supported that mission but were only things you wouldn't need to access very often.

The prompted me to reorganise the navigation into "things I want to see every time I open the app" and "things I only need to see every once in a while".



To support the distinction between primary and secondary features, I reorganised the menu structure to support "everyday features" versus "every once in a while features". Everyday features were accessible via the tab bar whereas the secondary features were semi-hidden behind a hamburger menu.

"If your site has more than 4 top-level navigation links, the only reasonable solution is to hide some of these. We did find that the usability penalty imposed by hidden navigation is very present on mobile, but it is smaller than on the desktop. Thus, we recommend making this design tradeoff because the usability of an expandable navigation menu is far better than that of alternative designs." -Nielsen group

Testing, learning

I was able to conduct four tests with users over a period of about half a year. To conduct these user tests, I iterated on prototypes that started pretty low-fidelity (thus low investment of time) and each iteration increased the fidelity. Towards the end, users interacted with a click prototype that was fully designed, visuals and all. 

slide 1.png

To help ensure I was getting useful insights, I wrote a script and outlined a few simple tasks I had users complete. 

Screen Shot 2017-11-18 at 15.31.59.png

After testing with about 20 people and reviewing the videos, I was able to pull out some very useful insights - everything from UX that was unclear to features they'd like to see.

slide 2@2x.png

One of the main points of feedback was the interface demanded too much focus on reading. The target user group was people with low tech literacy and often people with cognitive impairments, so an obvious interface with strong visual cues was key. 

old v new 1.png


Due to working with people with chronic conditions, it was also crucial that the app was accessible to people with people with visual impairments. This meant using a large typeface, and ensuring interactive elements (such as links, buttons, etc.) had a clear a visual cue. To help check that my colour pallet was meeting correct standards, I used a variety of tools, such as and Sim Daltonism.

Screen Shot 2017-09-28 at 15.03.00.png

UX validation 

Screen Shot 2017-11-18 at 15.49.16.png

Sometimes you need some quick insights with a large sample size.

To test basic UX, I used tools such as usability hub, which allowed me to A/B test, test the logic of flows and where to click. The above image is an example of heat reading on where people would click to add a new photo.


Branding, details

With the flow becoming more and more solid, it was time to apply the existing branding over the new visual style. This presented an interesting challenge, as we have many apps which are about 90% similar. Each app had subtle variations in features depending on which condition(s) the user has. 

ia copy.png

Light UI, Dark UI

One of the most interesting parts of the apps visual design is the mixture of a light and dark UI. Normally, I stay away from designing dark UIs, unless there's a good reason for it. The research is pretty clear that legibility decreases when light text is on a dark background. There are also additional factors like legibility in the sun, which is a concern with a mobile application. 


However, I found it important that all features were extremely clear in this application, with visually obvious cues (and often sacrificed aesthetic for function). The app had an incredible amount of features, which I had no power to change due to the constraints of being actively used by an existing batch of users. To further make explicit that those features were secondary, branded all of those features with a dark UI. The features you should be using on a daily basis are branded with a light UI.  



I made sure to create documentation sheets for the developers to reference detailing non-obvious interactions that couldn't be shown in a prototype or through Zeplin. Subtle details can make or break the user experience.

Screen Shot 2017-11-27 at 17.26.24.png

Wins, more testing

After documentation, the designs were handed off of the developers who rebuilt the app from scratch. The difference was huge: the new version of the app was faster, more responsive, and felt more modern. This isn't much of a surprise when you compare the stats of the old app and the new app:

Lines of code

or when you compare the number of files:

Number of files

Releasing the new app to our existing users will allow us to learn a lot by collecting user analytics and recognising based on the wins and pitfalls. Due to the codebase being so much more stable, we're able to learn from our users and iterate much more quickly. 


Currently, we're releasing a new version of the application every two weeks, and will continue to learn from our users.