Ariel
Salminen
Design Systems Architect
Ariel Salminen is a Design Systems Architect on the Nord Design System team. Her career spans from freelance consulting to working with some of the biggest enterprises in the United States. Ariel is recognized for her hybrid background in design and development which has led her to help various teams bridge the gap between these disciplines.
Ariel is also an active open source contributor and an author of various popular open source tools used by companies such as Adobe, AT&T, Cisco, Microsoft, U.S. Government, TED, and Monotype to name a few. She likes cycling, composing music, writing poems, and great typography. Not necessarily in that order.
Nord Design System at Nordhealth
Can you walk us through the current state of the design system you're involved with?
We launched the first alpha version of Nord Design System exactly three years ago in February, 2021. For the first (almost full) year, I was the only team member working on Nord. During that time, my focus was primarily on internal user research, obtaining buy-in and budget for the system, and creating the foundational design and code architecture. These foundational elements are still in use today.
In the summer of 2021, we hired our first Product Designer, Eric, and a little later in the year the first Frontend Developer, Nick, to join the team. This growth allowed us to expand from just the foundational and architectural work I was doing to actually shipping usable Web Components to our product teams. Later on, we also expanded the team with two more persons, Dave and Elwin, who both play a crucial role today in the growth and success of Nord.
Fast forward a year, to April 2022, we announced the 1.0 release of Nord Design System and moved most of the tools out of beta. A lot of the internal product teams were already utilizing our tools before this, but the release still marked a major milestone for our team and I even wrote about it in my personal blog if you’re curious to find out more.
As a design systems team, one of our goals has been to strive for modularity to reduce the complexity and improve our system’s reusability by breaking it into small, easier-to-consume parts. And so, if you consider where we started from in late 2020, we’ve embraced this thinking ever since and today provide 10 easy to consume Node.js packages in addition to our modular Figma Toolkit and the various themes included.
At the time of writing, roughly 60% of Nordhealth’s product suite has been either completely migrated to use the Nord Design System, or has been built from scratch with the help of Nord Design System’s tools.
What tools do you use to build and maintain your design system?
Behind the scenes, we use a custom solution that I built on top of Eleventy, the static website generator. Technically, the whole system is a single monorepo with various Node.js packages and Eleventy acts as our playground and documentation platform which connects all these packages together.
Nord’s Web Components are built with Lit and we use a tool called Custom Elements Manifest Analyzer to generate metadata from the WC source code that is then fed to Eleventy to process and generate documentation from. We’ve developed similar JSON APIs for the majority of our packages, and a significant portion of our technical documentation is automatically generated from the system’s source code in this manner.
Our components architecture is based on Web Components because we needed to support various tech stacks and couldn’t just choose [a framework] because the different tech stacks were picked by different teams, or even different sub-companies, for different reasons and we would have never succeeded if we would have tried to force everyone to use a specific technology like React.
Additionally, I’ve built us a couple smaller tools to help people working with the system such as Nord Theme Builder and Nord Color Generator which is a tool that generates color palettes programmatically for use with our color themes.
How do you balance the need for consistency with the desire for creative freedom among your designers?
There are two levels to design systems at Nordhealth. In addition to Nord, we have product level subsystems that provide more freedom for the product teams to create their own product patterns while still utilizing Nord and its theming capabilities.
Nord also heavily utilizes CSS Custom Properties (sometimes referred to as CSS variables) to make all of its parts themable and customizable. This provides fine grained control over the presentation and gives more creative freedom to our designers.
How do you stay true to your vision for the design system, even when faced with external pressures or trends?
It’s often tricky to find the balance between the two, but I believe it’s crucial to be open to criticism and listen to your users. Product teams utilizing the system usually have more business context as well, and these conversations help us to provide better tools and raise the collective quality of each individual’s work.
We also want to reduce potential rework and frustration for our users, and having these conversations helps; our team gets more context about what a product team is trying to achieve, and what’s perhaps stopping them from achieving this with the system today. Eventually, we can either integrate their feedback into the system, find an alternative solution that already exists today, or clarify why specific parts of the system are designed in a certain manner.
At the end of the day, it comes down to being transparent and empathetic towards your users while being clear and confident about the strategic and creative direction of the system.
How does your team collaborate on the design system?
Our team follows a hybrid model where the central design systems team is responsible for the overall direction. Growth is partly pushed to the consumers, who drive Nord's evolution. This hybrid model helps us keep Nord accurate and useful.
We also try to be as transparent as possible and share what we’re doing whenever we can. Building the system transparently increases its visibility and accountability and pushes us toward higher quality.
Are you tracking your design system? If you had to choose one metric to measure the success of your design system, what would it be and why?
We track the adoption rate of various products and sometimes run internal user surveys, but we don’t do extensive tracking such as I’ve maybe done with some of the previous design systems teams I’ve worked with.
If I had to choose, I imagine I would still choose to track the adoption rate over time and how that impacts the productivity of our designers and developers. An important metric for us is how quickly you can pick up our tools and build something. That should be minutes, not hours, days or weeks.
An important metric for us is how quickly you can pick up our tools and build something.
If you could go back and change one decision you made in your design system journey, what would it be and why?
The original package structure of Nord was too complex to use and there were too many dependencies between the different packages overall. So if I could rethink that decision now, I would simplify the architecture.
All of this seems quite evident in hindsight, but my original thinking was to strive for as much modularity as possible to reduce the complexity. The modularity went a little too far though, and eventually increased the complexity for our users because we didn’t consider the API carefully enough.
Originally, if you wanted to utilize any of the components, you had to first install and link our Design Tokens, then install and link Webfonts, then our CSS Framework, Themes, and finally the Web Components themself. That’s quite a few steps, huh?!
In the re-designed architecture, we have two different levels to the packages:
Level 1
On the first level, we have packages called Webfonts, Design Tokens, and Nordicons. These packages are like atoms of the systems as they don’t have external or internal dependencies into any other packages in the system.
Level 2
On the second level, we have CSS Framework, Web Components and Themes. These packages internally depend on the first-level packages. Still, we wanted to hide these dependencies for the end user, Frontend Developer in this case, meaning that you’d more or less always install one or more of the second-level packages only into your app to consume parts of the system.
Do you use any kind of automation or AI tools?
One of our team’s core principles is to automate everything we can. We value the time of our colleagues, users, and our future selves over our own so we are always proactively looking for ways to automate repetitive tasks and testing.
As I mentioned previously, we’ve built automation which generates the majority of our documentation visible at nordhealth.design. In addition, we also have comprehensive automated tests to catch issues early on. These include for example screenshot snapshots to catch visual regressions, tests to ensure we meet the accessibility requirements, color contrast requirements, end-to-end tests, integrations tests, linting, and so on.
Additionally everything related to building, versioning, and publishing of Nord’s packages is obviously automated. But I guess this is more of a given nowadays.
Where do you see design systems heading in the next few years?
Honestly, I think we’re in a pretty solid state and I don’t expect any major shifts in the next few years. For Nord Design System specifically, I see us evolving the system by building missing components and adding new features into the existing ones. I also see the need for increased design systems support since more and more product teams are utilizing the system now. I’m also interested in exploring how we can better integrate AI into our workflows.
What's one thing you wish more people understood about design systems?
Running a design systems team is vastly different from running a regular product team. In a regular product team, you might have a problem, a business objective, or a goal, and then you build something to solve it. And most of the time, you don’t have to explain why that work is worth doing.
But when it comes to running a design systems team, a big part of our job is often internal marketing; constantly explaining why the work is worth doing in the first place, why the team should exist, and the benefits of that work. So you end up battling with this existential threat while striving to maintain cohesion and protect your team.
And I hope more people would understand how this can be a significant aspect of our job in certain situations, particularly when starting and attempting to secure buy-in for the system's work.
In your opinion, what are the most overrated and underrated aspects of design systems?
Tools and processes are often overrated, while the people aspect gets underrated. You can have the most beautiful design system and still have no one adopt it because you’ve ignored that design systems are mostly trying to solve a people problem.
If you could have a coffee chat with any person from the design (system) space, who would it be and why?
If Reid Miles was still alive, I’d like to chat with him. Mainly because, in my eyes, Reid did the same to modern typography as Charles and Ray Eames did to modern architecture and furniture by pushing forward the way the typography is treated with his bold, playful designs, creative use of typefaces, and distinct preference for contrast and asymmetry.
Coffee with Reid Miles
What's one piece of advice that you would like people to remember from this interview?
What's your favorite thing to do when you are not in design systems?
Spending time with my kids and lovely boyfriend gives me so much positive energy. Occasionally you may also find me cycling, composing music, writing poems, and tinkering with typography. ❦
