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.
Both NRK and Ruter had a similar approach when it came to the code components: Code everything to standard, and then translate this into the framework of choice for a specific developer or team. NRK made everything in pure HTML, CSS and vanilla javascript. Not only to make things more reusable, but also to help support web standards, and make things accessible.
