Your personal health and travel assistant v.2.0.
After my first design sprint at BlueDot, I decided to conduct another round of testing, using some of the knowledge I gathered during my first study. I also had the chance to work on and improve some of my shortcomings during my first round of testing, such as my lack of gathering quantifiable statistics.
I felt that I was a bit too idealistic in my first sprint, and decided to focus on something more reasonable for my second sprint.
From my first sprint, the most resounding conclusion that I came to was that chatbots was perhaps the wrong way to go about this. While I personally thought that talking to a chatbot meant interactive and engaging, I was wrong about the general user perception. Also, I was very naive in believing that it would be possible to make a dent on how our target audience would view themselves or their risk of infectious diseases.
After probing and brainstorming, certain conclusions were reached:
The target audience of the application were smartphone users. However, this is mainly due to technical limitations; ideally, information would be spread to everyone. People without smartphones also travel, and that provides a large gap in use cases, which are potentially the most dangerous. For example, if someone from a first world country travels to a third world country, if the user uses the application, they can be aware and alerted to potential dangers. However, if the inverse were to happen, disastrous side-effects could happen.
In this case, logically thinking, only users from fairly developed countries (or lucky individuals in lesser developed countries) would be able to access a smartphone and thus, the app. However, in these developed countries, healthcare systems are also more advanced and more regulated, meaning the general health of the population tends to be quite high and suppression of infectious diseases is already in place. The same cannot be said for lesser developed countries, where resources are limited. Because the target market of the application (from a technical limitation only) comes from an area where they tend to be detached from the true horrors of infectious diseases and epidemics (most of the time), it makes sense that they wouldn’t care.
Health is often a low priority for people because good health is invisible. People only notice the state of their wellbeing if something goes awry. But because good health is invisible, it tends to fade in the background. In the same sense, tracking apps are successful because they collect data to visualize patterns in the hopes of bettering the user. But users have to be conscious and diligent about tracking their habits, and unfortunately, given the circumstances, infectious diseases and vaccinations are often not front and centre of users’ thought processes.
Planning & Conceptualization
Long Term Goal: To help users be more aware of travel and health risks before travelling.
How can we convince users about the potential dangers of travel (raise awareness, trust)?
How can we encourage users to see the big picture of travel?
How can we implicitly push users to use this application over other sources, such as Google or other applications? What can we offer as an incentive?
Compared to Pip
Because of the adverse reaction to chatbots and the request for manual entry, I decided to bring back the ability to control inputs and take out the ambiguity of a chatbot.
From brainstorming with others and from conducting my own research, it was agreed that users would not care about infectious diseases and vaccination unless it was directly tied to something more favourable, such as travel. It was just poorly executed in Pip.
Onboarding, which included the welcome screens, login process, and general tutorials.
Travel, which allowed users to search up location, view general country statistics, access a “Near Me” map, and bookmark specific landmarks. Users were also given the option to save trips.
Vaccination, which corresponded to saved trips. Vaccination suggestions would pop up, and the user would be alerted as to which one would correspond to which location, as well as the lifetime of the vaccine.
Profile, where users could personalize their health history as well as see small statistics such as the number of places travelled, the number of vaccinations taken, etc…
Mockups & Prototype
I was particularly inspired by the friendliness of DropBox (especially the on boarding screen), the help tips from Google, and the map feature from W for Wiki.
User Testing & Results
Once again, I recruited 7 users within BlueDot to assist me in testing my prototype. Some of them were fresh testers, others were returning testers who were able to compare the two prototypes.
Testers rated themselves on the higher half of 1-10 in terms of health-consciousness.
Every user had a different favourite application, meaning that each user prioritizes different functions in their daily lives. Of them, only one person said he enjoyed using chatbots, and another said she would use her mobile OneNote application even if she was sitting in front of her laptop. Otherwise, everyone else stated that they would rather prefer the desktop version of their favourite app.
Despite being fairly health conscious as a whole (I work at a health company), my users were reluctant to see a doctor unless absolutely necessary. Self-diagnosis and asking for advice were prevalent answers.
From this, I understood that:
I was testing a very niche market; of course the infectious disease researchers would care about infectious diseases. It’s part of their job.
However, despite being health-conscious, they preferred to stave off their illnesses unless “it’s debilitating with potentially morbid results.” Because information is so readily available, it becomes an issue of “how can we encourage users to use our application if they won’t even see a doctor because they can Google everything?”
Each user has different needs. Some liked reading Reddit, others preferred social media apps. Most users only use their apps as a means of convenience; why would people use BlueDot’s application if most people have computers these days? What incentive is required?
Two tasks were asked:
If you were interested in going to Bali, Indonesia, how would you search and add the trip?
How would you add personal information regarding your medical history?
Each user had a 100% success rate for either of the two tasks asked. Because of prototype limitations, the user did not always go back into the application to demonstrate the tasks, but were able to easily point out steps from memory.
This time, quantifiable statistics were gathered.
Idea: the idea of the application or application function.
Usefulness: do you see a use/market for this application or application function?
Usage: would you personally use this?
“This app is mildly useful; do people really use apps for this? I would assume you would have to be kind of paranoid to use this.”
“The vaccinations feature was a bit tucked away, the connection between that and trips wasn’t clear. Overall, a bit clunky.”
“The health focus isn’t too clear to me; what is the bottom line to do before a trip? Will it tell me flat out what I need to worry?"
In comparison to my first sprint, I would consider this more successful in terms of validating my initial hypothesis and improving on my shortcomings. I gathered much more quantifiable data, understood my user needs more, and received more favourable responses. 100% of my returning testers preferred Pupper over Pip.
After conducting this second sprint, it is clear that the issue that I am failing to directly target is not something I can control, but is embedded within societal thinking. I was already testing a niche market of people who are educated and aware of infectious diseases. However, even they exuded a reluctance to see medical professionals because they felt that they were so detached from the infectious disease scene for it to really matter.