Model of Collaboration

It takes a village to raise a child.

—African proverb

The same thing is true for building a design system. A design system - by its very nature - has to be living, constantly evolving and always in progress to meet the needs of its users; this takes a lot of effort.

It was a conscious joint decision, to set up the George Design System (GDS) on a collaboration model amongst all involved parties (development, design, product ownership, …). The development of new components is per definition a joint effort.

Benefits

Whereas the core competency of building components for the GDS to be used in George stays with a single team (Design System Squad), it is avoided that this team becomes the bottleneck for component development by co-developing user interface components in different teams. Additionally, it guarantees that the knowledge about component development and component usage is spread over all frontend teams that make use of the GDS.

History and Outlook

In the beginning, the George Design System’s single purpose was to streamline, support, boost and improve the development of George Retail. It allowed and helped to scale up the team size and played an important part to roll out George to other markets.
Later on George Business was added to the consumers of GDS. Whilst we see a declining need for new components for George Retail, the demand for George Business components (improvements, but also new components) is still growing.

Whereas the primary focus for GDS is still on George, this focus – due to the success and strategic importance of GDS – got even more extended recently: Other teams within the Group are encouraged to make use of GDS to design and develop customer-facing interfaces, advisor-facing interfaces or even internal applications outside of George.

Disclaimer

The decision to design and develop something with GDS brings – next to the many benefits of a design system – also the binding mutual contract to follow the design language of George and the processes around GDS. A key feature of any design system is to establish a consistent system of interface components to help the user of an application to explore its content by applying familiar patterns to any potentially unfamiliar new section or page.
Especially when porting existing functionality to the design language of George (which is necessary to make use of GDS), it is key to make use of existing components and patterns (even if it requires the interface design to be adapted), instead of introducing new components that solve the same purpose as already existing ones.

What belongs into GDS

The decision that an application should look and feel and behave like George, does not mean that all it’s components belong into GDS – rather on the contrary:
A design system needs to stay lean and focused to remain useful to it’s customers.
George itself consists of various good examples of components, built by subcomponents from the GDS, but developed, maintained and used by different frontend development teams outside the GDS. It is these teams own responsibility to develop these external components further and make them accessible for other teams as well to achieve the biggest synergies.

As a rule of thumb: If an element in the user interface of George is (or has the potential to be) used more than once, it most likely should be developed as a component for the GDS. It has to be merged to the code repository of the GDS through a pull request (PR), and be made available to all users of the GDS through a release of the GDS itself.

Elements in a user interface that are used just once are called “snowflakes” and should not become part of a design system. Bigger compositions, using a design system’s components – often referred to as Templates or Pages – most likely won’t end up in a design system (as coded components). However, sometimes it might make sense to showcase these as examples.
HINT Late discovery of snowflakes or late discovery of missing components (or component improvements) should be avoided.

Component decision tree - download printable file

GDS Governance and Process

An even more detailed flow chart on design approval and processes around GDS:
Hint Click here to open the flow chart in Figma.

Design exchange

The design platform leads at George Labs regularly host Design & Dev Meetups for all platforms (Web, Android & iOS). The purpose of these regular meetings is to discuss any George related topic with (GDS) developers and designers, for example

• Existing & new components across Retail, (Pro) and Business
• Global elements in George: Navigation, StripeHeader, FocusPage, Button, Grid, Amount displays, etc.
• George Store components
• Responsive layout optimizations
• A11Y questions or requests
• any cross-cluster topic that affects the specific platform, including webviews (e.g. on a tablet)
• …

If you are interested to attend one of these meetings, get in touch with

• Albin Kurtanović for George in a native application (Android or iOS)
• Aniela Drela for George in the web browser

or look out for announcements in the respective dedicated Slack channels (#design-system-web, #design-system-app)