The Interaction of Color Systems

Nov 29, 2017

–

10:30 am

–

Alamo Drafthouse New Mission

Diana Mounter

Director, Design Infrastructure

GitHub

Color is the most relative medium in art. This fact makes working with color in design systems particularly challenging. Few people seem to want to claim to be an expert in color—perhaps because there’s an immensely deep amount to learn, or perhaps it’s because color is one of those things we hate to get wrong. Whatever the reason, color remains a contentious but often critical part of design.

I’ll be sharing my journey into color, from the technical challenges to how people respond to it. We’ll take a look at the efforts required in updating large scale web applications like GitHub, testing the interaction of color with other parts of a design system, creating color naming conventions, color contrast, and color system use outside of the product UI.

Transcript

Una Kravets:

So, next up on our Brooklyn morning crew, we have Diana Mounter. Diana came to New York from Australia, via San Francisco. She spent some time here, but we're lucky to have her in New York now. Diana is the lead at GitHub, where she maintains their CSS framework, Primer. She runs the meetup, which was inspired by Jina's meetup. I love everything Diana's done for the Design Systems community.

All right. Please welcome Diana Mounter.

(Applause)

Diana Mounter:

I can't see anyone, so I'm going to assume I'm talking darkness.

So, I'm going to talk about the interaction of color systems and some of you might know that I stole this or borrowed part of this from a book called Interaction of Color. I don't know and you could see that, on the screen. But one of his famous experiments is the two boxes looking like it was the opposite color from the other side, but they're actually the same color.

So, I'm going to talk a bit about that very and color influence and about building coloring Design Systems.

So, as Una mentioned, I'm Diana. I'm broccolini on most parts of the internet. I'm a Design Systems manager at GitHub and I work from home.

(Laughing)

Diana:

I wanted to add this because I wanted to thank you all for getting up early, at this time of day. I'm usually still in my pajamas, dancing around with my cat. Maybe not quite as awesome as this dancing. So, thank you for being here.

So, I actually wanted to call out that it's partly Jina and Cap that I work on Design Systems, seeing how I'm following Cap today. Way back when I was in Australia and realized maybe using products like adobe Go Live and things like this, this is one of the few bits I've read from start to finish, which Jina wrote a chapter for.

And fast forward to several years later, I found myself chatting to Cap in a coffee shop for hour and then joining Etsy and moving to New York, where I ended up on the seller tools team and we ended up building a new style guide and that's what made me start to realize that's what I really wanted to do. The echo is crazy in here.

So, last year, in March at last year's Clarity conference, I gave a talk a lightning talk. And coincidentally that same day, I had been made the Design Systems lead. I was really excited. This is how I was feeling. Yes, finally. I got to work on this stuff and work on it fulltime. That excitement quickly changes to a lot of mind brainmelting problems, confusion about why anyone wrote code about that and a lot of communication and trying to make friends and win people over to adopt your the Design System. So, one of the most challenging parts of the work that I've done so far was on color systems, which is what I'm going to talk about today.

So, what's challenging? What's so hard about working with color? Well, one of the things is that color is subjective. There's a lot of things that affect how people respond and perceive color. Things like their background, current trends and even the age. There's a ton to learn. I really laughed when I saw this tweet recently, because I feel the same, like, six months later. There's endless amounts of stuff to learn. And, yeah, Jackson's response, sounds like you understand color now, when you realize you're never going to learn it all.

So, I wanted to talk about what you kind of end learning about color, maybe at school, college or many blog posts and you'll often see things like this. With, like, a triadic and complimentary color schemes. You might have used Adobe Color. This is what informed us about color. CMYK is subtractive. Maybe these are really cool mugs, Pantone is a color system as well.

What you might learn about or you might discover through your design tools is that a really intuitive way or a much more intuitive way is looking at saturation and brightness. I didn't realize that maybe this was something that lots of people hadn't discovered yet. But I saw a tweet and people saying, yes, this is so much better. That saturation brightness, but then there's this other thing called saturation lightness. So, is hsb the same as hsl? The good thing is these are both alternative representations of igb and they're meant to be a more intuitive way of perceiving color for humans.

