Choosing colors depends often on the designer’s taste. This can lead to tough discussions with stakeholders that do not share that taste. Everyone has gut reactions toward colors, but expressing why an element should have a certain color rarely goes beyond that. Because I think discussions about personal taste should not be a big part of design critique, I decided to learn more about color matching rules. After all, when I can explain why certain colors are a good choice, others can react to those reasons. While analyzing color palettes, I quickly found out that I needed a better understanding of what color actually is and how we people perceive it. In this post I will share what I learned so far.

What is color?

Color is a person’s perception of an object’s reflected or emitted light. It depends on its wavelengths, brightness and its environment. Yes: color is in our own individual experiences of what we see. But let’s get into the easy stuff first – the physics – and then deal with that personal perception.

In order to have a precise discussion about color, it helps to have a formalized way of defining colors. The model I find most useful is describing a color’s brightness, hue and saturation. Brightness is the easiest to understand, it defines how much light an object sends to our eye balls. The other two are weirder and more interesting.

How is wavelength related to color?

Hue is the quality of a color that we can describe the easiest with our common labels like red, yellow and violet. Most pure colors have a spot somewhere on the visible spectrum of light:

The visible spectrum of colors. Or actually: a compressed version of it, because no display can really show them all.

Our eyes do not have some sort of nanometer sensors to measure the exact wavelength of a light source. Instead our eyes are sensitive only to three ranges of wavelengths that peak in the wavelengths for red, green and violet:

The normalized sensitivities of the cones on our retinas for violet, green and red:

Chart with the relative sensitivities of retinal cones

Image by Bruce MacEvoy. I recommend spending a few hours reading his excellent page about color perception. Much of this post is just a simple summary of it.

I’m showing the normalized version of the chart above, meaning that the sensitivities for the three cone types are all set at a maximum of 1.0. In reality, our violet/blue-sensitive cones are much less sensitive. However, we have more cones of that type, which levels out the lack of sensitivity a bit. Moreover, our eyes and brain compensate for the differences in sensitivity. It actually does that compensation in an odd way, for instance making cyan look brighter than violet.

What happens if you mix colored light?

Although our retinal cones sensitivities peak at only three wavelengths, they pick up signals beside and between those peaks. Most wavelengths trigger two cone types and the ratio between how much they trigger the two defines where on the spectrum we identify it.

Imagine we point one beam of light that contains green light (meaning it has a wavelength of 500 nm) and one with red light (650 nm) at the same spot. That spot does not reflect light with a wavelength of 550 nm; the light itself is not affected by the mixing. We do however perceive the color that lies between green and red on the spectrum!

Blending green and red makes yellow

Our perception of light with two wavelengths does not equal a straight average of the two.

Can you create all colors with red, green and blue?

So computer displays show images with pixels and each pixel has a three tiny lights: a red one, green one and blue one. But can such an RGB array create all colors? In theory, yes, well, almost. As we discussed, the three cone types cannot discern between a mix of two narrow ranges of wavelengths and a spectral color. So if those narrow bands are aligned with the peak sensitivities of our retinal cones, the cones can be stimulated just like they are by spectral colors between the sensitivities.

The red and green subpixels create everything from red, orange, yellow to green. The green and blue subpixels are for the well, green, cyan and blue hues. Red and blue form purples and magentas.

Why don’t we have RGV displays?

Hey hold on, if our short wavelength cones have peak sensitivity in the violet area, why don’t we use red, green and violet light to display colors rather than red, green and blue?

As shown in the cones sensitivity diagram, our red-sensitive cones have a small peak in the violet area. We see saturated blues when:

  • Short wavelength cones (violet/blue) are triggered
  • The mid range cones (green) also quite a bit
  • The cones for red barely.

So you could mix a blue with violet and green light, but it would not look saturated, because our red-sensitive cones would pick up that color too. With red, green and blue we can accurately describe all hues in between.

Moreover: because of the small sensitivity peak of the long wavelength cones (red) in the short wavelength area (violet), we can mix purples looking just like violet by adding a bit of red to blue. In practice, that is the reason that displays cannot show violet as saturated as we can see it reflected from real objects.

Where are purple and magenta on the spectrum?

