When a conversation to solve a problem for the customer begins, the design system team listen intently and contribute wholeheartedly.

Until very recently, we kept hearing a similar thing on a lot of our Design System drop-in sessions, or more exactly, we kept saying the same thing regularly: "you shouldn't use the ns-highlighter component for that, consider this instead".

But before we get into why this kept happening, let's introduce you to the component.

What's a highlighter in Nucleus?

ns-highlighter is a component that will communicate important information, a warning, an error, or a success message, usually time sensitive and following an action from the user.

The component has been built with accessibility in mind, and its content will be read by a screen reader when the page loads or when it's added to the page after an action by using the role="alert"

And this is where things go wrong. Here is what (the Mozilla Developer Network says about this ARIA role here):

"Because of its intrusive nature, the alert role must be used sparingly and only in situations where the user's immediate attention is required."

We should've foreseen what comes next, but we didn't.

The confusion

The component has been used for how it looks, rather than how it works. Because it comes with a colourful accent and an icon, it was the perfect choice to make something stand out from the rest of a page, like a phone number, or some supporting information that isn't key but worth highlighting to the user.

But by using it for this purpose, the outcome would've been a page that reads out a phone number or a piece of content that isn't important or worth reading out loud on screen readers when the page loads, before anything else.

So we kept saying that "You shouldn't use the ns-highlighter for this" in a lot of the design reviews and drop-in sessions. So much so that we joked about making a mug with the quote!

But this wasn't the designers' fault, ultimately we made a mistake.

Where did it go wrong?

We picked the wrong name for the component. While we did pick a name relevant to what the component achieves, it wasn't the right verb to use. Highlighting isn't strong enough to represent what the component does. And the designers picking this component were doing the right thing: picking ns-highlighter to highlight a piece of information just makes sense.

The problem is that the component doesn't highlight something. It warns the user about something, it alerts, it requires their full attention because the information contained in it is important to what they are doing, or about to do.

And looking back at our story tickets, this is what we could find in the comments when it came to finding a name:

  • ns-windsock
  • ns-flag
  • ns-marker
  • ns-pennant
  • ns-roadsign
  • ns-support
  • ns-highlighter

Even more obvious ... our initial proposal was called In-page alerts (this type of ticket where we capture the needs/problems to solve with a component, and all existing evidence and research available).

In retrospect, we could've named it ns-alert, ns-flag, or ns-roadsign and we would probably have seen fewer misuses.

What we did about it

But we made another mistake, and that was not recognising the need for a softer highlighter. And the repeated mistakes told us the hard way that we probably needed to offer a solution to make a piece of information stand out, but more softly, without capitalising on a user's main senses when they access the page or take an action.

And this time we learned our lesson and picked a name that will hopefully be less confusing: ns-standout.

The new ns-standout component in its discreet variant.

We are also considering renaming ns-highlighter to ns-alert as part of a future breaking change to completely remove any confusion.

And in the future, we'll pay extra attention to the names we pick, and how they could mislead or be perceived in different ways by those using Nucleus.

Learn more about ns-highlighter and ns-standout in our documentation!