So turns out hsb/v is not the same as hsb/l. Hsl color is with white and HSV lightens the line.

A really good way of seeing this and lots more color variations and on colorizer.org. The hew is the same, but then the saturation and lightness or brightness is different. When you get to extreme, it's four values of red, green and blue. Sometimes those things will line up.

And then looking at color pickers and color tools, this is how a lot of tools have this very similar sort of layout with a gray a lot like square of color with some sliders, for saturation or brightness in here. Sorry. And, then sometimes you'll see things like this, as well. But they don't really represent the color spectrum very accurately. Some some hews have more range in brightness and darkness.

This is this is from Albert Henry Munsell. He said the desire to fit a chosen contour, such as the pyramid, cone, or cube, coupled with a lack of proper tests.

And Runa Madsen, there's history and the study of color is neglected in our color tools and this might be why I found myself using so many different tools when I was trying to work on a color system because no one's quite got it right yet and there's a lot of different ways of looking at color.

So we hadn't even begun designing a color system yet and we found out there's ton to learn, we're never going to learn everything about color and maybe you'll never been an expert and color tools are broken. Surprise. But, maybe on a positive note, maybe that's good. I don't know about you, but I really like it when there's tons to learn. I get excited about that. I'm still excited about learning about color. I feel like I've barely scratched the surface. You can work with color and make it easier for other people.

Also, it's an opportunity for some nice puns in your commits, like, I see red people and orangey blood. I updated these variables. So we're back to feeling a bit like this again, hopefully.

So, let's dig into creating the system. So, hopefully whenever you're doing any project, you're thinking, why are we doing this? And for anyone really, hopefully you're starting off with something that's useful for people using the system. You might have user stories along the lines of this, you're trying to make color easier to work with, you want it to be able to work with color and implement it successfully. A problem maybe not unique to GitHub was that we had all of these 2,449 hex values that were not connected in any way so making color easy to work with, we were failing at that.

And that also makes maintainability hard for people working on Design Systems. We had some problems with we had a few variables for color, but they were things like this, they didn't promote reuse. I can use flash text yellow for a flash text. Of course, people used it in other things, as well, which doesn't help with, like, making things easy when you're working with code. It can contribute to causing confusion.

Another problem was that we had a lot of color combinations that were really badly failing color contrastwise, which is definitely a problem. > And then, our colors were looking a bit drab and one of the designers, link color blue and jean blue, we were feeling there it was time to maybe give things a refresh.

But also, the reason that this kicked off when it did is because of an opportunity. And I think this is an interesting thing to consider and maybe be be aware of. One of the other teams was working on a big refresh of like a logged out marketing sort of pages and they wanted more colors and they wanted to be consistent about how they were using colors and that was an opportunity for Design Systems to jump on that band wagon and put some momentum behind this work.

That, of course, had to be balanced with not blocking that ship or slowing that down and so when you're doing that, you need to have a Plan B mentality so you cannot block it. But it can help get things done faster and that worked out for us.

So, let's get into details of things. So, building the pallet. If you about a month before I started working on the color system, we updated the site better to to be dark. It was white and we went dark. Which was controversial to some. I didn't when that was happening, I jumped in and I had already been thinking about color and it was an opportunity to add some hew to that dark color. So, all of our grays up until then had been really flat gray. Before it was 333. We moved to a gray scale that had a blue hew to it, which just starts to help with that drab feeling or getting away from that drab feeling.

It also was an opportunity to darken our darkest gray, which just helps a little bit with expanding our range of accessible color contrasts and combinations so I had already started on that so that gave me the starting point of, like, okay, I know what our gray scale is. Our grays are going to start to look this. But then I needed to get into primary colors, especially oblique. Because our link color was used everywhere and we tried and tested a lot of different variations. Some of those were quickly rolled out because they didn't provide good enough contrast or because they looked too drab. They weren't getting us away from dad jeans blue enough. To be able to be really test whether that blue color worked, I couldn't do that without looking at other colors.

