Creating a common language between designers and developers
Streamlining the development and design process through consistent and coherent design
Design system website
SSB page templates
I was brought in to work at Statistisk Sentrabyrå (SSB), the largest provider of official statististics in Norway. Together with another UX/UI designer I was tasked with developing a design system from the ground up, utilizing Atomic Design which breaks down the web platform and its components into the fundamental building blocks (e.g. Input field, button) and gradually building larger components (e.g. Search field, header) – making sure the new components are updated on par with the new visual profile, satisfying WCAG 2.1 requirements as well as overall user experience and visual coherency.
Through an iterative design process, by analyzing, breaking down and mapping the required features. I made mockups, designs, conducted user tests and used tools such as Sketch, Figma, Principle, Zeplin to create and communicate the design to developers. As a conclusion to this project, a fully functional design system was created with respective components, we also layed out rules such as, grid, color palette, typography, spacing, baseline as well as explanation for each component on a design system website showcasing all available components for easy overview and creating a common platform for discussions.
In a big organization like SSB, there are many teams working at all times on different products, often not communicating with each other and sometimes outside agencies and consultants are brought in to deliver a product or working on a part of the product. The result of this is that the website/products starts to look like a patchwork and creates both inconsistencies between products as well as disjointed user experience.
This is something I saw very early on when breaking down the functionalities of the web platform and its components. There was a large discrepancy between components that had the same functionalities. For example, 6 different types of buttons with different appearance, size, shape.This effectively puts upp an unnecessary difficulty for the user of the platform.
Communication or rather the lack of communication has created an environment where teams often times create solutions based on their own feeling and needs, which creates a large discrepancy between solutions and product released.
As mentioned previously, different teams creating different solutions without a consistent guideline means the design quickly looses its consistency and instead of solutions being tailored, it becomes a temporary solution for that specific project.
Over time, various new features gets added. However, without a system in place the older features become outdated and left on the platform creating discrepancy and causing the platform to loose its identity creating a disjointed user experience.
In short, a design system is a collection of reusable components, guided by clear standards and can be utilized to build different solutions and products. A design system solves the aforementioned problem definitions as its a method which provides a consistent experience and coherent visual language across the product. However, it’s important to note that design systems are not only a style guide, in order to fully utilize a design system it’s equally important to understand the context of use and the ”why”.
Atomic design is a methodology for creating design systems. By using Atomic Design in the creation of a design system, we can have a more methodical approach towards build a system and its components. Inspired by chemistry, where everything is comprised by atoms, these atomic units bond together to form molecules and eventually evolve into more complex organisms. The same concept can be applied when working with digital interfaces, by breaking down functionalities to the most basic building blocks on the atomic level (buttons, labels, input field etc) and using these atoms to form bigger and bigger components (e.g. a search field).
Within Atomic Design there are five distinct levels – Atoms are the basic building blocks, in the context of web interfaces this translates into for examples, label, input, button. Molecules are groups of atoms bonded together, with the example above, a level, input and button aren’t too useful by themselves but here we can combine them together to create a search field. Organisms are groups of molecules joined together to form a relatively complex, distinct section of an interface. At this level we can start to see the interface taking form. On the template level, now we have a combination of organisms together to form a more structured page layout and can more clearly see the design coming together and how the different components interact with each other. The last level in Atomic Design is pages, this is a high fidelity presentation where placeholder content is replaced with real content to give a more accurate depiction of the pages.
Phase 1. Planning & Definitions –
We also asked ourselves what kind of design system we were building, who it was for and what the purpose was. This comes back to the earlier problem statements and the culture at SSB. Due to the fact many products are being worked on simultaneously without much communication and guidelines, we saw products being released striving further away from the SSB branding and coherency between products.
Strict or loose?
We had a choice between a strict and loose system, a strict system provides comprehensive and detailed documentations, synchronized between design and development. While, a loose system allows for more experimentation and provides a more general framework with freedom for change. We decided upon a strict system with some flexibilities, due to the fact SSB has a lack of designer in the organization which means many teams often work without designer. If we created a loose system it can quickly lead to design system not being integrated and used.
Modular or integrated?
We also had to consider whether or not we should make a modular or integrated system. In our case as we had atomic design in mind, this made the choice quite clear. A modular system created flexibility with interchangeable and reusable parts, which suits SSB’s need quite well as the platform often introduces various different type of web products.
Centralized or distributed?
Lastly, whether or not we would have a centralized model or distributed model of the design system. In a centralized model, one team is in charge of the system and makes it evolve. In a distributed model, several people in several teams are in charge of the system. While this could make the adoption of the design system faster, we also saw the potential of design system loosing its consistency and predicability. In the end, we choose a centralized model but with a twist, allowing anyone within SSB to participate and make suggestions for improvements to the design system, this way we could create a sense of ownership and make sure the design system continues evolving and satisfying the needs of SSB.
Work in progress
What have I learned?
Working with animations has taught me how to appreciate the extra dimension that it adds to the design. In our case, we used it as a way to challenge the mental model of the users and a way to prompt users, but at the same it is equally important to balance the amount used, as it can become both distracting and annoying for the users.
Less is more.
While working on the project, I found myselfs often times trying to add functionalities or wanting to create a more robost design as if I was designing a whole new system. But both from feedbacks and insights gathered through out the process, it was proven that simplicity is king. As our goal in the end was to create something that enchances the platform not remaking it.
Everyone can be winners.
It seems like, often times there are always a compromise between user goals and business goals in design. Where you have to choose between one or the other. But for this project I believe we created a system and design that could benefits both ends. In that, the underlying design can consider both sides without contradicting each other.
What I'd do differently?
One regret I have from the project was that we did not manage to incoporate the interactive prototypes in a “real scenario”, in the sense of a moving background stream due to both technical and time limitations. It would have been very interesting to see how the testers would interact with our extensions in a near “real scenario” where sound and the constant moving background would have to be taken into consideration.
More user tests
In our testing phases, we had Interactions Designers, people who werent twitch viewers and twitch viewers as our testers. We did have a hard time finding a larger sample size of Twitch viewers that were available for user-tests. Another iteration with Twitch viewers specifically would have been even better to validate our design. With that being said, I believe that by including different types of testers we were able to see different perspectives and add another polish to our research and design.