Roadmap 2022

Konstantin Demblin

, Design System Lead

December, the month that hosts the end of the year - at least for the parts of the world that follow the Gregorian calendar - is widely seen as a good month to look back on what has happened in the last year and what shall happen in the future.

We, the team behind the George Design System (GDS), thought about the future of GDS in several sessions earlier this year and came up with kind of a roadmap - not necessarily (just) for 2022, but for the time ahead of us. Before we dive deeper into that topic, it is worth mentioning, that the majority of our daily work is invested in

• maintaining and improving the design system for web (for Retail, Business, the Store and more)
• maintaining and improving the design system documentation for mobile (Android and iOS)
• maintaining and improving the design libraries for the design chapter
• releasing a new version of the George Design System every sprint (= every second week)
• implementing new components for George
• providing support to the teams who are using GDS
• providing feedback and improvements for accessibility topics to feature squads
• challenging designs and asking for alignment in case we see inconsistencies in a designer’s component specification
• …

More complex topics, which have the potential to end up on a roadmap, usually stick much longer with us, before we find time to tackle them and more often then not they get pushed down the backlog for more mundane yet more pressing issues. So, maybe we shouldn’t call it roadmap then? Maybe we should call it “The list of topics we would love to to work on, if reality would not hit us several times, but we still plan to work on in the future” - sounds catchy, right?

Enough with that, here comes the list with some details:

Visual testing

Every new line of code has the potential to break other lines of code and to change the user interface (component) unintentionally. Visual testing will help us to improve the quality of our releases even more.
A visual test is an automation that checks each element on a web page for its right shape, size, position and colour by comparing two images - one from before the change, one from after the change - throwing an error, if a difference has been spotted.

We have started to work on it during this year’s hackweek and have written more about it in a previous blog post.

Examples and documentation

Improving our pattern library will remain an ongoing task of high priority. We want to add more real world examples from George to our documentation. We will aim for documenting all components with their full functionality.

We made significant progress on that matter earlier this year and most recently at this year’s hackweek as well.

Design tokens

Design tokens are values, represented as data, that are needed for building components - e.g. colour, typography, style, spacing, size, animation etc. These tokens can inherit values from each other which allows doing global changes much faster.

Design tokens are also a prerequisite for the next topic.

Grid of eight 🎱

This topic is with us for a very long time. Although quite some explorations have happened so far, we did not manage to make it a reality in GDS yet.

A grid system helps to build components and pages in a much more structured and aligned way. With a grid of eight, we aim to build components and their spatial relationship to each other with a multitude of eight pixels.
Within a component itself, the unit of measurement can also be a fraction of eight pixels. Potentially it could allow us to get rid of Bootstrap.

Architectural changes

We would love to make improvements to Storybook and Playroom. For instance to make all examples in the design system documentation openable in Playroom or to make stories copy and pasteable. But there comes even more to our minds when thinking of it.
We are convinced this would be very beneficial for our colleagues from the web frontend.

Additionally we are planning to migrate to an internal assets repository to improve the icon workflow and host other assets more conveniently.

Making GDS public

We are currently working on making the documentation of GDS public - to everyone on the internet. We are convinced that this will help all of us working with George no matter of our profession or location and we are sure it will help us to attract talent, too.
Besides, we are very proud of what we are building and we are looking forward to receive even more feedback and to inspire others with what we do.

Dark Mode 🦉

We have implemented dark mode for GDS during this year’s hackweek. You can read more about it in the previously mentioned blog post or - even better - check it out for yourself. You can toggle between light and dark mode in the settings menu; to get there click the ⋮ vertical ellipsis in the top right corner of the main navigation.

Aligning terminology

With the dawn of Figma as George’s primary design tool and the necessity to build the design libraries from scratch, the aim is to build design components that work and are named (component- and prop names) as closely to their React counterparts in GDS as possible.
This will make it easier for developers who are inspecting design files to get an understanding which components to use for implementing the given design and it will help designers to understand, if a new design is (most likely) implementable with existing components.

GDS 3 beta

With every release, we get one step closer to a new beta release. Let’s see, how far we will get in 2022… 😅