Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared Severity color palette (Borealis Update) #203387

Open
gvnmagni opened this issue Dec 9, 2024 · 2 comments
Open

Shared Severity color palette (Borealis Update) #203387

gvnmagni opened this issue Dec 9, 2024 · 2 comments
Assignees
Labels
Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins.

Comments

@gvnmagni
Copy link

gvnmagni commented Dec 9, 2024

Following the issue raised here (#202985) and given the upcoming release of Borealis, we thought it could be a good idea to take advantage of this transitioning phase to put together a Severity color palette the could be shared across solutions.

Currently there is a little bit of inconsistency when dealing with this kind of data, the lack of clear guidelines resulted in a different use of colors across the product, which is not great for our developers and designers that every time needs to find a solution while at the same time generating a scattered user experienced.

A first mapping of cases can show us exactly this behaviour, the following image shows how different this use can be and it shows perfectly the need for a clear set of shared guidelines

Image

Before introducing our proposal, a few constraints/requirements that need to be specified:

  1. New palette needs to be agnostic in terms of semantic. (Critical in Observability might means a different level of severity than Critical in Security)
  2. Needs to be based on color primitives provided by Borealis, so that it will be automatically updated in case of any future change
  3. Needs additional levels, in case of future cases in which we might need that
  4. This is a separated palette from what we typically call Status, which normally provides Green-Yellow-Red for Success-Warning-Danger. This palette is meant to map levels of dangers, with neutral or negative meaning.

Proposal

A new set of 15 colors divided into severity groups, spanning from Red shades for Danger levels, through yellow for Warning, while providing at the same time a group of colors for neutral categories of data.

Image

Specific color primitives and hex codes:

Severity Color Palette

Level 14		|  Danger 90		|		#C61E25
Level 13		|  Danger 80		|		#DA3737
Level 12		|  Danger 70		|		#EE4C48
Level 11		|  Danger 60		|		#F6726A
Level 10		|  Danger 50		|		#FC9188
Level 9			|  Danger 40		|		#FFB5AD
Level 8			|  Danger 30		|		#FFC9C2
		
Level 7			|  Warning 30		|		#FCD883
Level 6			|  Warning 20		|		#FDE9B5
		
Category 5		|  Blue Grey 30		|		#CAD3E2
Category 4		|  Blue Grey 45		|		#ABB9D0
Category 3		|  Blue Grey 60		|		#8E9FBC
Category 2		|  Blue Grey 75		|		#7186A8
Category 1		|  Blue Grey 90		|		#5A6D8C
		
Category 0		|  Muted Grey 20	|		#E5E9F0

Few notes:

  1. Using Danger 90 as highest level of severity allows us to be consistent with EUI. With this approach, the same color will be used in all contexts
  2. The palette doesn't change according to color mode (light/dark). The colors picked are contrasted enough to provide a 3:1 contrast with dark background, being accessible in dark mode.

Usage

This color palette will be provided as a list of color from which teams can pick according to their needs. Therefore it will be needed, from teams, to be a cautious in how it gets used and to make a couple of choices.

The main principle to follow would be the following, to always use the whole extension of this scale, which means to try to distribute your own levels of severity within proper groups of colors first (yellow for warning, red for danger zones) and to distribute them as much as possible.

This should allow us to get the following results:

  1. Maximise contrast between levels
  2. Always obtain our desired shade of red as most dangerous level. This will make the user experience the same every time, reducing the cognitive load. Main goal here is to be able to create a context in which our users can always associated our desired shade of red to danger that need immediate action.

An example of this use, picking the same scales shown in the first image of this issue:

Image

Which will get us this final result:

Image


Conclusions

This proposal is meant to be a solid base of colors that could be shipped quickly and be ready, if we are lucky, for 9.0. It's not meant to be perfect nor final, the conversation is still open and I would love to hear feedback from anybody who might be interested.
I do think though that, in order to start building a good user experience, the best would be to start having this in our library and eventually adjust it according to needs, rather than wait a long time before having this available for teams.

Please feel free to add anything to think it's relevant, apologies for the long issue! 😊

@gvnmagni gvnmagni self-assigned this Dec 9, 2024
@botelastic botelastic bot added the needs-team Issues missing a team label label Dec 9, 2024
@gvnmagni gvnmagni added the Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. label Dec 9, 2024
@botelastic botelastic bot removed the needs-team Issues missing a team label label Dec 9, 2024
@gvnmagni
Copy link
Author

A little update after a first very initial feedback from teams. Number of available levels and chosen colors have been received positively, while guidelines on how to use this list of colors can be improved.

An important concept that still needs to be investigated is the rigidity of usage, I would slightly reconsider the subdivision of colors into areas (danger, warning, neutral) in favour of a simple list of colors that are entirely available to teams to be used according to their context.

Some teams might need a lot of levels, some might need their severity levels to be as recognizable as possible, some might even want to use the same level color for multiple severity levels. I would probably avoid giving complex guidelines on how to use this, leaving on teams a bigger freedom, the only thing that probably needs to be fixed as a sort of main principle is that we should always use Level 14 (Red 90) to represent the highest level of severity in every context.

This would allow us to achieve consistency across the product, giving the user the possibility to understand the same color is always associated with the most immediate action needed.

I would use the following image, from now on, as a reference for this palette. I'll keep posting updates here so that we will have a reference for the ongoing conversation.

Image

@gvnmagni
Copy link
Author

An additional couple of updates in order to have full information and being able to set up a conversation in early January.

First, two main principles that I would personally introduce as only guidelines for teams to follow:

  • 1️⃣ If the severity levels available in a specific context are somehow associated with some meaning, it would be great to be consistent with overall share concepts. A very simple example would be a severity level called Warning, in this case I would strongly suggest to use yellow shades, which is a common and well known good practice
  • 2️⃣ The highest level of severity should always be associated with the highest level of color intensity. Regardless of the level itself (eg. Critical, Fatal, Alert...), we should try to use Level 14 of this color palette, so that customers will get used to associate that color to the most immediate needed action.

I believe that if we follow these rules, giving full freedom to teams to apply other levels according to their own needs, we will end up with a consistent use of severity colors in the end.

Second, we realised that teams were already experimenting with these colors and we thought it would be better to have control of the process in order to avoid ending up with tons of hard-coded color values.

EUI team has been able to include these variables (as proper tokens) in their latest release. This means that we can already start using them even if, potentially, they might change in the future. This will help us a lot, being able to point something already available to engineers instead of just pointing to design work (PR)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins.
Projects
None yet
Development

No branches or pull requests

1 participant