Helix Design System
This project was a massive undertaking but lots of fun. I was the lead designer in this project and was tasked with creating the Google material system components in Figma.
Project overview
This has already been done! I know, but if you truly want to maximize the potential of the native Android UI then you have to build it yourself. Google doesn't give you everything. So that's what I did. Using Figma auto layouts and variants I built the Material system for Ascension Health's design team. Take a look at some of the challenges that came up along the way.
Execution
Now I know what you’re thinking and you’re right.
Google does give you their components so why did I need to recreate them? There are several reasons why it was imperative that we designed the components ourselves but here are a few of the big reasons.
1. They don’t give you all the state changes.
If you want a scalable design system then it is crucial that you have clearly defined states for every component in the system to create clarity for both designers and engineers.
2. They don’t give them to you in variant and auto layout format.
If you use Figma then you know how beneficial it is to have components that are made using these two features.
3. They don’t have the correct colors for your specific brand or product.
Out the box material comes with a default theme. It is up to you to create your own theme to match your brand or product color scheme.
Let's get started.
Now when I began this project the theme layer had already been created, so I started creating the components to the specifications stated in the material design documentation. Building the components was fairly straight forward. If you understand how auto layouts work then you can pretty much make anything using it. There were a few challenges making some components like the bottom app bar and the date picker responsive, but through trial and error I figured out how to make them work. All in all I created 30 components and over 3800 variants for both light and dark mode. This was actually the easy part though. The hard part was still to come. Right now we essentially just have a component library.
We need documentation.
Since we are using a platform based system most of the documentation was pretty straight forward. There were a few main things that documented across the board to get things started. Those were:
1. A high level implementation guide
2. A sticker sheet for each component
3. Links to the material documentation
4. A Figma variant guide
This is just the beginning though. We will continue to add documentation to help internal and external designers and engineers better understand and implement the system.
It’s time to launch it!
This is the hard part! It’s hard because there was already an existing Android library being used by some of our design teams that this new file would be replacing. It wasn’t as robust and responsive as the one we just built. Again, I know what you’re probably thinking. Why didn’t we just update the components in the current library and publish it? I’ll tell you why. Figma is amazing but it’s not perfect. When you build several large and complex variant components in a single file you will see a performance hit in Figma. This will affect you in two ways.
1. It will bog down the speed of your file making it take longer to build new components.
2. For people using the library it will take longer for the larger components to load in their file.
Because of those things I had to make our updated system in a new file and replace the old file. This is where the challenges began.
1. Move the old file.
I needed to move the old file without breaking the components that were linked to it. It’s easy to move files in Figma but I had never moved a library before so I wasn’t sure how it would behave. I didn’t want to leave it to chance so I tested it first. I made a small test library and moved it and found out that linked components should automatically stay linked. I say should because this was a small scale test and on a larger scale there is still a potential for things to break. Luckily move went over without a hitch.
2. Publish the new style.
I needed to publish the new library and make sure that the components were working correctly. I primarily wanted to test the larger components to make sure that they were loading within an acceptable amount of time (Within a few seconds). Then I tested the other components to make sure that the variants were linked correctly and they were all scaling correctly.
3. Move the styles.
The trickiest part was that I needed to move the styles from the old file to the new file while keeping all of the old components linked to the correct styles. This was my first time doing this so I was extremely nervous. Since it was my first time I wanted to test and retest and test some more. I wanted to test a few things. I started by testing what happens when you move a style from one file to another. Then I tested what happened when you had a component linked to the style when you move it. Through those tests I found that you can pull styles from one file to another but you can’t push them. I also found out that components that are linked to the style will automatically update the link to the new file if a style is moved.
Results
The result was a responsive abs easy to use system maximizing all of the features that Figma has to offer. The biggest take away from this project was the importance of communication. I was constantly using the designers on the team about what’s changes were coming, when they were coming, and potential problems that could arise from those changes. I wanted to over communicate to make sure that I could identify any problems ASAP. Plus the system is for them and I want them to feel ownership of it. I want all the designers to feel that if they see a problem it will get fixed and if they see room for growth their voices will be heard.
Welp. Now I’m off to go do it all over again for iOS. Wish me luck!