Purple and magenta are examples of non-spectral colors; you can only make them by mixing wavelengths. Red and blue, as you know. Now unlike with mixing red and green, we do not perceive a color between those two on the spectrum! By averaging the wavelength, you would imagine you’d get green:

A blue and a red circle overlapping. The overlap is purple.

Combining wavelengths means you get something in between, but it’s not a mathematical average.

Purple looks like violet instead! The reason is that violet light does not only activate our short wavelength cones, but also the long wavelength cones for the reds. Purple also triggers both these types, making our brains interpret them as similar. Magenta is like purple with more red.

Gradient showing red, magenta, purple and violet

Why make a color circle out of a linear spectrum?

Color circles are used a lot in color theory and design software, but why do they exist at all if the spectrum is linear? Because purple and violet are so much alike to us, we can create a smooth gradient between the most opposite colors on the spectrum: violet and red:

Two spectra that overlap in the middle of the image.

In the center I have blended the extremes of the visible spectrum. You see purple and magenta there.

By drawing the spectrum as a circle so that both ends overlap, we get the same effect:

The spectrum bent around a circle. Its ends overlap at the bottom.

Again, this only makes sense because our long wavelength cones are also sensitive to short wavelengths. For creating colors for animals that have different cones sensitivities, this model would not work. In fact, most of our color images do not look anything like their reality.

The color circle contains all perceivable hues. Another neat feature of the color circle is that you can find contrasting colors: they lie on opposite sides of the circle.

Describing colors

Only a hue does not make a color: we need to define the saturation and brightness too, to describe a color completely.

With values for hue, saturation and brightness we can accurately define colors in a way that is close to how we describe colors verbally. Take for instance ‘vivid light blue’. The basic name of a color, ‘blue’, describes the hue. ‘Light’ means high brightness. Vivid means high saturation.

These are the three properties in the Hue/Saturation/Brightness model that is used in a lot of software. It has some issues (I should write about that), but the model is complete, precise and in many ways close to how we perceive color.

What is saturation exactly?

Saturation is the purity of a color. The purer a color, the narrower a light source’s band of of wavelengths it occupies on the spectrum. Spectral colors are the most saturated colors possible and have only a single wave length. The least saturated colors are white and black and all the greys in between. White light is a balanced mix of all the colors that we can perceive: light waves from across the visible spectrum. Or simply by mixing red, green and blue in a clever way. Either way, the mix has to imitate the ratio in which the sun’s light triggers our color sensitive retinal cones.

Knowing how to make the most saturated and least saturated colors, you can create colors with medium saturation by adding white light to a saturated color.

A triangle with a mesh gradient. 100% Saturated at the top, white at the bottom left, black at the bottom right.

This triangle has all possible variants of this blue high. Vertically its saturation is varied. Horizontally its brightness.

Saturated colors only trigger two retinal cone types – their sensitivities overlap, so it’s impossible to trigger only one type. That means we are actually quite bad at assessing color saturation. We cannot see the difference between a spectral yellow and an even blend of several greens and reds, for instance. The only way we can perceive that an object has an unsaturated color (and thus reflects light containing many wavelengths) is when all our three color receptors for red, green and blue are activated by that color. So as long as one of our three cone types is not activated, we process it as if it were a pure, spectral color. The more light the third cone type is picking up additionally, the less saturated we consider the color.


Just by trying to define color we already have to go beyond the physical properties of light. Our retinas process wavelengths in a non-mathematical way, requiring a lot of interpretation. And I did not even get started with what our brains do with the signals they receive from our eyeballs! That’s for the next post.

Follow me on Twitter or Mastodon to get an update as soon as part 2 is ready.









Warning: these posts are pretty old

It’s been too long since I wrote something here. Some posts were so bad that I archived them and I’m quite sure today nobody is interested whether or not designers should code. Nor were they before. I’ll post something now in the next, let’s say month or so. Promise.

Should designers write code?

Should interaction designers write code? Many in our field seem to be occupied with this question. I decided to find out for myself. In this post I’ll share my experiences of the last three years combining design with code. Three years ago I only knew a bit of ActionScript, which – besides in the odd Flash banner – never made it to production. I’m now proficient with HTML, CSS and JQuery. Last year I worked half a year at Apple as a software engineer.

