Our Julius Baer workflow to create pixel-perfect UIs in React with Figma and Material UI (MUI)
Lately I have been part of the efforts to modernise the UI of our clients’ e-banking in my role as a senior frontend developer in Julius Baer. To this end, I spend a significant amount of time collaborating with designers and interfacing with Figma to develop parts of the UI in React.
In this article I will share with you the process we use in our teams at Julius Baer to create React UIs with Material UI (MUI) from designs in Figma. This article might be of interest to you if you are a:
- Frontend developer interested in converting Figma UI designs to React components with Material UI for React.
- Designer who want to know how to optimise their Figma projects to facilitate the work of developers.
- Product owner/Scrum master of a team whose size and function resemble those of our organisation and who is looking to find a collaboration workflow between designers and developers.
Collaboration with our Designers
The way the teams and experts that deliver IT functionality in Julius Baer are structured and collaborate significantly affects our workflow. Before we go to the specifics of our process let’s talk a little bit about this setup first.
As part of the SAFe agile methodology, we have cross-functional teams that deliver new functionalities in each product iteration (PI). These teams require functional specialists in particular areas of expertise, such as software engineering or user experience (UX), in order to achieve their goals. Julius Baer features pools of specialists organised by knowledge domain to provide these teams with experts in domains. Such a pool of specialists is known as a Center of Excellence (CoE).
When it comes to the User Interface of our e-banking, a new product iteration usually starts with our colleagues from the Change and Customer Experience (CCX) competence centre. CCX is responsible for the UX of our products and among other responsibilities they create and validate user journeys, UI prototypes as well as their final designs. CCX has many experts working on different projects, however, the one I interface the most is Ming (Ming Shi), a UI designer whose main focus lies on establishing the new client-facing channels design.
Ideation phase
During the ideation phase, Ming creates interactive prototypes in Figma. He receives feedback from the various experts in and outside the team (such as product manager, product owner, branding experts and more) and iterates on the design. My feedback to Ming is mostly focused around technical feasibility, responsive design, interactions between touch and pointer devices, animations, transitions between pages and all around technical feedback.
As the Figma prototype is moving towards its final shape, it is time for Ming and me to start setting up the Figma file in a way that will facilitate implementing the design as React Components using the MUI library.
Considerations in Figma design to facilitate frontend development
Design tokens and MUI theme
In Julius Baer we are at the process of implementing a design system. Although still an ongoing process, there are already many design decisions encoded as design tokens. Such tokens include a colour palette, typography etc..
The design tokens of the design system will be encoded inside a MUI theme in the frontend code. There were cases where we were missing a design token for MUI theme settings that are frequently used in MUI components such as spacing, responsive breakpoints, and transition settings. In such cases it makes sense for the designer and the frontend developer to define and agree on values for these “temporary” tokens, even if they don’t make it into the design system. All that is necessary for the tokens to be used in the Figma file. This decision helps with the:
- efficiency of converting the design to code (each token can be reused in the code);
- consistency between different components (e.g same gutter everywhere); and
- effortless communication between designers and developers using mutually (defined and) understood concepts.
As a concrete example, we were missing a spacing factor which is used in MUI all the time to define paddings, margins, gutters etc. Ming and I agreed that we will use the default spacing factor of 8px of MUI. Ming then used this factor or multiples of it when he was implementing the next iterations of the Figma design.
By the same token (pun intended) we agreed on an extended colour palette, responsive breakpoints and transition duration values.
Interactive components
It is important to consider that interactive components such as buttons, navigation list items, sliders, video players etc. have multiple visual states in their UI. For example, a navigation list item may have the following states:
- Normal: Indicates an item that the user can interact with but it is not selected.
- Selected: Indicates that item has been selected by the user.
- Hover: An item is in that state when the user’s pointer hovers over it
- Hover_selected: An item goes in that state when it was in the selected state and the user’s pointer hovers over it
Designers should communicate, if possible, all of the visual component states to the developers. One way to do that is to design all the states in Figma as seen in the following figure:
Another way is to create design tokens that describe how to implement such states in a generic fashion. Design tokens can be very useful for describing state changes that are hard to capture in a static design, such as transition properties. In our navigation list example, all the states are drawn in Figma but we also make use of the “transition duration” design token to specify the background colour and border colour transition duration between states.
Implementing the frontend in React
Custom MUI theme and extending its defaults
MUI allows developers to user their own theme where they define variables (properties) for palette, typography, spacing, breakpoints and more. Creating a custom MUI theme is a straightforward process where the developer creates an object with the theme structure as specified in the theme docs. It’s sufficient to just define the properties that are different from the default theme and MUI will make sure to overwrite them while still using default theme settings for properties that weren’t defined.
It’s very common to extend the default theme with variables that describe styles and settings specific to one’s project. For example, in our project, we often find ourselves using specific typography styles for label/value pairs. These styles are good candidates to be encoded as typography variants in our theme. The default MUI theme doesn’t include typography variants for label/value pairs out of the box and we already use the existing default variants for their intended use case (such as body1 and body2).
Let’s extend the theme with the new label value typography variants. Here is the code for JavaScript.
If you’re using Typescript you will also need to update the related typings:
Theming MUI components
MUI comes with a library of components that cover a lot of the common UI needs such as buttons, dropdowns, lists and more. Some of the look and feel of the components, such as the font-family, is configured by theme properties such as typography. Most components however have many more styles applied to them.
There are several approaches for customising a component in MUI. The ones I personally use the most are global theme variation, one-off customisation and reusable style overrides. In this article we will talk about global theme variation and one-off customisation.
Global theme variation
Using the components property of our theme we can globally override component styles (and props). This means that the default look and feel or our components will change according to our overrides. This approach is suitable for styling frequently used components for which we desire a style different than the default MUI component style. In our application, Ming opted for using light shades of our signature “Royal blue” and “Reflex blue” colors as the background-color of the :hover and selected states for the ListItemButton component. Since we are using this component multiple times in various parts of our application, we will globally override it in the theme.
We use the listItemButtonClasses class names exported from MUI to avoid hardcoding the names of classes such as .Mui-selected.
Now we can use the component override in our theme definition like this:
One-off customisation
In contrast to the value of the background colour for specific states of the ListItemButton, which is the same throughout the application, we only have one use case where we want the ListItemButton of a specific component to have a left border (plus some padding). In that case it makes sense to perform a one-off customization and just style the ListItemButton in the component definition like this:
Notice the use of the shorthand py and pl spacing properties of the sx styling property of MUI to set the vertical padding and the left padding respectively.
You can see the component in action in the gifs above. Notice that it uses styles from both the global theme override and the one-off customisation.
Final words
In this article I presented our workflow at Julius Baer to convert designs in Figma to React UI with the help of the MUI UI component library. We covered topics such as team organisation; setting up the Figma file; design tokens and encoding them in a MUI theme; and two of the approaches on how to theme MUI components.
Before closing, Ming and I would like to share our common observation:
When frontend engineers pay attention to the design details, designers are more keen to learn about engineering principles and vice versa. The quest to familiarize oneself with a different domain than that or their specialization creates a channel of bilateral knowledge exchange and feedback that greatly benefits collaboration, efficiency and — most importantly– the final product.
Let us know if you found this article useful or if you have any questions in the comments below and stay tuned for more topics on UI with React.
