Updating the Babylon Health triage design language

The challenge
The Babylon triage experience on both web and app needed to be updated to match the newly defined design language. The experience did not have a dedicated design team and had an inconsistent design language that contained old fonts, colours, components and iconography.
Search for a symptom screen on the old triage experience. The screen leads with a question asking the user “ok, what symptom would you like to check?” Followed by a text field to enter your a symptom the user may be suffering from
Search for a symptom screen on the old triage experience.
A screen from the old triage experience asking the user a question. The question asks “Have you injured your finger recently?”, followed by 3 possible answers; yes, no and I don’t know
A screen from the old triage experience asking the user a question.
This project was just about updating the design language. Unfortunately, we didn’t have the time or resources to make wholesale changes to the content or user experience. However, we could improve aspects of the experience by making the interface easier to use and consistent with the updated design components and design language.

One of the biggest challenges was to ensure that the design worked seamlessly across web and app. The app would use the same web experience, so it was fundamental that the design didn’t look or feel like a web product within the app.
What changes did I make?
Listening to the research
The existing product automatically shifted users to the following screen after selecting an option. While this moved users through the process, it was quickly deemed flawed. Our research team had insights that informed us many users were missing options that didn’t fit into the landing view of their device. As a result some users were not scrolling to see all the possible options and therefore would make a choice based upon what they could see in view. This was common on questions were users can only select one option from a list.