How coding changes the design process

Design without coding

The figure below is a rough interpretation of how designers work as soon as they have picked a problem to solve: ideas are sketched, good ideas are turned into detailed designs that are in the end handed to an engineer in the form of a specification. Regardless of the field (industrial, interaction, graphic design), the specification consists of a technical drawing and a formal description of the features.Design is not a linear process. Solving a problem usually takes several iterations of ideation, sketching and detailing. New ideas pop up and the designer becomes aware of issues that weren’t identified before. At several stages in the process, prototypes of low and high fidelity are made and tested.



Detail design



These used to be my basic tools in the design process. Of course in reality, the process is not this linear.

This process isn’t unique for interaction design. You can just as well replace ‘Development’ with ‘Printing’, ‘Injection molding’, etc. Except for artistic and artisanal designers, engineers and machines take the next steps to turn the detail design into a product.

Design with coding

Nowadays I often skip the step of making detail designs and design specifications, because I deliver (part of) the front-end to the developers in my team.



Detail design

Front-end coding



In projects for which I do front-end development too, pixel mockups aren’t always necessary.

Things I’ve learned as a coding designer

My code may not be great, but it only has to be good.

A programmer with good taste doesn’t make a designer. Just like that, me fancying to write a few lines of JavaScript every now and then, doesn’t make me a computer scientist.

Not all coding is programming though. HTML and CSS only define the appearance of more or less static elements of a web page. They’re just design specifications that are understood by computers. I think therefore it’s only natural for web designers to write HTML and CSS themselves. You don’t need to be a programmer to do that really well.

Interfaces are more than static layouts, so it’s necessary for designers to define how the interface changes based on events, like a user clicking a certain button. When designers start writing code to define how such interactions should be handled, they enter the realm of software development. There, code can output unexpected results and just completely fail to execute. This is where developers may get suspicious about the quality of my work.

I may not write the most efficient JavaScript, but it’s understandable for anyone familiar with that language. Stuff that happens in front-end is usually relatively easy to comprehend, because the results are so visible. Because of that, a short review of my scripts will suffice for a developer to identify potential issues. Except for high profile projects, the efficiency and beauty of code are not likely to be noticed by anyone but those in the development team. It doesn’t matter if the code is well-written or not, as long as it works.

Doesn’t going straight from idea to code compromise design quality?

Quality of code may not have to an issue when designers start coding, but what about the quality of design? Isn’t it a terribly bad idea to just implement first ideas without considering and testing alternatives, like mentioned above?

Generally, I think it’s stupid to go straight from idea to code. A complete design is way too complex to create just in the mind and then execute without the help of sketches and models. There is a scenario where it makes sense though. When parts of a design have been implemented in a front-end, it’s very easy to make changes. What would happen if I’d change the button colors, or if I’d increase the white space? Such questions are easy to answer by changing a few lines of CSS. Changing a pixel mockup takes more time than that. If designers can’t make such changes themselves, a lot of time is spent on creating mockups and communicating changes to a developer. Developers seem not be especially keen on getting such mundane change requests.

So, as long as designers don’t forget they’re designers first and coders second, editing code is a great way to get the details right in an interface.

Better team collaboration

When I didn’t write CSS

Designer: Can you please change the line heights? Developer: Maybe after I've finished some crazy complicated computer things you don't understand, but are very important.

Now I do write CSS

Designer: I have just committed the new CSS. Developer: Thanks.

Once I delivered a visual design as an HTML mockup. The front-end developer who received it was all like “WTF is this shit!?” and wanted Photoshop files as a reference instead. I still don’t know why. No Photoshop file would have shown the animations I had included. Even communicating what parts of a responsive layout are fixed size and what parts scale is awkward in a set of images. Maybe this developer was just a bit territorial about his field of expertise. Totally unnecessary though, he was experienced and there’s no way any designer would replace his job on the projects he worked on.

That incident was an exception, luckily. Not everyone may feel comfortable with a shift of responsibilities, but more overlap in understanding of concepts does make collaboration easier. I think engineers have a natural interest in technical problems, where designers are more interested in user experience. That always leads to discussions about priorities. Knowing how the code of a front-end works, these discussions now go beyond pushing for our own stakes in the project. We identify issues and come up with solutions together. Peace.

