Design systems: The BNARL model
Strategy framework to shape a healthy culture around design systems.
Common criticisms about design systems are mostly rooted in unhealthy design system culture. When a design system is set in place, there are a few common pushbacks:
- It limits designers’ creativity and becomes too rigid. Despite it can increase speed and maintain consistency.
- The designers feel that design systems ignore context, and give one-size-fits-all components to use.
These criticisms are valid. It often comes from an unhealthy design system culture. The BNARL model helps the design system leads to be aware of the culture and set a necessary intervention.
How the BNARL looks like?
Here’s an example of the BNARL model in my team:
- Beliefs: our users are not familiar with tech and need assurance
- Norms: everyone can contribute and evolve the design systems
- Artifacts: we make tools to support us, not the other way around
- Rituals: high participation where people can exercise their skill
- Languages: plain, simple, and easy to remember language
I intentionally keep it high-level and simple since these are key strategies. In this model, we don’t talk about how-to. Rather, it laid out the desired culture. We’ll talk more about the how-to in the next series.
Use the BNARL model to assess the current culture, and use it to shape the desired culture.
Beliefs
Beliefs express the fundamental knowledge we have about the users we serve and use it as one of the primary lenses in our thinking process.
Reflection: How aware are you of the team’s deepest beliefs about the users? Collect them as a set of hypotheses and test them as you go. Don’t blindly make a decision with the wrong beliefs.
In our case, we build products for teachers and educators in Indonesia. Through our foundational study, we learned there are teachers who are reluctant with technology and anxious to take consequential action.
By being aware of our beliefs, we can use them as lenses in our thinking and decision-making process.
Norms
Norms set a tone on how people should behave around design systems. Lining up in Japan’s station would serve as a good example of a norm.
Reflection: Observe how people act in a certain situation. For example, how often do people create a new component? If they quietly create the component. Then the current norm is to stay quiet when creating a new component. Ask yourself: Is that the desired behavior?
What should designers do when they use the library and can’t find a good component to solve their problem? Is it OK to suggest an improvement?
Should engineers create the component from scratch when they inspect a prototype and see a component that doesn’t exist in the library?
We want the norm where everyone can contribute and evolve the design systems. In reality, this will be translated into a few tactics down the line. See collaboration ground as an example.
Artifacts
The strategy on artifacts sets the perspective on how we want to see the artifacts (UI kits, principles, etc) in our day-to-day. It is less about what artifacts we will produce.
Reflection: What is the role of the artifacts in your team? Is it a utility tool that you see as a supporting tool? Or do you treat it like a gladiator sword that is sacred?
Is it OK to challenge the typesetting? Is it OK to propose a new color token if a designer feels the need? Or should we see the color and token as permanent variables that we rarely change?
For us, we make tools to support us serve users, not the other way around. This means we’re open to change the components, principles, or design foundation as long as it helps us to serve users better.
Rituals
You can see rituals as a supportive element to reinforce the norms you want to shape in the culture.
Reflection: What kind of rituals can you design to reinforce the norms? Ritual is one of the most common leverages you can use to shift the current norms to the desired norms.
When I joined the team and talked with a few designers. I realize one interesting dynamic. Most of the designers in our team are proactive and strong in problem-solving. But interface design is not their strongest suit, many expressed it is the growth area they want to explore.
Armed with that insight, I also want to incorporate a way to enable designers in our team to grow their interface skills. Therefore, the strategy for our design system ritual is to focus on high participation where people can exercise their skills.
Languages—smart or plain?
Reflection: What is the perspective you want to use when naming the component or color? Do we want to ensure simplicity or do we want the vocabulary to be catchy?
With design systems in place, your team will add more of a shared vocabulary. For example how you name the color. Would it be better for your team to have a smart and catchy name like sunset or forest? Or do we prefer plain naming like green-80 or action-neutral?
It depends on your purpose. But for our team, we a plain, simple, and easy to remember language.
Up next → #3: From BNARL to interventions
Budi
Blog: buditanrim.co
Newsletter: buditanrim.co/newsletter
Twitter: buditanrim
- Intro: How to shape your design systems culture
- #1: LEGO Kits Syndrome
- #2: The BNARL model
- #3: From BNARL to interventions
- #4: The Pattern Friday as Ritual
- #5: How to Facilitate a Pattern Friday?
- #6: A Case Study: Bukalapak 2019
- #7: A Small Team Case Study: Indonesia Education Civic Tech 2021
