How we Grew our Design System Over 5 Years of Design Experimentation
A story told by a designer and a developer from Societe Generale.
The current surge in articles about design systems inspired us to talk more about what we do at Societe Generale. We’ve been experimenting with ours for a long time now, and as a designer who deeply cares about technical details, I personally see it as a huge achievement in my career.
Since design systems are languages that allow designers and developers to work together harmoniously, I put this piece together with my colleague Fabien Zibi, Lead Front developer. We’re going to talk about our design system’s lifecycle and share our experience of fruitful collaboration, hoping it can help and inspire people embarking on the same journey.
How we evolved over the years — a quick timeline
At Societe Generale, we’ve been developing our design system approach since 2014. Back then, we started with already-designed prototyping assets and already-coded components for static HTML to begin harmonizing digital experiences across the SG Markets products, our market place of Business-to-Business (BtoB) financial services.
This allowed us to deeply understand our users’ behaviour with regular financial interfaces and see what types of components and design were the most efficient. Regular feedback over the next couple of years allowed us to finetune our vision.
Starting 2017, we dived deeper into the subject. Defining core principles and guidelines helped us unify the system, and an intense revamp of all our components resulted in a significantly easier design and hand-off process. The whole design team contributed to this work — Lucas Z was at the forefront of this process and certainly remembers this intense moment!
Later on, the growing collaboration between designers and developers, combined with our strategy to recruit early bird projects, made us confident in our design system’s ability to be widely adopted by product teams. This resulted in the release of a fully scalable design system, tailored for BtoB and Business-to-Employee (BtoE) needs with its dedicated ecosystem, used now by over 750 digital projects worldwide.
But wait… let us take you back to the start to take a closer look at the different phases we went through and a quick tour of our everyday tools.
Starting point: building on the past
Creating a design system is one thing but reaching company-wide adoption of the system is quite another. To do so, you need to consider what is already in place and to what extent you can build on it.
When the first services of SG Markets were developed, we used Bootstrap 3 to leverage on the open source community — we did not want to reinvent the wheel, nor the web. It seemed a very natural progression to continue using Bootstrap as the central technology behind the design system — especially after the release of Bootstrap 4 which by default, gave us a core components library, SCSS variables and fixed a lot of accessibility issues.
Our first step was understanding how the new library works. We created a table of more than a thousand SCSS variables which helped us quickly identify which parts needed to be changed to begin the customization of Bootstrap.
Next, we added variables for our specific needs. The result was an “SG” Bootstrap 4 (“SGBS4”) which, with our own art direction applied to the existing components, was ready to be our main framework. The existing use of Bootstrap 3 throughout the company allowed an easy transition to the new system.
Enter the fundamentals
With a consistent technical framework in place, we created our core guidelines for art direction around clear principles which drove the whole conception of our design system.
“Timeless typefaces, dynamic typesetting and strong visual hierarchy.”
Typography
Most of the time, 90% of website content is typography. Therefore, we placed typography at the heart of our design system.
Space
For harmonious layouts and good content hierarchy, we set a calculated ratio between margin, padding and negative space.
Tones
Our choice was inspired by Swiss graphic design and the essence of the financial industry.
At the early stages of the design system, most of our time was spent on core guidelines. Once they were stable, it was easy to define a large set of scalable components. Today, every time we want to add, improve or modify something, we make sure we are in line with these core guidelines because they work together to build a system.
The three building blocks of the design system
The core variables and core guidelines of art direction are the foundations on which we were able to build our design system. In other words, they are the subatomic elements which then allow to create atoms.
#1 Atomic Design structure
Atomic Design is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner.
— Brad Frost
As we already had an existing component structure from our previous technical framework, we decided to keep its philosophy and reduce the 5 original levels of Atomic Design to 3: components, patterns and templates / widgets (embedding APIs and ready to use in production). At the root of these levels, we kept our core variables — typography, colour and spacing — to which we added content guidelines.
With this structure, the result is an easily customisable system where all the components and patterns can be combined or work individually. We define the difference between components and patterns by scale: components are single assets such as buttons, inputs or cards, while patterns combine components into forms, headers and date-pickers.
#2 Patterns, templates and widgets
Curated, well-constructed parts, skeletons and extensions.
Our patterns, templates and widgets are regularly reviewed and updated according to new use cases and feedback that we receive, to make sure that we are delivering the best user experience possible. These assets have also made interface design easy for developers — the whole system is completely reusable and (almost) unbreakable in code.
#3 Guidelines
Guidance and instructions to help designers and developers use our resources wisely.
Our guidelines are our “single voice of truth” — they give us clear and consistent design directions. Our overall aim is to unify the user experience across our products so that once a user is familiar with one product, they can easily use them all.
The guidelines also make the design phase of product development particularly fast — our designers can ensure that their designs are free from personal style and completely aligned with the system.
Our design process and its ecosystem
Processes and experiences evolve constantly throughout the system’s product lifecycle. To make sure development is harmonious and doesn’t descend into chaos, we need to rely on well-established processes.
We have therefore developed an ecosystem of supporting tools to help communicate and work with our design system consistently.
Design assets available in Adobe XD artboards with components and patterns ready to be used for prototyping.
Live documentation to share the principles and usage rules with code snippets.
InVision and Typeform to share prototypes with our users and projects and collect feedback.
A coding playground which is a live editor where designers and developers can quickly share snippets of code and test components in any of our themes and viewports. This is our most recent addition to the ecosystem. As we work on a large variety of use cases, from less financially sophisticated to very complex, we developed it so that any designer or developer can share their patterns.
A sandbox website, shared with the whole community, for technical experimentation with all the assets in code. It features pages for each group of components and enables us to live-test new versions and updates of the design system (so there are no consequences when we break things!). This adds another layer of feedback to development before the update is live.
Github Entreprise to track, develop and collect issues. For transparency and traceability purposes, we record every variation of our components and collect the feedback, specifications and changes from designers and developers using the system. Anyone can report a bug and even fix it with a pull request.
What’s next? Check and improve!
As of 2019, we’re at a point where we have a stable — but still evolving — collection of assets and tools that we use daily. To go further, we ask experienced users of our design system which new features or assets they would need. In parallel we also ask new users how they think we could improve the onboarding to the design system. By doing so, we create priceless synergy with our users and gradually foster adoption, which is a key success factor. Like many companies around, Societe Generale is made of heterogeneous teams, with different skills inspirations. This makes it a bad idea to immediately impose a new system on these teams and their products.
If you start building your own design system, here is our main piece of advice: stay open-minded! One thing that we learned while creating ours is that it’s impossible for us to be immediately correct about everything, or to make the perfect system, on the first attempt. Building a design system is a large project involving a lot of work, but be aware that anyone using it can have valuable ideas. Therefore you won’t win the war on adoption if you refuse to open the system and make it scalable.
This article is part of our Design System series: 4 false assumptions, getting buy-in, governance & chaos (part 1), governance & chaos (part 2), adaptive colour systems and surviving. Watch this space for more!
Shout out to Henry Daggett and Caroline Ganne for their help on this post and putting up with me and Lucas Z and Fabien Zibi in general.
Visit our Design website to learn more about what we do at Societe Generale.