Maybe I care a bit too much for engineering issues now

My better understanding of engineering issues comes with a trade-off. When discussing ideas for changes, I’ve caught myself more than once with the developer’s attitude of “No. Then I wrote all that fine code in vain!” That’s bad. As a designer I should be arguing the benefits for the users instead! For this reason, it’d be good to have more than one designer on the team, with one who’s not writing code at all.

I hope being aware of this pitfall helps, but I’m pretty sure it affects me on a subconscious level too, favoring ideas that are easier to build with my limited dev skills.


I think the drawback of having designers code mentioned above is outweighed by their ability to create realistic prototypes. How much time do designers spend creating advanced prototypes with Axure, Fireworks and the like? Isn’t it a waste, if all that work has to be redone to make it work in the actual product? If coding designers can make prototypes more efficiently because part of it can be used in the implementation of the product, more prototypes can be built and tested early in the process. This should reduce the need for expensive changes later on.

I may be a slow coder, but writing a design spec is a total waste of time if you can avoid it.

Compared to specialized front-end developers, I’m rather slow writing code. But being capable to do it, I don’t have to write lengthy documents with specifications anymore. I deliver a front-end instead.

Also, I don’t waste any time creating those so-called pixel-perfect Photoshop files. I just spend less time getting a design from concept to detail design, which used to be a huge chunk of my work.Anyone who believes a pixel perfect psd is essential in the development of a web-based product, better changes their career to embroidery. As long as the big browsers are not capable of displaying web pages consistently, I don’t see the point of have a perfect execution of the design that no user will ever see.

Best of all, I make fewer change requests after assessing a design implementation. That old workflow with dumping a design spec in a developer’s inbox is prone to errors. Even simple web apps contain a few thousands lines of CSS, based on a document with dozens of pages with specs. So even if I’d always write complete (no) and flawless (not likely) specs in one run, the developer may overlook parts or just interpret things differently.

Even if my code were only used by developers to see what the design should look like in the front end, I’ve used the clearest and most efficient way to create a design spec.

Conclusion: learn to code, do what you like

We need specialists in every aspect of design: usability research, ideation, brand experience, you name it. A big organization with a big project may benefit from teams of experts – if it can afford it. In the small to midscale projects with only a few designers and developers, compared to those who stay away from code, coding designers deliver more, collaborate better and create higher quality products. To designers of interactive products, I recommend to get familiar with code at least to the level they feel comfortable discussing technical issues with engineers.

How I design ‘mobile first’

I never found designing websites for mobiles really attractive, compared to designing for big displays. Pretty much any design gets better when you add:

  1. Lots of white space
  2. Contrast in size

Since you don’t have that luxury to apply that on little smart phone displays, what’s the fun in designing for mobile? After designing and building this website the mobile first way, I realized it’s all about creating a good experience for visitors on any device.  It’s more work than it used to be when 1024 x 768 pixels was the standard, but it sure is rewarding to see a design fluently adapt to the size of its window and work perfectly on any device. Doing it mobile first helps to achieve that.

What is mobile first?

Strangely, even in Luke Wroblewski’s Mobile First book I can’t find a definition of the term ‘mobile first’. To me it simply means starting design and development of web content for small devices first and enhancing it for larger screens later. With that come some requirements, but also opportunities that can greatly improve the user experience.

How I do mobile first

Message first

Designing for mobile makes you focus on what’s most important on each page. Forget  slideshows, mouse hover effects and banners. Put the core info on top and make sure it’s visible at least partly when the page is loaded. I’m not talking about reintroducing the fold, but about immediately giving website visitors the feeling they get what they’re looking for.


On a mobile device, each of my project pages shows a larger version of the thumbnail from the project overview. I assume that when people click the thumbnail, they want to see the design up close, so I offer that immediately. From a layout perspective, that’s not really nice, so visitors with a large enough display get that image a bit lower on the page.

Depending on your device, you will see the image before or after the project details.

Depending on your device, you will see the image either before or after the project details.

Basic styling first

