Google Health
Humanizing Healthcare
Overview
This Google X BrainStation hackathon winning project, was a functional Android native app my team created to help low income families make informed decisions with regard to health insurance.
Project Type: Google x BrainStation 24 Hr. Hackathon
My Roles: UX Designer
Timeline: 24 Hours
Tools: Figma, Slack, Zoom
The Challenge
Picking a health insurance can be a confusing and frustrating process. People make decisions based on incomplete, perplexing and inconsistent information. The challenges continue even after they've chosen a plan in the form of finding in-network services & availability for patients. Mistaking the understanding of insurance coverage can be incredibly expensive.
Research has shown that more engaged and informed patients could improve health outcomes, lead to better patient care and lower healthcare cost.
How Might We
create meaningful solutions to improve our communities’ access to healthcare services?
Our Team
The brainy bunch
Data Scientists: Prasann Ranade, Elliot Chuh
Web Developers: Patrik Ziajski,Hassan Niazi
UX Designers: Shannon Wackett, Emilie Mazurek, Mark Eugster & I
Digital Marketer: Charlie Caldwell
Understand
& Ideate
Our Strategy
Divide
& Conquer
Build & Pitch
-
Project brief from Google
-
Team Standup
-
Brainstorming
-
Voting
-
Data Scientists
-
UX Design
-
Web Development
-
Digital Marketing
-
Submission deck
-
Script writing
-
Practice
-
Present
@0 Hrs
@ 17Hrs
@24 Hrs
Our Approach
Optimize Time
With only 24h in hand, we knew that optimising time and workload management would be critical
Collaborate
The entire team accounted for the time & space each sub division would require to complete their section of the project. Thereby allowing seamless collaboration
Leverage Skillsets
Every single person on the team leveraged their strengths to create the strongest deliverable
Enjoy
More than anything, all of us really wanted to do our best and learn new things without sacrificing our sanity and pulling all-nighters
Understand & Ideate
Research & Insights
Since we only had 24 hrs to work on the project, we decided to check the data for insights.
Our data scientists found that there was a clear relationship between uninsured individuals and families living under the poverty line, so we came to the consensus that accessibility to health insurance had great potential for further exploration.
Insights:
1. People make health insurance decisions based on incomplete information
2. Health insurance information is portrayed in a very complicated & confusing manner
3. Finding in-network services & availability for patients can is challenging
To address these problems, we reframed our design question to:
How might we
improve community health insurance access to ensure patients find network services
in their budget?
Persona
To make sure we make all design decisions keeping in mind who we were designing for, we created a proto-persona.
User Stories
To make sure that we develop features and functionalities that best address the consumers pain points, and so all the stakeholders are on the same page, we articulated user stories. Here's a peek at 3 key user stories
As a shopper, I want to find the best match insurance policy so that I don’t have to waste time browsing irrelevant options
As a shopper, I want to see all my options so that I make the best choice for me
As a shopper, I want to understand complex terminology so that I know exactly what the policy means
A simple onboarding so that the user can choose from appropriate health insurance matches.
A library of health insurance matches for the users to make an informed decision
A way for users to understand complicated vocabulary through simple definition
Divide & Conquer
Sketching
Being mindful of the time, we selected a task flow and built out the screens based on our user stories. I sketched out a few options to visualise what the functionalities would look like.
I sketched out the 3 main screens:
-
Onboarding Screens
These screens capture the needs and wants of the user and then the matches based on these needs -
Options Screen
This screen displays options along with necessary info in easily digestible format -
Comprehend Terminology
Users can easily understand the meaning of complicated words in insurance policies so they can make informed choices.
Asset Collection
Once we had all finalised on the layout of the screens, it was time to create a high-fidelity prototype in neck break speed as the web developers were patiently waiting to start with the development part!
Since we were building for Google, it was important that we adhered to the Material Design Guidelines.
Aaaaaand...it was finally time to put all pieces of the puzzle together and dazzle the panel ;)
Build & Pitch
To see how all the pieces of the puzzle interlocked to build a solution that would greatly benefit the low in come families looking for a perfect health insurance plan, feel free to play with the prototype.
Just to give you some context, imagine that you're trying to explore and quickly find the best health insurance plan.
Key Learnings
And just like that, 24 hours were over! It was now time to present our hard-work to the the Google panel, consisting of Brooke Conway, Dan Brown & James Campbell.
In just 4 mins., we needed to:
-
Explain the process
-
Share the key idea
-
Show a walk through of the prototype,
-
Pitch our solution
Presentation
-
Push your limits
Although 24 hrs seemed intimidating at first, with the right planning and by stepping out of our comfort zone, we were able to accomplish a big deal. Previously, I had never designed for Android, but this hackathon pushed me to research, learn & grow. Other than that I also got the opportunity to collaborate with other departments and understand how they work.
-
Sometimes the answer is right in front of you
When we were presented with the challenge, we were super excited and went all out on the solutions that we could develop. We really did some blue-sky thinking. But we quickly got back on track and looked into our data set to find that the answer was right in front of us all along, within the data itself.
-
If you design for everyone, you design for no one
It was very tempting to help as many people as possible with one solution. But I soon realised that is just a recipe for disaster. It made more sense to solve problems for a specific set of people in the best way possible rather than do a half baked job for everyone.