And it's difficult to say, now I need to have all the other colors all at once and test everything all together. That's not going to happen. I started picking some of the color combinations. We have a lot of messages that's have a dark blue over a light blue and we have lots of light gray backgrounds and blue links over that. So, I started to started to flush out the rest of the colors. And but what this really looks like so, if we move the darkest gray into the gray scale because, really, it's a part of that family. It looks like moving up and down these scales to flush out the different shades so I found myself focusing on these sorts of ranges. Very dark ends of the spectrum when I knew those colors needed to work on a light background, when you want to use colors in the same sort of hew.

And then, sometimes we have places where we we have a big block of color, maybe it's used in a background or an icon and text with it and sometimes you want the text darker but the background a bit lighter. Obviously, grays, and you use GitHub, you might notice there's a lot of grays and so a few more were picked up and tested early on. As well as tests to flush out those colors and test out those colors, I needed to start testing them in the real components and the UI. I picked off really highlyused components. Iconic pieces of the UI, which I'll get to and frequentlyused pages. So, how you use components for buttons. For us, our status labels are really important. For the merge status and things like our alert messages and then for us, things that are perhaps iconic are the contribution graph. I'm not sure how well the difference in color shows up here, but they the top one is before and the bottom one is after updated the colors.

And then, pages like our refill pages are highly visited. I started to test all the colors working together. I noticed that colors were together in the UI. I spent a lot of time making the orange the right orange that was close to the blue and how it was effected by the light gray. It was really interested how those could effect each other. Someone recommended me to that I read Interaction of Color. I was like, okay. I get this now.

One of the mistakes we made if you were on GitHub and following Twitter at the time. Objectively made a mistake, I guess. We made our file icons this saturated blue and when we shipped this, that was the thing that people most commented on. They were like, oh, my god, I can't cope with all this blue. It doesn't seem that bad now, but in contrast to the old design, it really changed things so the area the mass that color takes also influences how it's perceived.

So, I was flushing out testing out individual colors, starting to flush out the family, test things in the UI, test things in individual component isolation and quickly the workflow starts to look a bit crazy. It's not linear at all.

And, together with that, then you start to really need to look deeply about, how do colors look to each other in the pallet? And I think Linh talked about this yesterday in the data talk, touches on this with the Salesforce example with the making sure your pallet works for color deficiency.

So, one of the areas where I really needed to make sure that colors seemed different was between our orange and our red. These are two colors, two hews that can easily start to look like each other and so testing those so that there was enough difference doing colorblind testing, was really important.

And so, making sure those, like those hews were different enough and then testing that with so that the different shades, the darker and lighter variations of that, had to make sure they didn't get too close to each other. Another area people needed to see a difference was between our red and green. That is one of the more difficult colors to work with for color blindness.

Luckily, for us and this is advice, we didn't roll out color to displace this information but it felt important to make these different so I did a lot of testing with the red and green, especially.

So, as well as contrast as the testing for color deficiencies, I really think accessibility is important and this is a quote from a talk I saw in San Francisco last year, I couldn't find the example of the source of the slides. Jennison is a manager at LinkedIn. He said either it's accessible or it's not.

If you have the opportunity to start from scratch, try not to use green. It's really difficult to work with. Or at least it's difficult to work within the brighter ranges.

So, we debated this. We tried some much different darkening, sort of forestry greens. We explored using changing our buttons to blue but we felt this was too many changes to introduce in one go. So at the moment, we're working on edging towards getting things to pass and being fully accessible and so we're just stepping in that direction. Because GitHub's a utility, people really notes these changes. We're working towards it.

This is how colors interact within the same family. It's worth looking at all the different shades in that hue and with white and whatever your dark black and darkest gray and seeing what works. This is the base and default red and so and then, like, with our dark darkest red, making sure that that works with the lightest variations and then works well with white and black. And this helped me start to define system rules. It's good to it helped me, like, have some constraints around this and narrow down the color choices.

So, I started to define roles like in every base color, it must at least pass an aa large and the darkest and lightest colors in a hue must pass for small text.

So, that's something that I found helpful and helped me make decisions about what would GitHub color combinations and what should be part of the new pallet.

So, naming conventions. We can't have a Design Systems or CSS conference and not talk about naming things. So, there's a way to approach this. Figure out what's important for you and some of the things that were important to us was knowing what the name of the color is by name alone. I want to look at that color code and know what it is. I want to be able to quickly internalize color names so when I'm writing colors in code, I can remember the different variations of those colors. And also, we wanted to help aid vocabulary around colors. Hopefully, the naming of these colors helps those conversations.