You don’t get to make complicated layouts on a small screen, so typography and color play a much more important role than on a large display. On any display size, these two have to be right, because bad typography and an ugly color scheme can’t be compensated by some cool layout. Designing mobile first forces you to get the basic styling right without getting distracted by details and fun features.


One of the first things I did to create a style fitting the requirements for this website, was picking fonts and a color scheme. These were applied in a base stylesheet, working best at a small window size: less than 480 pixels wide. I optimized the character size and column width for readability: ten to twelve words per line. I may have failed to get that right, if I had started with a larger, more complicated layout where more factors have to be considered.

Simplicity first

Continuing on the previous example: yes, I like drawing nice, complicated grid layouts with lots of side bars, widgets and whatnot. But if the message comes across clearer without that stuff on a mobile, why would you need it on a desktop computer? For this website I started with a single column layout for mobile devices. I wrote the CSS and tested it in a narrow browser window on my laptop. When things looked ok, I made my browser window wider to the point where things didn’t look ok anymore. Then, for that window width, I added CSS adjustments for character sizes and margins.


Dragging my browser window wider, at a window width of around 600 pixels, some things started to look off. I noticed that the buttons of the top navigation menu got huge. For mobile, they’re set to  50% window width, which obviously doesn’t make sense for larger displays. I created a break point with a CSS media query at the point where I was sure the labels in the buttons would fit in a single row and set the width of the buttons to 25% there.

Step by step, I repeated this cycle of increasing window width and adding styling. Some text was put in columns, like the details in project descriptions. I found there was no need to add sidebars and widgets at larger window. Had I started sketching layouts for large displays, I may have come up with ideas (side bars, mega menus, etc) that were much more work to implement.

Mobile CSS first

Mobile first makes as much sense for writing code as for the design, because the layouts for large screens tend to be more complicated than the single column designs on a mobile. As mentioned, designing for small devices first and scaling up later, may lead to the realization there’s no need for a complicated grid layout at all. That definitely cuts time writing CSS for it.

That said, creating a fully responsive website takes way more time writing and testing than one that’s optimized for a single, fixed screen size.


My CSS,  based on the Bones WordPress theme, is organized as a base stylesheet, to which styling for larger screens is added progressively with media queries. This is good because:

  1. The CSS for small screens stays light, and gets heavier for larger screens that generally come with computers with more processing power and memory.
  2. The CSS is clean, because the extra styling for big screens  is separated from the base style sheet that is applied to all devices.
  3. It’s intuitive to write. You don’t have to override the complex styling for big displays by applying higher CSS specificity for all attributes that need to be changed.


I’m glad I didn’t discard mobile first to the buzz word pile. The experiences I described above, convinced me that designers, developers and product owners alike can benefit from making the shift to mobile first.

New design pattern: Drag To Tag

Working on a new platform for keeping annotations, I came up with a new way of tagging items! In many applications, tagging is used to make items, such as photos, bookmarks or songs findable. I guess many people like myself find proper tagging tedious at times. It’s an administrative job, something you may skip if you’re not sure if you need it in the future.

Bookmark tagging window in Firefox

When you tag a bookmark in Firefox, you edit/add an item and add keywords by typing them into a text field.

On top of that for many people, typing on a mobile device is rather inconvenient. So why don’t we skip the part of adding a new bookmark and going straight to adding tags, without actually having to type anything? ‘Drag To Tag’ is my idea for a new design pattern to assign tags. Just drag the tag symbol to a word in the text:

New design pattern for tagging words on, say, a web page

Drag the tag to the words that are typical for the webpage to tag them. No typing!

The tags that are visualized in the text could be made resizeable to create tags longer than a single word. Of course we shouldn’t get rid of typing altogether: users may want to add tags that don’t occur in the text after all.

A similar pattern would be selecting a word and clicking/tapping the tag button, which would be especially handy for tags longer than a single word.

Drag To Tag has several benefits over traditional tagging:

  1. No typing required
  2. Fewer user actions required (you can even skip the ‘add bookmark’ action: when a tag is added, a bookmark is created when it doesn’t exist yet for the page)
  3. It’s visual thus less nerdy

Though it looks so simple, I haven’t seen Drag To Tag in any application yet. Are there any drawbacks I’m overlooking, from a design perspective?