To help resolve this we made it mandatory for a submit button to be included after the last option, regardless if the user could select one or multiple options. This would mean users would have to scroll to see all their options before submitting and progressing.
A screen from the old triage experience asking the user a question. The question asks “Do you want to check for symptoms of coronavirus (COVID-19”, followed by 2 possible answers; no and yes.
A screen from the old experience that allowed users select one option from a list.
A screen from the new triage experience asking the user a question. The question asks “Do you want to check for symptoms of coronavirus (COVID-19”, followed by 2 possible answers; no and yes. The screen also has a ‘continue’ button and a ‘provide feedback’ link
A screen from the new experience that allows users to select one option from a list.
Explanation links
Some of the questions would require an explanation link in order to include more detail and context to what was being asked. In the existing experience the link would navigate the users to a new page, taking them away from the question and the possible answers, making the experience quite jarring. 

To improve this, explanation links would now display in a popover instead of navigating to a new page. The aim of this was to keep the user on the page and the question they’ve just been shown instead of navigating them away. The popover would sit on top of a scrim so the user could still view the question and they would know they hadn’t navigated away from the screen.
A screen from the old triage experience asking the user a question. The question asks “Have you injured your finger recently”, followed by 3 possible answers; yes, no and I don’t know. The screen also has a link called ‘see and explanation’ which takes users to a new screen to explain the question in more detail
A screen from the old experience that provided users with an explanation link.
The image shows the ‘what does this mean’ screen on the old experience, the user navigates to the screen after selecting the ‘see and explanation’ link. The title on the screen is ‘what does this mean’ with copy that says ‘having had an injury to the finger in the last 30 days.
The screen that provided users with more context to the question they have been asked.
A screen from the new triage experience asking the user a question. The question asks “Have you injured your finger recently”, followed by 3 possible answers; yes, now and I don’t know. The screen also has a link called ‘see and explanation’ which takes users to a new screen to explain the question in more detail
A question from the new experience that provided users with an explanation link.
The image shows the ‘what does this mean’ pop over on the new experience, the user navigates to the screen after selecting the ‘see and explanation’ link. The title on the screen is ‘what does this mean’ with copy that says ‘having had an injury to the finger in the last 30 days.
On the new experience the 'see an explanation link displays the content in a popover.
Replacing buttons with radio buttons
The existing triage experience used buttons as if they were radio buttons and selecting an option would automatically move the user through the process. As mentioned previously, existing research demonstrated that some users would miss options that didn’t fit into view. The style of these buttons were also completely different to any other button used across the app or web. 

To improve this I used the newly defined form and button language. It was important to demonstrate how scalable the new language was whilst also showing how to correctly apply these new components, especially when using the new form language.
A screen from the old triage experience asking the user a question. The question asks “Is one or both of your ankles swollen?”, followed by 3 possible answers; yes, no and I don’t know.
The old approach to single selection used buttons.
A screen from the new triage experience asking the user a question. The question asks “Is one or both of your ankles swollen”, followed by 3 possible answers; yes, no and I don’t know. The screen also has a ‘continue’ button and a ‘provide feedback’ link
The new approach to single selection uses radio buttons from the new design language.
Design details
Splitting the question and the card
The aim here was to reuse and test as much of the design language as possible, especially our form designs and how they would work with our cards. 

I decided to separate the question and the input options. The idea was to place the inputs in the card container to make it clear to users that this was the area that they could interact with and add their data. It also helped provide a clear, reusable structure when including errors and ‘see explanation’ links as part of the question. 
Image shows the designed question component that contains, in order, a question, hint text, explanation link, checkbox options and a primary button.
Question component that lets users select one or more option.
Image shows the designed question component that contains, in order, a question, hint text, explanation link, error message, checkbox options and a primary button

Question component displaying an error if an option isn't selected and the user attempts to progress.

Image shows the designed question component that contains, in order, a question, hint text, explanation link, radio buttons and a primary button.

Question component that lets users select a single option.

Image shows the designed question component that contains, in order, a question, hint text, explanation link, error message, radio buttons and a primary button

Question component displaying an error if an option isn't selected and the user attempts to progress.

The question would always remain fixed at the top of the page, 52px away from the navigation bar. This was so that the user would always know the position of the next question while providing breathing room between the navigation bar and the content below.
A guide on the spacing layout of the triage questions. 
2px corner
For the final card design I deviated away from what we had created in the design language, but only ever so slightly. Instead of using a 16px radius for each corner of the card, the top left corner that was directly underneath the question would use 2px. 

One reason for this was to provide better left alignment with the question above. Another reason I introduced 2px to the top left corner was to have a consistent style with our chat bubble that the design system team had defined for chat assistant and member support. We wanted these input cards to work across triage and the chat experience so that our users would have consistent experience.
Image shows an example of a members support chat screen, where the user is talking directly to a member of the Babylon Health support team
Example of the new members support chat
Image shows an example question screen from the new design to highlight how the design of the triage experience looks and feels similar to the support chat.
Example of a question on the new triage experience
As well as redesigning the questions in the triage experience, I had the opportunity to introduce the new design language to the symptom selector, results, condition pages and more.
Image shows the auto suggest screen with a list of result options based on the search for ’Sore’
Auto suggest search results.
Image shows the auto suggest screen after a result option has been selected.
Auto suggest complete.
Image shows the final results page the user is shown after answering all the questions presented to them in the new design.
Results landing page.
Image shows the final results page the user is shown after answering all the questions presented to them in the new design. This version of the screen shows the current symptoms the user may have.
Results page showing multiple possible outcomes 
Image shows the conditions page the user is shown after selecting a potential symptom they may be suffering from. The page shows risks, typical symptoms, common treatment, warning signs and prevention.
Conditions landing page 
Image shows the conditions page the user is shown after selecting a potential symptom they may be suffering from. The page shows risks, typical symptoms, common treatment, warning signs and prevention. This version shows the Typical symptoms option expanded.
Conditions landing page with an open accordion
Desktop examples
Image shows the auto suggest screen for desktop with a list of result options based on the search for ’Sore’
Desktop example of auto suggest results.
A screen from the new triage experience asking the user a question on desktop. The question asks “Do you have any of the following problems with your toes?”, followed by 3 possible answers; painful toe, numb toe(s) and swollen toe. The user can also select multiple answers
Desktop example question that allows users select one or more option.
A screen from the new triage experience asking the user a question on desktop. The question asks “Do you see any blood in your vomit?”, followed by 3 possible answers; Yes, No, I don’t know. The user can only select a single answers
Desktop example question that allows users select one option.
The image shows the ‘what does this mean’ pop over on the new desktop experience, the user navigates to the screen after selecting the ‘see and explanation’ link. The title on the screen is ‘what does this mean’ with copy that says ‘having had an injury to the finger in the last 30 days.
Desktop example showing the explanation to a question in a popover.
↑Back to Top