How Altinn Studio uses Designsystemet

Altinn Studio is a tool for creating digital services. If you use Altinn Studio to build services, you automatically use components from Designsystemet!

For Team Altinn Studio to achieve their goal of creating a good tool — a good design system must be the foundation. The developers at Altinn Studio need components that are accessible to users in a good way, while also allowing them to extend the components to more complex ones.

"It's important that it's possible to extend the components to more complex ones, because all products need to solve a unique need in the market, and often situations arise where more specialized components are necessary. If we can extend existing components from Designsystemet, we'll be able to maintain many of the accessibility requirements and visual similarity with the basic components without having to put in too much effort."

---

When adopting a third-party solution, whether it's Designsystemet or something else, it's important to consider some basic rules to ensure quality and security in your solution.

Designsystemet offers a wide range of basic components that can be designed in many variants. An example is the button component (see figure 1).

Click the image or press Escape to close

Although the button component comes in many variants, that doesn't mean you and your team should use all the variants. Designsystemet offers these possibilities to be flexible and provide you with functionality that is both commonly used and follows familiar patterns.

Designsystemet has documentation on patterns for when the different variants should be used. See for example the button at this link.

How can we ensure that an entire team has control over which variants should be used where and when in the team's product, and why is this so important? It's primarily important because we need to develop a solution that is well-thought-out and conveys a cohesive product that the user understands. We must therefore ensure that the same type of tasks for the user are solved in exactly the same way, both visually and functionally across the product. This also means that we must ensure that there isn't a random implementation and user experience based on which developer implemented the function, but rather have well-established concepts in the team.

So, this means we must ensure to maintain three important main points when using Designsystemet.

1. We must be able to establish our own patterns and concepts that are adapted to the target audience of our product. This ensures a good user experience for our target audience while maintaining cohesiveness across products by using designsystemet.no.
2. We must ensure that the entire team has confidence when updating the npm package from Designsystemet.
3. We must ensure simple handling of Breaking Changes, both for confidence — but also to ensure that the team doesn't lag behind on major versions.

How can we maintain our own patterns, concepts, confidence, and breaking changes? The key word here is isolation. By isolating third-party systems, we increase control over the third-party system internally in the codebase and in the team.

What does it mean to isolate a third party? It's about ensuring that we only have one integration point with the third party. In this case, it means we only have dependencies on Designsystemet in a single place. How can we achieve that? By using the facade pattern.

The Facade Pattern

The facade pattern in software development refers to a design pattern that allows clients to communicate with complex systems through a simplified interface. It's used to hide the complexity of underlying systems and promote a more modular and maintainable codebase.

Altinn Studio uses designsystemet.no with the help of the facade pattern.

Team Altinn Studio uses a monorepo, which means they can create their own packages internally in their own codebase. This promotes the ability to build modular and scalable code.

Altinn Studio has therefore developed its own package internally in the monorepo that they call studio-components. What's the difference between Designsystemet and studio-components? The difference is that Designsystemet offers a complete design system that includes tokens for colors and spacing, as well as basic components. While studio-components follows the facade pattern to build on the components from Designsystemet, and also uses tokens from Designsystemet. In other words, Altinn Studio achieves isolation of Designsystemet by using studio-components. It also gives the team the opportunity to define their own patterns and components for their needs.

Are you curious about studio-components? Altinn Studio has documentation of the components at https://components.altinn.studio. At the time of writing, the documentation is under development and more information about patterns and concepts is coming.

Here, Team Altinn Studio achieves isolation of Designsystemet, while also opening up for extending Designsystemet with more complex components for their own needs. The advantage of extending Designsystemet is that you see the whole picture and recognize the composite components because they are built up of one or more components from Designsystemet.

For example, Altinn Studio needs an ExpressionEditor. This is a component that becomes too specific for Designsystemet, so it's not practical to let Designsystemet develop and maintain this component. Team Altinn Studio has therefore created their own component in studio-components that extends Designsystemet by using the basic components Designsystemet offers. The component also uses the same tokens for spacing and sizes that are used in Designsystemet. In figure 3 below, you can recognize the whole because they use the basic components in Designsystemet as building blocks. Cool, right!

Click the image or press Escape to close

Designsystemet is developed in a way that makes it easy to use and extend the components to the more complex ones where needed.

Here, Team Altinn Studio maintains the first principle of being able to define their own patterns and concepts for their product, to meet good user experience. This also simplifies the work day for designers and developers on the team. Because they have created a reusable component for all places where it is necessary to edit an expression.

How to Maintain Confidence?

Let's continue and find out how we can maintain confidence when updating to a new version of Designsystemet.

To achieve confidence and security when updating third parties, it's important to isolate the third party. If you don't isolate Designsystemet, you must have direct dependencies on Designsystemet in all pages and components in the app. This means that you have to visit all components and pages that use a component from Designsystemet that gets a breaking change. This means that we potentially can have hundreds of files that are changed, just because we made an update of Designsystemet. Figure 4 below shows a simplified illustration. The illustration shows four pages that use a button directly from Designsystemet, i.e., no isolation. This means that if the button gets a breaking change, code must be changed in 4 page components. In real life, it can be about changes in hundreds of components. This makes it uncertain whether everything works the same as before the update.

Click the image or press Escape to close

How can we solve this problem? That's right — we can solve it by isolating the components using the facade pattern.

Figure 4 illustrates how we can isolate using the facade pattern. By isolating external sources in their own facade components. We can export only the necessary properties to our actual application. When a breaking change comes, we only need to implement the change in the facade component and keep the same API out to our own application internally. This means that we get only one file to change instead of 4 page components as shown in figure 4.

When implementing facade components, it's also important to ensure good unit tests for the facade components. So that we are sure that the component works in exactly the same way both before and after re-implementation of breaking changes.

When we isolate our components, we eliminate the need to change the existing code in our application itself. The only part of the code we have to adjust is the facade component. This results in pull requests containing updates for breaking changes remaining small, while the tests for the facade component assure us that unchanged code works and behaves as before.

Click the image or press Escape to close

Now that Team Altinn Studio has achieved isolation of composite components, frontend developers and designers can work more closely together between what is technically implemented and the sketches in Figma. This means that the Figma sketches can reflect the component names in studio-components.

Now they can document and use the same components and names both in Figma and in code. This makes it easier for the team to establish patterns and reusable components that solve the same problems across the product. Now the facade components can also limit the number of variants of the component from Designsystemet, making it less likely that variants that shouldn't be used are used.

The Altinn Studio codebase is open source and therefore openly available to everyone. If you're curious about the studio-components code, you can find the code at this link https://github.com/Altinn/altinn-studio/tree/main/frontend/libs/studio-components.

It's crucial to ensure that the components that make up the facade package are simple. This means they should only receive information as input props, based on this input, deliver an expected result back. It's essential that the components in the facade package do not make API calls or have tight connections to external third parties. This can lead to reduced reusability of the components.

Summary

Now we've learned that we should consider isolating third parties that are used as a central part of our own solution. We've learned that isolation will create confidence and predictability. It will help to document and develop internal concepts and patterns that build further on Designsystemet for the product's needs, while maintaining the whole. It will help to create an even closer and better collaboration between design and development.

Bidragsytere

David Øvrelid