So, I picked some examples from Etsy and they just as I was leaving, they had started to introduce a range of oranges. I had to poke around the site the other day and see which ones were being used. They have the standard orange, but then they have Cara Cara, Creamsicle. They have Rausch, Babu, Arches, Hof. Looking at other examples and material design has this sort of tons of numbers. And I started to look at how other companies were naming colors in different Design Systems and I started to look at design tools, like photography editing software and what words do people use to describe color? I ended up it's really easy to quickly get confused about is this indigo or blue? We ended up with things like this and quite similar to materials with a lot less colors. But we can't with very simple color names.

And not to say that Etsy and colors don't work but for us, that didn't seem to work right.

I've had a lot of conversations about when it comes to class names in the markup. We have a bunch of things like this. Things like text warning, button danger, flash danger. They're all red. The reason I say that is I've many times, am working code that has those sort of different names instead of using the color. I find myself going, is it button one or button one danger? It's up to what works for you and your team. That's something I worry about sometimes. I think there's places for where it might not be the best idea to name things by color. I think either of these can work, it depends on how your system is used. If you're using button primary, it's part of a theme and that color could change so maybe it couldn't make sense to call it button green. Think about these use cases and what works for you.

So, we're going to get a bit into nerdy as I am right now. So, I think a lot of people want to yeah, write a script and it just generates all these colors and I'm sure that some people are really good at doing that have done some good things. As I was exploring color, I noticed that there weren't I couldn't find, like, a pattern that applied to the whole range of colors. Some colors were the way that saturation worked and was different as you went from the darkest to the lightest variation, whereas with something like grays, the the saturation tended to bend quite differently, like this. And then looking at hue, I've seen some blog posts saying, I'll keep the hue exactly the same. I personally don't agree with that because I think it's more about how it's perceived. How it feels. Does it seem like does it feel like it's in the same color family? And sometimes with colors like orange, that can get they can get kind of muddy, can get more brown as you get darker or red. If you want it to be different than your red color range, then you might need to bend the hue a little bit.

Also, I really like this example, which is from Interaction of Color. I don't know probably can't see the difference on this screen, but you can see the numbers, that's why I put them there. So, in the the first the one, two, three, four example, the mixing of red and black is in equal amounts. What happens is it doesn't look like that, it perceivers differently and three and four blur into each other. Whereas, if you add if you double that and go one, two, four, 8, then the actual perceived gradation seems like it's equal even though it's not technically equal.

And this is an example I don't know how to pronounce this, WeberFechner Law. It is the relationship between actual change and perceived change. I was like, how this looks is not marking to how this is in code so it's difficult. I think what's perceived is hard to calculate, not impossible. Just hard.

There was an example of procedurally generating colors and he recreated the material design orange scale and it's not quite the same, but it's close. Maybe doing something that works for you. There's a site called Palx. This steps through hues in equal amounts around 360 and then uses lumens. Maybe this works for you or maybe use it as a starting point and then adjust.

So, programming and color, not impossible, just difficult. Maybe a lot of this stuff going on.

Okay. So, shipping. How did we do? So, this is the old color can you see the difference on the screen? Probably not much, huh? Of course, we were extending the ranges of those colors. It wasn't just these hues. What we did in the first ship was remove 579 of those hex values, which was 23% of the code base for colors, percentage of the colors updated, which is quite a lot in one ship. I thought it was.

What's interesting though is what was perceived to have changed. And I think this is something that's worth thinking about in Design Systems. If you're working on a scale of GitHub, you don't always have the opportunity to update everything to the new systems in one go. That's not possible. So, it's interesting to figure out how much needs to change to seem new and feel like everything's been updated and that's where it kind of landed for us.

So, how have we done since then? Made a little bit of progress, not as much as I would like. But there's a lot of competing priorities to work on with Design Systems, but we're shipping away again. But really, what did people think of this update? And so, #opinions. Twitter had some opinions. Some people thought this was quite bright. I kind of like this one, because Joe Graph is like, what's the deep with these new GitHub colors? Then he follows up with a tweet saying, it was really helpful. Thanks. I'm like, thanks for that.

