Introducing Design System to Multinational Web Apps

Hi, I'm Allison. I'm a front-end developer from Octopus Energy in London. Today, I want to talk about Octopus Energy's journey in introducing design systems to multinational web apps. Octopus Energy was founded almost seven years ago now, and this time, we've gone from zero customers to over 3 million. As we were growing, and by this, I mean, in global scale, naturally, we faced some challenges. So we started working on the solution. I want to share our journey in implementing the solution and the learning points from it. And if you have any questions along the way, please take a note or something, we'll have time at the end for the questions and answer.

At Octopus, we have a weekly get together for company updates and drinks in Friday afternoon, we call it Family Dinner. We were hearing some exciting news every month. Octopus Energy is expanding to new regions in the world, which then brought some interesting challenges too.

We ask these questions. How can we keep our brand identity consistent across different countries? How can we maintain accessibility to the highest standard? How can we support our engineer teams by providing a better developer experience? Well, nothing's better than some visual examples.

This is how Octopus Energy's main page landing area looks like in different countries. This is the UK, France, Italy, Spain, Japan, the US, Germany, and New Zealand. I can show you how our main navigation logo looks like behind the scenes in different countries. Some countries were using the logo with our mascot Constantine, the cute pink octopus you see there, and others were using the logo without it. This one got a simple A-tag wrapping an image. Another got a wrapping A-tag that has a span an image and you can see some accessibility practice here with area label and visually hidden text for screen reader. This one has a A-tag wrapping div that has another div with an image inside and an image tag. And you can see that this doesn't use any class names, whereas the previous ones were using some class names named with the convention of each engineer team's choice. This is only some of the examples of the code behind the UI, but you get the feeling of what's going on here. If the main logo comes with this many styles of code behind it, you can easily imagine how it will look like for different components and different pages.

We have set up some goals to tackle the challenges. We want consistent brand identity across the countries. We want to provide the great accessibility practice. We want to provide our global engineering team with a nice developer experience. What have we decided to achieve this? We decided to build LEGO blocks for developers. For them to build whatever they want easily with these LEGOs, while not having to worry about brand identity or anything. In other words, we decided to build a component library for our developers. This logo block will be made following our design guidelines. Each LEGO block will come with accessibility best practice. Also, it will be all typed, as TypeScript is our language of choice on top of React. In this LEGO blocks, the component library will be shareable for our developer teams around the world, as part of our design system. We started creating our design system along with building the component library. It contains our brand's design principles. It provides guidelines for the patterns. It is the source of truth on how to define what our apps should look like.

We started off from having basic design principles. Color palettes, so that you can be assured with the color usage guidelines. Also, if any of these color changes in the future, you just need to make a change in one place. Typography, so that you don't need to worry about which size and font weight for each headings and the body text. Spacing, so that you can spend as little time as possible on deciding what the padding should be and margin should be.

With these design tokens ready, you can now add patterns to the library. Add UI components such as buttons here, and how the buttons look and behave. For example, as you can see, we have standard, outlined, text, or a button with an icon in it. Also, we defined hover state, click state, disable state, and so on. The alert box, the slider, and the text input. All these components can be used to form a pattern in the library, such as this form, or a call-to-action button with an input. A card component with text inputs and a button inside, and you can see how many design decisions are there in just this one little component. Padding, margins, font size and weight. Without the pattern defined, this is something that needs to be decided each and every time for both designers and developers. We'll always be able to refer to this design system when we have to build whatever the page or product we need to build. Just as we look at an instruction when we build a LEGO model.

With our component library, we decided to follow Bradfrost's atomic design methodology. Smallest components, or LEGO blocks, is called atoms. Larger components, thus made with combining atoms, is called molecules. User interface, thus made of atoms and molecules, such as a navigation bar, cards with text or inputs inside, is called organism. Something like 404Page can be added as a template because that's a complete layout and can be shared in different countries. Project Corel. We started building a component library to resolve the new challenges that I've mentioned in the beginning. But wait, design system? Component library? Are they the same thing? Component library lets you use ready-made LEGO blocks out of the box. Since all LEGOs inside are made following design systems guidelines, you can be assured that it will provide consistent user experience. Design system is the instruction for building LEGO models. And component library is the box of LEGO blocks. Know that design system is a broader concept that includes component library. Design system will still be design system even if you don't have component library. But component library can exist without design system.

This is what we used to build our LEGO blocks. We used TypeScript, so our theme is all typed. We write tests for our components using Jest. We use Versal to quickly deploy the changes to Storybook. It's very easy for us to build something and deploy it fast to get the feedbacks. Versal is a great tool for fast deployment and developer collaboration. It's very simple to integrate with GitHub, so that when you make a change and push, it will deploy instantly. With the preview URL and everything. There's one more which I will talk about later.

We use Storybook to have the available props documented in the props table. Storybook can also show you if your component meets the accessibility standard. Also, this can be used as the documentation as well as the source of truth for developers to check the UI in the example usages with the functionality to look at the code. And this is what the question mark was about.

We decided to use existing external component library that has similar design style to us. This is material UI. And why did we do this? Because at the beginning of this project, there were limited resources. So basically, the number of designers and developers who can work for this full-time were small. And we wanted to create something rapidly while taking the advantage of react and TypeScript support in the accessibility best practice. And as it aligns with Octopus' basic design style, we wouldn't need to make a lot of customization. Important thing is that our design system is independent from this external component library. So in case we decide not to use this library anymore or switch to different libraries, we can still keep our own design system without much issues. So there were many good reasons why this was a good choice for us in the beginning, but as we were growing, we moved away from it as it was limiting our ability to follow the design decisions. We decided to use styled components, which let us use React components with an easy integration of our own design system. It's fine to use existing component library to start building your own. Just make sure that your design system does not completely depend on it. Remember that the external component library of your choice is a tool for your design system. You might want to build your own from scratch or might want to use another library. But in any case, you still have your design system as a source of truth to guide you. Also, I can remind you once again that the component library of your choice is a part of your design system. So this is a result.

Do you see the improvement from this to this? It can be used by any of our developers around the globe as well. Now, each territory can use the logo as simple as this. You can pass width constant in prop if you like to include the mascot in the logo. You can also set the specific width to the width prop for the sizing. And of course, you have the option of adding hyperlink and use it without the mascot.

Remember where we started? Design system doesn't have to be this massive documentation that contains all the rules and guidelines. In the beginning, you can start by creating some design tokens such as you have a list of colors that's used in your app. You have the list of typography rules such as we use this font family and font size for heading one heading two and things like that. Or the list of spacing like the size of the spacing you want to use for the padding or margin or the space between the sections. There's nothing scary about defining these things early on. Because when you hear design system, it sounds like a big job. But don't let it put you off.

Coral is an actively ongoing project in Octopus Energy. We have a feedback channel in our Slack where everyone who's using the component library is invited and share their feedbacks including requests, bugs or questions. With the feedback channel, the door to discussion is always opened and this is how we know what we need to do for our next step. Also, while we have the team that's in the center of decision-making in Project Coral, it's an open-source within-organization open-source project where we welcome everyone's contribution. This way, we can improve things faster while having a clear direction of where we're heading. Take design system as a living thing, it will be changing and evolving as your product and business does, and you don't need to get everything perfect from day one. It is something that will grow over time as long as you maintain it. Thank you so much.