Between my two sprints, I had a brainstorm session with the design team regarding the features, functionalities, and target audience that we should focus on. From here, certain conclusions were reached:
The target audience of the application heavily consisted of smartphone users. While primarily due to technical limitations (how can people access this app without a phone?) this lead to certain implications, such as the socio-economic demographic of the audience and thus the healthcare systems available. It was also highlighted during the thought exchange session that health is often a low priority for people because it is something that is taken for granted. Users having to be conscious and diligent about tracking their habits is not ideal, and unfortunately, given the circumstances, infectious diseases and vaccinations are often not front and centre of users’ thought processes.
Once again, I followed a modified version of the Google Ventures Design Sprint method. However, after brainstorming and seeing the failure of my previous sprint due to my idealism, I reformed my goals and questions.
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?
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.
The main features that were tested included onboarding (which included the welcome screens, login process, and general tutorials), travel (which allowed users to search up attractions and bookmark them), vaccination (which was synced to locations and past trips), and profile (which allowed users to personalize their health profiles).
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.
Amongst more specific results, I understood that I was testing a very niche market of researchers already well-versed in the realm of infectious diseases. 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?”
Despite my qualms, my users reported no difficulties in using the application. The user flow was well-mapped out, but there was the overarching concern that this was not a health-centric application. It was more travel-related than anything, and when asked for quantifiable data and rankings, this sprint did not end up ranking very high.
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.