Introducing Design System to Multinational Web Apps

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at React Summit 2022, check out the latest edition of this React Conference.

FAQ

Octopus Energy ensures consistency in brand identity by using a design system that includes a component library with predefined LEGO blocks. These blocks are designed following specific guidelines to maintain uniformity in visual elements like logos, colors, and UI components across all regions.

Octopus Energy's component library is built using TypeScript and React. The library also incorporates Jest for testing components and Versal for fast deployment and collaboration. Additionally, they initially used Material UI for rapid development before creating their own styled components.

The design system at Octopus Energy includes accessibility best practices in each component. This ensures that all elements, such as navigation logos and UI components, are accessible, including features like aria labels and visually hidden text for screen readers.

Feedback is integrated through a dedicated channel within Slack where users of the component library can share feedback, requests, and bugs. This open-source, within-organization project encourages contributions from all users, facilitating continuous improvement and evolution of the design system.

Octopus Energy started their design system by establishing basic design principles, such as color palettes, typography, and spacing. These foundational elements provided a simple yet effective framework to begin standardizing design across their applications.

The main goal of Octopus Energy's design system is to maintain a consistent brand identity across different countries, ensure high standards of accessibility, and provide a seamless developer experience by offering a component library built on design guidelines.

At Octopus Energy, the design system is a set of guidelines and principles, acting as the instruction for building UI components. The component library, on the other hand, contains ready-made 'LEGO blocks' or components that developers can use directly. The design system encompasses the component library but is broader in scope.

Alison Yoon
Alison Yoon
18 min
21 Jun, 2022

Comments

Sign in or register to post your comment.
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.

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

Design Systems: Walking the Line Between Flexibility and Consistency
React Advanced 2021React Advanced 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
Watch video: Debugging JS
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top ContentPremium
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Building a Voice-Enabled AI Assistant With Javascript
JSNation 2023JSNation 2023
21 min
Building a Voice-Enabled AI Assistant With Javascript
Top Content
This Talk discusses building a voice-activated AI assistant using web APIs and JavaScript. It covers using the Web Speech API for speech recognition and the speech synthesis API for text to speech. The speaker demonstrates how to communicate with the Open AI API and handle the response. The Talk also explores enabling speech recognition and addressing the user. The speaker concludes by mentioning the possibility of creating a product out of the project and using Tauri for native desktop-like experiences.
A Practical Guide for Migrating to Server Components
React Advanced 2023React Advanced 2023
28 min
A Practical Guide for Migrating to Server Components
Top Content
Watch video: A Practical Guide for Migrating to Server Components
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
Power Fixing React Performance Woes
React Advanced 2023React Advanced 2023
22 min
Power Fixing React Performance Woes
Top Content
Watch video: Power Fixing React Performance Woes
This Talk discusses various strategies to improve React performance, including lazy loading iframes, analyzing and optimizing bundles, fixing barrel exports and tree shaking, removing dead code, and caching expensive computations. The speaker shares their experience in identifying and addressing performance issues in a real-world application. They also highlight the importance of regularly auditing webpack and bundle analyzers, using tools like Knip to find unused code, and contributing improvements to open source libraries.

Workshops on related topic

Building a Shopify App with React & Node
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
Workshop
Jennifer Gray
Hanna Chen
2 authors
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.
Build a chat room with Appwrite and React
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
Workshop
Wess Cope
Wess Cope
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!
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
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.
Build Modern Applications Using GraphQL and Javascript
Node Congress 2024Node Congress 2024
152 min
Build Modern Applications Using GraphQL and Javascript
Workshop
Emanuel Scirlet
Miguel Henriques
2 authors
Come and learn how you can supercharge your modern and secure applications using GraphQL and Javascript. In this workshop we will build a GraphQL API and we will demonstrate the benefits of the query language for APIs and what use cases that are fit for it. Basic Javascript knowledge required.
0 To Auth In An Hour For Your JavaScript App
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Asaf Shen
Asaf Shen
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.