Design Without Color First
medium.com
medium.com
Most of my clients (who have marketing but not design backgrounds) want that "wow" factor when they see the first mockups. By easing into the designs I felt like I lost that.
As a designer I realized I wasn't just delivering a JPG, but a design experience. My clients seemed to equally enjoy putting their mark on the design and imaging the same "wow" factor their CEO would feel when they saw the latest iteration.
So, while I love this process for personal projects or for companies familiar with the design process, for the average marketing team I'm still going full color mockups.
When they see some cleanly designed draft printed out (or worse: on the screen), most people cannot see that it is a draft, even if you tell them.
I firmly believe that communicating the right thing in a strategic way to the customer giving them what they need and making them realize that they want it, is what seperates a good designer from a bad one.
Another way than actually drawing is to give them many drafts, so they focus on the differences. This however depends on the job (sometimes multiple drafts are not a thing you can afford time wise).
When I got started in marketing the best designers I had the pleasure of working with educated me as to the different kinds of decisions design needs to make.
The finished product is the amalgamation of many different, distinct, decisions. Those decisions include things like: what is the objective of this page? If there's more than one objective which one is more important? If there are several objectives how do they compare in terms of importance to the end user? How does that contrast with the goals of the business? How do we want the user to feel? What do we want them to think? What action do we want them to take?
Some of these questions require high fidelity design while others do not. The lower fidelity designs typically help answer the strategic questions that the higher fidelity designs will build upon and execute. Using sketches and wireframes facilitates separating these conversations.
If a client is looking for a 'wow' factor with the first mockup then they've confused themself with the end user.
This kind of approach should also apply to good requirements gathering in my opinion.
Yes, a lot of "craft" oriented people don't realize that until they have a few painful experiences with clients. They spend hours and hours poring over every single pixel, and then do not spend anywhere near the same amount of effort on communicating with and presenting to the client.
The article is correct that designing without color at first can be a fine approach, encouraging you to focus on weight, layout, etc. But showing these intermediary, exploratory outputs to the client is just asking for wasted time at best, and trouble at worst.
I understand that focusing on pleasing your client is the easiest way to gain acceptance and possibly business, but if it's at the expense of delivering a product that actually serves your client (which pandering to clients on purely aesthetic grounds very often is), you're effectively selling snake-oil. It may be lucrative, but it's bad design. Doing good design requires managing your clients' expectations and selling them on quality.
Focusing on B&W forces you to work on your composition and be able to produce an interesting, captivating image without letting colors "compensate" for subpar composition by drawing the eye to a brightly colored object or patch. Even if you're mainly interested in color photography and eventually want to focus on properly using colors, starting without them will give you a foundation that you might otherwise never acquire.
Actually, this was because developing color prints is orders of magnitude more difficult than B&W prints. Most of your famous early photographers are known for what they did in the dark room, not for their composition skills. E.g. you can buy an Ansel Adams poster for a few dollars, but an actual Ansel Adams print will run you several thousand.
I haven't seen any material since the digital age took over (sometime around 2000) recommend that photographers start with B&W.
Learning to see and think about the lightness relationships in a picture is a very valuable skill for color photography which is easier to learn when trying to make black and white pictures because there are fewer distractions and fewer choices to make.
> I haven't seen any material since the digital age took over recommend that photographers start with B&W.
I am not super familiar with recent introductory photo courses/books/etc. Have you examined many of those?
While I haven't taken any formal classes in photography, I started learning around 2000 which is about the time digital started taking over. I started with film, then quickly moved to digital. None of the digital materials I used ever recommended starting with B&W. And the more formal classes I've looked at (but not taken) don't appear to start with B&W either. At the very least, they cover a lot of color stuff, where the older film classes only covered B&W, color was considered very advanced.
I honestly think B&W photography is actually harder than color when talking digital. That's because the scene you see has color in it, and it can be tough to imagine what shapes will be dominant when converted to B&W.
When making a full color photograph, it is often (though not always) most effective to get the lightness right first, then worry about hue/chroma afterward.
Sometimes it is helpful to hide the color altogether and look at lightness alone while producing a black and white picture which looks good as a black and white picture, then work on the full color version afterward.
At the same time, I've found that when I circle back to add color to the resulting design, it gets even harder to choose an interesting palette. I get used to seeing it monochromatic and adding vibrant colors looks "wrong" to me, so the end result is often less saturated than I really prefer.
Much of this is probably because I'm just not very skilled at working with color.
https://refactoringui.com/previews/building-your-color-palet...
Following the advice in the article, my current project has six hues, each of which has 9 shades. I really like that diagram of the chat UI that shows all the different colours that were needed.
What it doesn't help with is choosing which grays and accent colors to use. A slightly warm gray? How does that interact with the accent colors? Do the accents shift hue and/or saturation at the different shades? Doing so usually looks better, but then by how much?
This makes as much sense as designing without different font sizes, designing without borders, or designing without rounded corners so everything is rectangular.
Visual design has a vocabulary where everything can be a useful tool for differentiation, but which requires a visual balance between too much uniformity and too much variety.
Arbitrarily removing color as a tool and treating it as an "extra" to be added back in later makes as much sense as writing a program that organizes code and variables into separate files instead of separate classes, and then adds back classes later.
Certainly, sites should still be completely usable by the colorblind, but color is in no way an "extra". It is functional, and treating it merely as ornament instead will lead to a more limited, more likely worse design -- the same as if you limited yourself to a single font size and were unable to draw extra attention to headings over body text, for instance.
And if you want to focus solely on layout? That's what wireframing is for, and you ignore everything else, not just color.
The human eye has three types (“L”, “M”, “S”) of cone cell light detectors, but the raw data from these detectors never makes it to the visual cortex of the brain. The first level of processing inside the eye combines these into an L + M lightness signal and two color difference signals (L – M and L + M – S), which are then further combined into higher-level spatial patterns, etc.
Lightness contrast is most of how the visual system distinguishes motion, shapes, textures, and fine details.
Two bordering shapes without lightness contrast get visually smeared together, text without lightness contrast is illegible, design elements without lightness contrast are largely indistinguishable, etc., even if the colors are otherwise strongly contrasting.
* * *
> makes as much sense as designing without different font sizes, designing without borders, or designing without rounded corners so everything is rectangular
Designing with rectangles only as a first step to iterate quickly seems like a reasonable idea. Your other two suggestions are not analogous.
A better comparison might be getting the melody of a song right before figuring out the lyrics.
A grayscale design with a highly-saturated orange button that is technically the same lightness as the other light gray buttons will stand out immensely and the eye will be immediately drawn to it.
Likewise, a light orange button against a dark blue contrast creates a far stronger separation than a light gray button against a dark gray background, even though the "lightnesses" are still the same.
So I really don't understand how you're trying to argue that color doesn't matter.
If your intense orange button has nearly the same lightness as its intense blue background, it’s going to look like a headache-inducing blob instead of like a button.
> light orange button against a dark blue contrast creates a far stronger separation than a light gray button against a dark gray background
It’s not that much stronger separation, in my experience. Light on dark is much more fundamentally important to the design than orange on blue.
If you made it intense middle orange on intense middle blue, the result would be horrifically bad. But light gray on dark gray is just fine.
If you get the lightness contrast right, you have broad latitude in color choices and you won’t be able to screw things up too badly. You can switch between light yellow on dark red, light blue on dark purple, light orange on dark blue, light gray on dark brown, etc. On the other hand, if you get the lightness contrast wrong, then there’s pretty much no way to fix it with color. Which is why it is helpful to design for lightness first.
That doesn’t mean that you can’t e.g. keep in mind while you are doing your black and white setup work that a particular button is going to get a super zappy red color against a largely neutral slate colored design (or whatever), but even so, you want the lightness relationships to be right. Doing the lightness work separately up front can be helpful for many artists: it will preclude many of the worst design mistakes, and focus attention on making text legible, structurally important shapes stand out from their background, and so on.
The approach is reductionist and aims for solving the right problems first. You can reach for color, typography, etc after you’ve done the legwork to know your design satisfies basic constraints. It’s hard for me to generalize the statement, but learning to design this way (BFA at a well-known fine arts college) had an immediate positive effect on the usability of my apps and readability of print media. I still use the technique today.
It is actually powerful way to work. You start with some concept and create limits around it. You mentioned using one font size - thats wonderful tactic. Often time it is enough or almost enough. Design is about balance and it is much easier to sucessfully balance 5 variables than 50. In fact i doubt anyone can do it. Great designers are just very good at hiding that they made their job easier.
Completely agree. It's a bizarre suggestion, to just arbitrarily drop one of the most important tools. What if traffic lights were designed this way?
They are; reason being: color-blind drivers are out there.
Traffic lights have consistencies which allow drivers not to rely on color. The consistencies aren't global, but hold within major geo-political regions.
For instance, where traffic lights are vertical, it's usually red on top, then yellow, then green. The order isn't perturbed. Moreover, the red light may be larger and brighter.
From the tools used in the article - Squarespace - I imagine this is how best to make 'div soup' rather than premium content that has excellent document structure and accessibility built in as a consequence.
If you get document structure right by starting content first and making sure that a story is told (even if it is just a product page) then you can then go from there to the final visual design relatively easily. If you want to change the thing wholesale for different colours then you can. But you have to be working with CSS Grid and CSS variables instead of 'div soup' with trillions of classes to be able to take this more modern content first design approach.
If working content first then you can work on the visuals as you go. For instance you might find that the captions are not always working with images on all device types due to there being too much text. Then you can work on your content to maybe put the captions into a 'details/summary' element that solves that design problem elegantly whilst also improving the document structure. Also, because you are working with real content with real images you can find out what colours work. Because you are merely using CSS variables you can also see what happens when you change the --background-color to Papaya Whip to see if that helps more than the monochrome you started with.
At some time some people in this industry have to get off the div soup and the big up front designs that have to be cast in stone and handed over to developers to 'paint by numbers'.
Because then you'll most likely already have color palettes that work on a general level, and different component archetypes that are easily adjustable for any brand.
I mean, why not bake your taste and experience into your own design system that you then use for other project specific design systems as a starting point?
Then again - it might have been because I was unfamiliar with frontend coding, or that we didn't really go past the wireframes stage.
Clients are typically not designers, and when you show them anything visual, they will see and judge it as a design standing on its own, and not as an intermediary part of your process.
Anything that is seen by the client is a deliverable and should receive the utmost amount of polish and attention. As a designer/engineer/someone who makes things, you may be able to mentally fill in the blanks or visualize what the finished product might look like based on wireframes, diagrams, etc. Your client cannot, and showing them non deliverables will only muddy the conversation.
Just to make it clear - I am not advocating working in obscurity for months, not giving the clients anything, and then giving them the finished product on a silver platter - this is just as bad. You should absolutely be delivering regularly, getting feedback from the client on the deliverables, and iterating that way. But everything that you give the client is something that stands on its own, not a wireframe that you introduce by awkwardly saying "well, we didn't have time to add color, but just imagine...".
There’s nothing awkward about not using color. It’s smart and makes you focus on the right stuff in most of the design process. That’s something any reasonable client will understand perfectly well.
The fact that everything is rendered as a low fidelity mock really helps avoid discussions like "move this 2 pixels to the left" or "maybe this blue should be more towards green". The exceptions are set in wireframe and when we have a working version is a nice surprise.
Just different stages of _the process_ or _development_.