February 12, a Design Systems Meetup was held at DOGA in Oslo. This was a follow up to the Design System Power lunch at Sparebank 1 and a breakfast seminar at Gjensidige. Both events had a good turnout but this meetup shattered all expectations and ended up having over 400 participants, with close to 250 on the waiting list.
The meetup consisted of inspiring talks from NAV, NRK, Ruter and GOV.UK and how they approached constructing their design systems like the UX Portal we have in Visma at ux.visma.com. You can find all the talks further down in this post.
A lot of the issues that were raised are the usual suspects when it comes to the construction and implementation of design systems. But some of the things that got mentioned are particularly important to reiterate because they should be some of the fundamental considerations one should make before planning and implementing a design system.
Why are you creating a design system?
This question was mentioned by several speakers but it was a central point in the presentation given by NRK who continued: What is you systems mission? What and who should the system support? And in which way? These are questions that you should take some time to discuss before you start creating your system. Consistency of visual design is usually a starting point, but it does not have to be.
In NRKs case it was in fact not the main goal of the system to make everything consistent. Rather they wanted every product to be true to itself and let it deliver the experience that it was meant to give. So the NRK News app is visually different from NRK TV, NRK Radio, NRK Super and the YR app. And each of those apps is visually distinct from the others. But in most cases they do share some common design and structural “DNA”. And that is supported by the design system with the intent of making the production of these products more efficient. The particulars of the design and implementation are decided by the individual product’s designer and developers.
Another point to consider is if you need to create everything from scratch? Do you need your own Design system descriptions? Or could you use existing services or products to contain your design system? Do you need to mix the code and the content? Or could they live separately? Could guidelines and visual elements be in something like Frontify, and code snippets and CSS definitions stored in similar developer-centred solution?
Adding value to the system
When your system has a mission, defined user groups, and a thought behind how it should be used, you need to know what to do to add value to the system. How do you get people to start using the system?
ABB talked about their system which had to support a range of products in different markets. The result is a lot of teams working with different implementations running on different frameworks. ABB’s solution was to make their system technology agnostic, so the particular constellation of elements that a particular team or product has does not impact their ability to use the design system.
Design tokens as used by Ruter (photo by Odd-Wiking Rahlff).
NRK also used their system to remove boring tasks from the developers. They used time to read through the documentation of different browsers and versions of browsers and what they supported of new functionality and then constructed the different components so they would behave in a predictable way when rendered.
A couple of the companies had constructed a colour contrast checker within their system. So that designers and developers could easily check to see if the proposed combination of predefined foreground and background colours passed the WCAG contrast requirements for readability. This is an excellent way of both adding value and simultaneously increase the use of the system. There are many contrast checkers that you can use, but one built into your design system already has all the company’s colours ready to test. No need to cut and paste colour hex or RGB values, just click to choose.
Ruter pointed out that you need to give the users compelling reasons for choosing to use (or just visit) your design system. And when you get them in, convert them into ambassadors for your system. In this way you get a helping hand from the users of the system to introduce additional users to the system and spread knowledge of its value throughout your organisation.
One interesting thing that ABB did during the planning phase was to set up a business model canvas for their design system in order to see what value they provided, who their customers were and how that value was translated to those customers. This was discussed and documented. The value they would deliver and to whom they would deliver it was thus clear from the beginning of the project.
And as mentioned by Tim Paul, lead designer of The Government Digital Service (GDS) (responsible for GOV.UK), a large part of your time will be used helping others. They were delivering design consultancy through Slack, and that was considered part of the service.
ABB’s presentation (Photo borrowed from IxDA Oslo).
How to scale?
You know what the system is suppose to achieve, you know who the users are and you know how to add value to it and communicate that value to the rest of the organisation.
Now you need to decide if you are going to be the gatekeeper for everything that enters you system, or if you should give other designers and developers the feeling that this design system is something that they have a stake in and are a part of. Should developers just be able to send in requests for new components or should they be encouraged to make suggestions that can be added directly to the system?
GDS had established a process around this. They have a design system team of about ten people. But they get suggestions for new components from different design and development teams around the country and every month an independent group of designers and developers from different departments reviews the suggestions and evaluates them according to a set of criteria that anyone can view so that the process is as transparent as possible.
The same things applies to Sketch libraries. A lot of teams use Sketch, but GDS does not provide any libraries. This is something that the design community within the government has provided to itself. And according to Tim they don’t want to be an ivory tower, but would like to reduce the involvement of GDS in the process of adding new things to the system. They want it to be a democratic process.
NRK has a bit more restrictive process, where developers can suggest new possibilities or components, but it is the master vision of the thought behind the system that decides if a suggestion will actually be added or not.
The GDS process might take a longer time to go through, but you get people to feel that the design system is something that they are a part of and have influence over. And it is easier to get new components into the system when you have a bigger pool of developers and designers that can create them.
A more centralised way of working, like they way NRK presented, can be faster and make sure that what is added fits with the rest of the system and is easy to use both for new and existing users.
It was good to see that many of the same issues and challenges that we have faced and discussed can be found in other companies. And even if our own design system is not fully developed yet, our starting point seems to be pretty good considering the time and resources that we have available for this type of work. And that we can continue making sure that the system lines up with our vision, continue adding value to it, and make sure that we look ahead so that the system can handle our future design needs, and ease development and thus support our company.
Links to videos of the talks
- Opening keynote by NAV CIO Jonas Skjærpe (Norwegian)
- Ruter: A design system for public transport
- ABB: Design systems within the industrial domain
- NRK: What more is there to a design system, than design?
- DIPS: A design system for life and death
- Norsk Tipping: The journey towards a consistent user experience
- GOV.UK Building the Design System
- NAV: Building a design system across multidisciplinary teams