A software product that aims to provide patients in the United States with better access to their health data, helping them to gain insights and make informed decisions, beginning with pregnancy
Embedded Files
Skills:
Design System Maintenance
Comparable Research
UIUX Design
UX Writing
Usability Testing
Storytelling
Wireframing
Prototyping
Responsive Design
Graphic Design (App Store Assets)
Role:
Product Management and UX Design Intern
Timeline:
May 2023 - Aug 2023
Tools Used:
Figma
Overview
During my internship, I worked on two projects - the ideation and design of the Family History feature in the Trellis Health mobile application, as well as the visual design of assets used for the App Store release.
🍥 Family History App Design Process
The Problem
Patients are given the mental load and stress of trying to fill up their family history form that requires them to fill up a list of health conditions that their relatives have suffered/suffer from whenever they visit a new doctor.
💭 HMW help users to better keep track of their family member’s health conditions?
The Solution
A family tree is being built, allowing users to add, edit and remove relatives. Users can tag several health conditions to their family members. After tagging the diseases to their family members, users can view a list of common diseases that occur among family members in the family tree. This helps individuals gain insight to their present health, understand about the susceptibility of inheriting a disease from their family member and take steps to reduce the probability of inheriting such a disease. Users can also walk into a new clinic and share their family history with their doctors seamlessly, reducing any unnecessary stress and cognitive load before the doctor’s appointment.
User Journey Map
I began to seek to understand the journey that the user takes to fill up the family history form in the clinic, noting the steps, their feelings as well as the pain points that they faced. Thereafter, I added several opportunity points for the steps that did not provide a positive experience for the user.
Competitive Research
A deep dive into several ancestry apps were done. Additionally, I decided to study other applications such as mind maps, drawing applications and maps. I wanted to better understand the human to mobile interaction when using mind maps and how the different features worked. Moreover, the deep dive into drawing applications gave me ideas on several fun interactions that we could replicate in the Family History Design. Lastly, the research into maps gave me the most concrete idea of how we eventually envisioned the product, where users could essentially zoom in and out of the family tree or click on buttons or chips within the family history feature.
Task Flows
Several task flows of major Jobs-to-be-done (JTBD) were crafted.
Wireframing
The family tree begins with a single node and having prompting buttons as part of the skeleton UI to encourage users to add relatives or family members to the family tree. Users can also view family members who suffer from a certain disease by looking at the color of the dot at the bottom of their name.
Viewing Profile – When a user clicks on a node, it becomes outlined and a small modal pops up at the bottom of the screen (similar to Zillow and Airbnb). They can also view full profile when they click on the “Eye” icon, where a bottom sheet containing the user’s full profile appears.
JTBD 1 – Adding a relative
There are two ways to add a relative:
1st interaction: Adding a family member allows users to add information about their family member when they click on the "Add relative" button – Bottom Sheet form or a step-by-step process which prompts users to fill in information about their family members.
2nd interaction: Users can press and hold on a family member to add a relative connected to them. A bottom sheet appears, prompting them on who they would like to add regarding the node or person whom they pressed and held on.
When you add a relative, you can also tag health conditions to the relative. Three methods were designed.
1st design: Users can easily search or pick several conditions from the list of suggested diseases under the search bar.
2nd design: Inspired by ixnote and to make the experience more fun, users can view the list of conditions under a bigger umbrella of a specific disease by scrolling up and down. As the user scrolls up and down, the lines which connects the disease to each condition moves dynamically as well. To select the health condition, the user needs to tap on the condition. They can then click on a button on the top right corner of the screen which will show a summary of the conditions that they have selected. While this experience is fun, this is not a common user experience and requires a lot more resources to develop this application by the software team.
3rd design: Users can click on tabs that represent the various diseases, looking into each tab to select the health condition that they want to tag a family member to. Similarly, they can tap on an icon on the top right corner of the screen to view a summary of conditions they have selected. However, this design requires a lot of time for our users to go through each tab to select the right condition. Moreover, diseases with long names may result in unnecessarily long horizontal scrolling patterns for the end users as they look for the specific disease to investigate.
JTBD 2 – Viewing related conditions
Users will be able to view related conditions between family members. This helps them to understand from whom possible conditions could have been inherited from and raises awareness as to the diseases they may be more susceptible to. Each health condition is being categorized by a different color.
JTBD 3 – Adding a health condition
Adding health condition to the family member allows users to tag a disease to multiple family members at once. Two interactions were being designed.
1st interaction: Users can select one health condition via a bottom sheet that pops up when they tap on “Add a health condition” button. Thereafter, they can tap and select family members to tag the disease to them.
2nd interaction: After users select a certain health condition to tag to their family members, they can drag and drop the condition to each node or icon to tag the specific individual with the health condition. However, this interaction is uncommon and requires more effort on the users end.
Internal Feedback
Viewing of health conditions using dots - Perpetually showing the health conditions that each family member had in the family tree was raised as it can unintentionally serve as a negative connotation for individuals. It may not be necessary, nor may it provide an overall positive user experience when our end users looked at their or their family members health conditions every time they looked at family history. We looked back at the JTBD, questioning if users needed to be able to view their health conditions every time they entered family history. Eventually, we decided to remove the function as viewing health conditions for each family member was not a major task to be done and not a common goal of the end users. Users can only view their health condition and its relatedness to other family members from the “Filter” button. This was reiterated in the high-fidelity prototype.
Implementation of 3 FABs – These FABs were on the top right corner of the screen which was not a common area at which the user could reach when using their mobile phone with one hand. Additionally, it was not recommended (in fact, a crime) to add more than one FAB and FABs in general take up space on the main interface, preventing users from seeing the main information presented to them. Several designs were thought of, an expandable FAB button as well as having a horizontal scroll list of buttons for users to select. Since it wasn’t clear what the heart shaped icon meant, and FABs should only be used if it was clear to users what each icon meant and having expandable FABs resulted in the user having to take more steps to do the same task, we decided to implement the horizontal scroll interaction of buttons where users could “Add relative”, “Filter” to view related conditions, as well as “Add health condition”.
Add relative – Users can fill up information about their family members, including their birthdate, whether they have passed on, their health condition and any additional information that they recall. Users can either add a parent of grandparent using the skeleton UI, “Add relative” button or by pressing and holding onto a family member whom they would like to add to. To add other relatives, they can either tap on the “Add relative” button or press and hold on the family member whom they would like to add a relative to.
Add health condition – Initially we were thinking off adding a toggle button for users to view the list of health conditions that they selected in the Add health condition page, however, with the toggle button, this would suggest that whenever the user chose to turn it on or off, the entire list of health conditions under it would shift up and downwards which would be jarring to the users eye. Hence, we decided to keep a simple counter of the number of health conditions that the user has selected. The user can also scroll through the list of health conditions to view those that the user has selected.
High Fidelity Prototype
After several rounds of feedback and reiterations of the design, a high-fidelity prototype was created.
Two ways to add relative: Press and hold on the family member whom you would like to add a relative to OR “Add relative” button where you must select a family member whom you’d like to add a relative to and fill up the form including information about the relative
Add health condition: Users can tap on the “Add health condition” button. Thereafter, they can search for or select a health condition from the list of common diseases present to tag to multiple family members. Once the family member has been tagged with a certain health condition, the node or icon turns into the color of the disease to notify the user that the node has been selected. They can click on the bottom “Adding <disease name>” to select a new health condition to tag their family members to. This function is autosaved.
Filter: Users can select one disease to view the related conditions that family members have.
View Profile: When users click on a node, a small modal at the bottom appears, allowing users to view the profile of the person whom they have clicked. They can choose to view their full profile or edit that person’s information.
Usability Testing
During the usability test, participants were asked to build a family tree as well as view related conditions. Thereafter, they were asked a few questions before going to the subsequent task of identifying a big family tree and inferring what the relationships between each of the people meant. Lastly, the participants filled up the System Usability Scale survey. Some of the findings are as follows:
- Users had difficulty viewing related conditions, they clicked on themselves instead. They also did not expect to be able to view the connection between family members suffering from the same disease. This suggests there was a mismatch of expectations when they clicked on the “Filter” button and viewing the related conditions afterwards.
o Filter – Copy issue
- Most of the users added relatives and added health condition to the family member when they added a relative, Add health condition is not commonly used and was also not as obvious to them since it required horizontal scroll to notice the button
- Users found it difficult when asked to add distant relatives such as cousins. They clicked “Add relative” and mentioned that they were looking for a “Cousin” option in the bottom sheet. One user even wanted to add her grandparent from Joanne (herself).
o Add cousins/grandparents/more distant relatives option in the bottom sheet while adding relative
- Users took awhile to find the legend which helped them to understand what each different line in the family tree meant
- Past marriage and adopted child dash line is too similar
The feedback from the usability testing has been taken in the next reiteration of the Family History design.
Reflection:
A deep dive into family trees needed to be done to see how we can better represent the visual information of the family tree properly to the end users. Moreover, a list of edge cases such as past marriage, adopted children etc. had to be considered. A lot of research and considering of the edge cases was needed to build an extensive family tree. If I could do this again, one thing that I would change would be to note down the user stories or JTBD before going into wireframing and prototyping. During the design process, we focused a lot on the minute details such as copy and went back and forth thinking about multiple ways that a user can accomplish a single task. I think it is important to always go back and design based on the JTBD. By focusing on the JTBD, we remain user-centered and this helps us to gain clarity and focus on the functions to design based on its priority. Moving forward, more usability tests need to be done and the design needs to undergo several rounds of reiteration before it can be handed off. There also needs to be a consideration of other edge cases such as “What if children find out that they are not actually related to their said parents?” and “What if there are parents who have other children outside of marriage that they do not want to view or have displayed in the family tree?”. Designing a family tree feature is complicated, but there lies so much potential in what the use of this feature can do to help patients gain insights to their own health in the long run.
Several designs and iterations for the app store were being done. Through internal feedback and a company wide voting session, the design was reiterated multiple times and eventually finalized and has been put up in the App Store.
Note: To view/download the app, your App Store region must be set to the United States.
Page updated
Google Sites
Report abuse