After completing my successful projects at Discovery, I was offered an opportunity to switch industries and advise a health startup. A project with the aim to allow easy communication and offer professional support digitally.
ONKO combines the expertise from cancer dieticians, physiotherapists, specialist nurses and psychologists. This combined service has the aim to offer the user a full spectrum of services via the phone app with the support of real healthcare professionals to ensure patients get the very best results.
The general aim of the app is to allow for frequent education, understanding and connected care with data capture points to help you achieve the best quality of life and fastest route to recovery.
This opportunity was huge to me sine I am very interested in the medical tech space a chance to shape and be part of a project that would bring together complicated and sometimes uninviting services and make them easy to understand.
Designing within the new normal.
Since this was was a green field project and I was tasked with leading the overarching product design of it. I started with understanding the aims of the project. What will it be used for. This took some discussion and really was about outlining the requirements.
Generally speaking, I like to start a project on paper, post-it notes, organise workshops, whiteboards sessions and discuss the project and really get a feel for it. This is generally a quick solution to getting a solid understanding of the aims of the users and business objectives.
As we are all living in this new Covid19 work world, these creative opportunities to collaborate have been really challenging but this is were Ive had to say good bye to old software such as Sketch and Omnigraffle and migrate towards Figma and Miro type applications with the addition of Zoom or Teams. – This transformation of my workflow has allowed me to keep the creative exploration progress alive but be in the digital space by the means of digital remote working sessions and design sprints.
The above diagrams have been taken from our collective collaborative miro space. Working in this way remotely allows everyone to clearly understand and gain visibility of the whole app. Allows key stakeholders to view the project in their own time and ask question. Feedback would have been given, reasoning why the structure is how it and how it allows a user and the objective meet their objectives.
One of the key challenges was to create a simple organisation of functions that using can easily navigate between the section but also work in a wider App context of App design. What are users use to, where would they generally already know where to expect to find the account, what should really be in the bottom navigation to again allow to the context switch with out thinking too much.
The above diagrams illustrate the in detail how the use-flow is completed to create a user’s goal. This further illustrates all the business objectives that are tied into the the users objectives.
When thinking about the userflow and user expectations within health and app quite quickly we come to the realisation that users (base on Qual research) always want their experiences to be personalised and as a designer this make total sense, that a users data should reflexed in the app. Health is is ultimately extremely personal.
For this reason, it was always connived that the app would take in data from hardware devices, on device frameworks such as Healthkit and Account linking data via Api linking.
With this in mind and clear product direction for the use of this data we could start advising users on their next actions to take or if there were up coming actions to be taken.
The following two wireframe and functional spec are taken from the Wireframes for Dev document to outline and give clarity how we want to handle and manage a users personal data. This also illustrates and gives the user a space to understand how the data is flowing from sensors into the App it self. Furthermore this is also a space to manage the user’s Apple based sensors such as the Apple watch such as heart rate or blood oxygen amount or more general health kit data such are activity amount.
Phone based and API based Health data sets.
On the key aims of the project from business and user point of view was enable users and the business to make discussions based on user data. For this reason it was critical to understand what the possibilities of each data set was capable going. Where he data was coming from and what choices we could make based on it.
Starting off with Healthkit, I gathered all the possible categories and data points such as Heart Rate, Steps taken or Blood Oxygen and listed them and the worked closely with the Product Owner to explain what they could do with this data. Having the understanding of what was technically possible helped me and the PO and the Devs to work together and craft ideas that could be actually useful to user. This was repeated with Fit API.
Moving away from embedded phone Health data, I started to look into Wearables but specially Health devices that could gather data for the app. This was here I started to look into FitbitOS & API and Strava API. The process whilst different than Health Kit or Fit API was similar, both need the user to authentic and grant access. From here the app can start making calculations.
Other than explaining these facts to my PO and my key stakeholders, I started to explain and experiment with the API’s directly. Whilst as a designer I don’t have access to everything the Devs have but I do have access to Fitbit’s API data. This lets me understand the structure of the data available and allows me to start to use myself and in my own experiments with with the help of Origami Studio and the Network patch.
Understanding how the tokens work with an API lets me better understand the limitations of the platform I am building, whether that is a default platform such as iOS or a hardware device connected to the phone or watch.
The creative progress once we had outlined the key functionality was relatively straight forward. We had a lovely brand designer who had crafted ONKO’s brand with key colours and the transition into UI exploration was seemless. Below are section of screens designed for the ONKO.