Jack Roles - Lead Product Designer
The existing design language on the new React Native platform was difficult for teams to understand, to use and inconsistent. It was also inconsistent with the design language being used on the web and in our marketing materials.
Certain aspects of the design language lacked guidance, an example of this was a split background that was used in certain areas of the app. Because this split background lacked clarity, it caused confusion within the design team on when they could use it.
With no brand team it was down to the design system team to collaborate with the marketing team to create a design language that would work across both app and web while still being consistent with marketing.
Example of the previous Babylon health app home screen, which contained the split background.
North star concepts
An external agency looked at the future of the app experience. They were given the freedom to experiment with a new colour palette and user interface for the app. However, not everything in these concepts was feasible or accessible. Large parts of the colour palette did not meet the WCAG AA requirements and the components lacked the attention to detail required for accessibility, health care and our design system.
Moving to React Native
The business had also decided to move away from native iOS and Android. React Native was being tested on a US app that had a relatively small user base and the plan was to test it before rolling out across the main app.
But before doing this we need to improve the accessibility of the app, create a clear design language and an easy to use set of components.
The DNA team will take it from here
Once the north star concept stage was complete and signed off, it was down to the DNA design system team to make aspects of this a reality. At this stage the DNA team consisted of:
• Michael Owen, Design Manager
• Jack Roles, Lead Product Designer
• Paul Tran, Senior Product Designer
• Fred Warburton, Accessibility Lead
• Lily Batt, Agile Delivery Manager
To successfully execute the new design language work and integrate the results with our new UI style, the team would need support in the form of four contract designers. As this was a time critical project, the team needed the additional support to prevent existing projects falling behind and not having design resources.
The Babylon DNA design system team.
What did we have to work with?
To start we had to inspect the north star work. It was important to identify what was feasible and if the UI approach was accessible and scalable.
We then analysed the competition. We had to discover where the new design and style of Babylon would fit in the market, and, with no brand team, we collaborated with the marketing team to determine the design language of Babylon going forward. We needed to identify what the team believed the brand was and felt like. Was it warm, cool or just a single brand colour.
Foundations first
Initially we focused on colours. These would set the mood for the brand and would be essential for the design language across app and web. The team created and experimented with multiple colour palettes, testing them on icons, graphics, existing screens and components.
We had recently updated our typography and choice of font; we moved from using Visuelt as our functional typeface to Inter for accessibility reasons. Visuelt still remained the main type face of the Babylon brand, but was reserved for large headings across web and app.
Another key aspect of this work was to determine the rules and guidance for the radii used on our components. There was no guidance or rationale behind the existing radi and this was an opportunity to get that right.
Exploring the UI
After evaluating the concepts and feedback on the north star work, we decided to push forward with the idea of cards being the core aspect of the interface and page structures. The rationale being that cards could provide screens with clear structure and make our content easier to scan and consume. The team also believed that with clear guidance, screens could be easier to design and build.
Components
After we were happy with the new foundations, we applied these to core components such as buttons, links and inputs. These core components would set the style of the digital language across the app and eventually the web. The structure of components such as text fields, radios and checkboxes didn’t change too much, we simply applied the new foundations, altered the corner radius and applied a new focus style. The biggest change and impact came when we changed the size of the checkboxes and radio buttons on our web components.
Default states of inputs and buttons in the old Babylon design language
Default states of inputs and buttons in the new Babylon design language
At this stage we also stress tested all the different variations and instances of these components, especially the colours for focus and error handling. We decided to alter the approach for our focus state, the existing design was looking clunky and colours started to clash when making the contrasts accessible. The existing approach for focus was difficult to scale for third party colour palettes because it used the primary brand colour reduced to 40% opacity.
The new approach used a stroke around the outside of the inputs, this meant it could scale for all of our inputs and that any contrast passing colour could be used.
Focus states of inputs and buttons in the old Babylon design language
Focus states of inputs and buttons in the new Babylon design language
We also kept the position of the error text below the text field label. Placing the error directly below the label would provide more flexibility for implementation as the error could be part of the label or separate. Because the association between errors and input fields for screen readers happens at the code level, it generally doesn’t matter what the position is for them, so this decision was more for visual association. You can read more about this decisions from my Designing accessible web components for Babylon Health post
Error states of inputs and buttons in the old Babylon design language
Focus states of inputs and buttons in the new Babylon design language
Cards
When designing the style of the card, we had to consider the radius and if we needed any elevation. If cards were to be the core part of the app design, there needed to be a fine balance when adding an elevation style. We experimented with a variety of elevations, and in the end we deemed it necessary to have a subtle drop shadow. The reason we found it necessary was to ensure the cards stood out against the newly defined primary and secondary background colours.
Cards also raised many interesting points for the team to consider, such as should they always be interactive or just informative, or could they be both? If they are interactive should they only ever contain one clear call to action? If cards could be both interactive and informative, how do we differentiate them and make it clear to the user?
The team, especially Paul, began by looking at the content structure of the card including headings, body text, images, icons and different types of call to actions. This would help us answer the many questions we had regarding interactivity.
A small snippet of cards from our discovery work.
In the end we decided that the card could be both interactive and informative. If actionable the card would have a button and if it was navigational it would have a differing call to action.
The final set of cards were really flexible and could contain images, icons, a profile image or just contain text. Not only could they be used on their own, but they could be stacked vertically to create a list related by theme or content type.
Final designs of the cards in light mode
Final designs of the cards in dark mode
Examples of card lists and groups in light mode
Examples of card lists and groups in dark mode
Setting up the new libraries
We decided to start again with our libraries. This wasn’t because the existing set up was bad, more that starting fresh would allow us to test and break things without impacting our users, in this case our design team.
Another reason for starting again was because of a platform shift from the business. The business was moving the app from native iOS and Android to React Native. Although this move was, and still is, controversial from an engineering and accessibility perspective, it allowed us to reduce the number of libraries we needed to maintain in Figma. We would only need to take care of 3 libraries; foundations, web and app.
Foundations
We started with the foundation's library, arguably the most important. Foundations essentially hosts the design tokens we use across our Figma component libraries, including colour, type styles, iconography and even some graphical elements. The reason this library is so important is that it provides the styles to our components and any changes or additions we make to the foundations are instantly available to the component library.
Colours, type and even icons were given semantic naming, moving away from the old brand names we had inherited. Names that describe what the element does would make it easier for the design team to adopt and to help create consistent experiences. Colour categories ranged from Brand, Type, Background, Status and more.
We also included the Atkinson Hyperlegible font in the foundations library. This font would be an accessibility feature that users could turn on and off within the app. It made sense to include this so designers could see the impact switching between Inter and Atkinsons Hyperlegible could potentially have on their designs.
We also set up and used the Themer plugin to help designers quickly switch between light, dark and third party themes. This would allow us to test and see the instant impact on our components and screens. More importantly, it would allow the team to create screens once and switch them to another theme in just a few clicks.
Components
Each page within the component library was categorised based on the components role. For example, we had a category named Navigation which would contain buttons, top and bottom navigation bars, tabs and more. This approach allowed us to have fewer pages while still making it easier for the team to discover the components they were looking for.
In terms of laying out our components, we positioned them on a templated frame. We wanted to include small snippets of documentation, links to Storybook and examples of where the component is used. The idea was to show our designers the information they required within Figma instead of linking them to an external source and out of the tool. The aim was to then include more detailed documentation to the DNA design system site, but due to time and resource constraints this would have to wait.
An example of one of our component frames. Please note, these components were created prior to the component properties feature.
As well as containing the component and all its variants, each frame would also contain a title, description, instructions on how it should be used and examples. Seeing examples would give designers a better understanding of the content expected in the component, especially as the type within the components would be labelled based on the semantic naming from our foundations.
We also included a page dedicated to patterns that were used throughout the app. These would include things such as photo upload, pin entry, empty states and maps. It was important to have these commonly used patterns easily accessible to the team to avoid duplication. The patterns could then be instantly taken from the library and dropped into a designer's workflow.
Example of our maps and photo upload patterns
Things we would have done differently
While the project was a huge success, in hindsight there are always things you wish you had done differently. Looking back there are three areas I think we could have improved.
Firstly, I believe we emphasised too much on cards. While the outcome of the cards was a success, the rules on when to use them did cause some confusion with the wider team. For example, if a page was purely informational, it wasn’t clear if that information should be placed within a card or directly to the background.
Secondly, we should have considered theming in greater detail and the impact this would have on our components and colours. Theming is important for Babylon, with third parties having themed versions of the Babylon app and experience. Some design decisions we applied to certain components made it difficult to theme for our third parties. The secondary button in particular made it difficult to distinguish between the primary and tertiary buttons when an external theme was applied.
Finally, I believe that if we had defined some UI principles early on our reviews would have been more streamlined. In some cases reviews and decisions come down to personal preference, which is fine of course, but principles would have given us something to measure our designs against.
Reviews and reaction
Sharing progress and collaborating with the wider team was fundamental. The team had a weekly review process to discuss progress, identify any blockers and any components or variants that may have been missing. These sessions also included our design system engineers, as we had to ensure all components met requirements from a development standpoint too.
Weekly reviews with Amy Keeling (VP Design) and Yon Nuta (CPO) to highlight progress and rationale behind design thinking were also essential in our progress.
We also had separate review sessions with our marketing team. Because there was no brand team the design system team and marketing had to work and collaborate very closely to ensure we had consistency where it mattered.
The teams reaction
The overall reaction was extremely positive, and because we shared our progress frequently it was no huge surprise to the team. Throughout the process we would work with our domain teams to test the components further; the purpose being to see how components would scale and the impact the new language would have across the product.
The team really liked the simplicity of the design language, that accessibility was at its heart and a design language that felt like Babylon.