(Laughing)

Diana:

This is one of my favorite ones because I was like, hell, yeah, I want it to feel like this when you use GitHub.

(Laughing)

Diana:

What this experience taught me is is, yeah, color is the most is such a relative medium. It's the most relative medium form of art. It's interesting to see what we can control or not. We can control the pallet, we can choose what it is. We can choose the composition, we can't exactly choose what data fills up those pages. But we can kind of control that. But what we can't control is whether someone has color deficiency issues, whether they're looking at GitHub on their phone and light is shining on their screen. Whether they've got not a very new monitor or older computer or different browser. We can't control how people are viewing it and how they're observing it and in what context.

But this is stuff you can test for and it's something I feel like I'd like to test a lot more of. And the other thing is, like, we didn't get everything right. I feel like this is a good v1 of our color system and as many people say, Design Systems are never really done. They should be built for change and that's something you should think about when you're building any parts of the system.

So, I ended up feeling I felt happy. I was like, cool, we introduced a new system. We improved a color contrast in a ton of places. We made color as easy to work with for our designers. We definitely made things look less drab and so I felt good about that. It's baby steps.

So, thank you very much.

(Applause)

Una:

Thank you, Diana. Thanks. Please take a seat. Thank you.

Awesome. So, I'm just going to ask a few questions. Great presentation. I love how detail you went with all the color theory. If somebody wanted to learn more about color theory, do you have any resources?

Diana:

One would be Interaction of Color. I like the online book, Programming Design Systems. He does a great history of color theory and then starts to with each sort of section, he goes into ways you can program with color or any other parts of the system. So, I think that's really good to give you some, like, quick history and then also, like, what's useful to actually learn about and then from now, I found myself on many Wikipedia pages. Also, there's an iPad out for doing the exercises and the interactions book, which is fun.

Una:

Is it a workbook?

Diana:

You slide the colors into you have to pick the you get the experiments going and pull them into the shapes. The way they did these tests was with paper initially and it's sort of mimicking that.

Una:

That sounds really fun.

(Laughing)

Una:

Next question comes from the Twitter world also, I'm wondering this. What tools do you use for testing accessibility?

Diana:

Definitely used Colorable a lot. It's colorable.jacksonblack.com. I'll tweet it or he'll tweet it because he's here.

(Laughing)

Diana:

Spectrum is the current tool I used as a plugin for testing colorblindness and color deficiency. Just using I like color picker because often I want to do quick spotchecks in places. So, I use that a bunch.

Una:

Is that the desktop extension?

Diana:

Yeah. I have been making a list of these, I'll get them online and share them.

Una:

Awesome. Speaking of testing, do you ever ab test the color changes?

Diana:

So we couldn't do that with this because this is actually a lesson in sort of the the expense of not having Design Systems and not having a color system in place. There was really no way that we could easily put all of that stuff behind a feature flag. It was like, it's not impossible, but we decided not to do that because of the timeline we wanted to do this in and the effort it would require. When people think of Design Systems, I think of this example and say, as early as possible because you pay for it later. They have been testing they do regular testing on these sort of signup forms and things like that, which have evolved some of the colors. But not uniquely. I think we'll soon be in a place where we can do that now that we have a system.

Una:

That's good to get those Design Systems up as soon as possible. On that note, like, how do you advocate for updating the color system or including accessibility within your company?

Diana:

I mean, it's 2017. Are we still having this discussion?

Una:

We are, sometimes.

Diana:

Yeah, it's been part of the discussion and we can we could have, but we chose not to do that in every single context because we were trying to find we made sure everything was an improvement and it was a rule to make sure there was no derogation. We did manage to get past it. I think, like, I didn't have to have too much of a deep discussion with that because a lot of people were like, yeah, this isn't great. Right. We feel bad about this. And it affects, you know it affects a lot of the population and everyday use cases, like those moments when you're using it with light shining.

Una:

Just outside.

Diana:

Yeah. Yeah. And then for some companies, there is a monetary value. Some will have requirements about using versions of software, like government and universities. Sometimes there are ways if people don't just want to do it anyway, you can track it.

Una: