Common criticisms about design systems mostly rooted in unhealthy design system culture

When a design system is set in place, there are a few common pushbacks:

1. It limits designers’ creativity and becomes too rigid. Despite it can increase speed and maintain consistency.
2. The designers feel that design systems ignore context, and give one-size-fits-all components to use.

These criticisms are valid and it often comes from an unhealthy design system culture. An example of a culture problem is when the designers think they can’t make a suggestion to the system. The BNARL model helps the design system leads to be aware of the culture and set a necessary intervention.

Use the BNARL model to assess the culture

Like its name, this model consists of five elements of culture—Beliefs, Norms, Artifacts, Rituals, and Language. I don’t invent these elements of culture.

The whole idea is if we disrupt one of the elements, it could shape or reshape the culture. In practice, you can use the BNARL model to assess the current culture. Then, you can use this model to reflect on the desired culture. Once you see the gap, you can start planning the appropriate intervention.

In this article, I’ll share the example of the BNARL model in my team that we use as a key strategy and share the thinking behind each element.

Example of BNARL

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.

The thinking behind the example went like this…

Beliefs we have as one of the primary lenses

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.

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.

This belief becomes one of the lenses we use in our thinking and decision-making process. The team’s beliefs will always be updated as we learn new insights.

It’s useful to observe what people believe about the users. You can observe this through the conversation. People in our team often said something like, Teachers are not familiar with English terms.

Reflection: How are are you with these beliefs? Collect them as a set of hypotheses and test them as you go. Don’t blindly make a decision with the wrong beliefs.

Norms—how people expected to behave

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.

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?

Everyone used to be quiet and not communicating with each other. Whenever someone creates a new component, someone else actually creating a similar one. There is no clear way to communicate across the team.

To combat this, 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. For example, if you want to enable people to challenge the design system, you should provide a way for people to make a suggestion (see collaboration ground as an example.)

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?

Artifacts—what’s the role of the 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.

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.

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?

Rituals—reinforce and maintain the norms

You can see rituals as a supportive element to reinforce the norms you want to shape in the culture.

A meeting will be a common example of “ritual.” If you ever work with the agile methodology, the team retro is one of the rituals.

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.

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.

Languages—smart or plain?

I put languages last because it is a supportive strategy, but still important. With design systems in place, your team will add more of a shared vocabulary. When someone says, “Let’s use Toast component because it’s only a lightweight system feedback.” We can all have the same idea when we hear Toast.

The other obvious example is how we name the color. Should we go with 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.

Reflection: What is the perspective you want to use when naming the component or color? What are important terms and concepts you want to foster in the team? As an example, I always use “affordance” and “signifiers” lately, to ensure people practice this concept.

Thought exercise:

When building a design system, we often forget about the cultural aspect. Culture has been with us since we were born. Humans acquire culture through the learning processes of enculturation and socialization. A healthy culture is the heart of successful design systems.

If you’re interested to expand your own BNARL model, you can use these reflection questions:

Exercise #1: Take your time to talk with people and synthesize their frustrations. When you talk to people, pay attention when their frustration connected to any element of the model (Beliefs, norms, artifacts, rituals, or languages)

Exercise #2 on Beliefs: What is the fundamental belief about the users that your team needs to remember when making a design decision? Be aware of these beliefs. Collect them as a set of hypotheses and test them as you go.

Exercise #3 on Norms: How do you want people to behave in a certain situation? When they want to make a new component, what should they do? Then take a moment to reflect, what is the process looks like?

Exercise #4 on Artifacts: 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? As long as you have a clear why and be open-minded when people challenge that.

Exercise #5 on Rituals: 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.

Exercise #6 on Languages: What is the perspective you want to use when naming the component or color? What are important terms and concepts you want to foster in the team? As an example, I always use “affordance” and “signifiers” lately, to ensure people practice this concept.

Up next → #3: From BNARL to interventions

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