Introducing Design System to Multinational Web Apps

Rate this content
Bookmark

I will walk through the process of my team introducing design system to our company's web applications that are built separately in different countries - UK, US, Germany, Spain and Japan. After that, I will add a practical guide to set up a design system for a project.

18 min
21 Jun, 2022

Video Summary and Transcription

Octopus Energy introduced design systems to address challenges in maintaining brand identity, accessibility, and developer experience. They built a component library using design guidelines and accessibility best practices, following Bradfrost's atomic design methodology. They used TypeScript, Jest, Versal, and Storybook for building and testing the library. The design system is an ongoing project that evolves with the product and business over time.

Available in Español

1. Introduction to Octopus Energy's Journey

Short description:

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.

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.

2. Octopus Energy's Challenges and Solution

Short description:

At Octopus Energy, we faced challenges in maintaining consistent brand identity, accessibility, and developer experience across different countries. To tackle this, we decided to build a component library using LEGO blocks, following design guidelines and accessibility best practices. This library will be shareable for our global developer teams as part of our design system, which contains our brand's design principles and guidelines for patterns.

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.

3. Building the Component Library

Short description:

We started with basic design principles like color palettes, typography, and spacing. These design tokens allowed us to create patterns in our component library, such as buttons, alert boxes, sliders, and text inputs. By defining these patterns, we eliminated the need for designers and developers to make design decisions repeatedly. We followed Bradfrost's atomic design methodology, where the smallest components are atoms, larger components are molecules, and user interfaces are organisms. Our component library, which contains ready-made LEGO blocks, ensures consistent user experience. While a component library can exist without a design system, a design system encompasses more than just a component library.

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.

4. Building the Component Library (Continued)

Short description:

We used TypeScript and Jest to build our LEGO blocks and write tests. Versal and Storybook are great tools for fast deployment, collaboration, and documentation. Initially, we used Material UI as an external component library, but later moved to styled components for better design decisions and integration with our own 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.

5. Design System and Ongoing Project

Short description:

The design system doesn't have to be a massive documentation containing all the rules and guidelines. It can start with simple design tokens like colors, typography rules, and spacing. Coral is an ongoing project at Octopus Energy, with a feedback channel for users to share their feedback and contribute to the open-source project. Design systems are living things that evolve with the product and business over time.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
WorkshopFree
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.