Hacker News new | comments | ask | show | jobs | submit login
Design Without Color First (medium.com)
105 points by febin 4 days ago | hide | past | web | favorite | 40 comments

The points all make sense, but anytime I've tried to show clients anything less than a high fidelity mock-up (wireframes, design palette, b/w mockups, etc.), I've been meet with something been indifference and guarded acceptance.

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.

Designer myself. It very often helps to visually communicate this as a draft. That means: show them a drawing, or a nice rendering with Copic markers – even if you designed on the computer.

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).

>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.

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.

That was indeed brilliantly put. I'm saving this. So many questions get answered if you explain this right at the very beginning of the design process.

This kind of approach should also apply to good requirements gathering in my opinion.

> As a designer I realized I wasn't just delivering a JPG, but a design experience.

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.

It depends on whether you're designing for your clients, or for your clients' customers. It sounds like you're doing the latter.

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.

Setting correct expectations is a generally hard problem. As a designer myself, I try to outline the whole process with my clients before work begins and I emphasize “wireframes” vs “mockups.” It’s worked for me so far, but YMMV.

This sounds similar to the advice often given to budding photographers back in the day -- learn the ropes on black and white film, and only then move into color.

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.

"learn the ropes on black and white film, and only then move into color"

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.

I would still recommend that people start with black and white pictures, or at least spend some serious time on it sometime early in studying to make photographs. Darkroom skills per se have little to do with it. I would also recommend that aspiring painters spend some time making black and white photos, charcoal drawings, or the like.

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?

Yes, all of your more traditional mediums will start with black and white for the same reason that color is vastly more complex. No one should start to paint in color until they've got a good foundation on just getting shapes correct.

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.

Not only this, but:

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.

I've done this several times with my own design because otherwise I tend to get lost tweaking colors for hours. It's been a good technique to get me unblocked and moving forward.

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.

That's exactly the approach I started using, after reading that article a couple of months ago, and it's made everything so much easier. There's no more constant tweaking of colours once I have the main palette set, and colours are much more consistent. Before this, I never realised how many colours I actually need.

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.

Yeah, that's effectively the approach I've long taken, though I prefer fewer shades of the accent colors.

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?

I would add that this approach would also help you design interfaces that are more friendly for colorblind users.

Sorry but I completely disagree.

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.

Removing color is not arbitrary. It is based on the physical features of human color vision.

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 light gray button somewhere among other light gray buttons has zero emphasis whatsoever.

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.

Nobody says color doesn’t matter, or that final designs should not use color.

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 advice is sound, IMO. Fine arts teach in this way and it’s an accepted best practice.

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.

Although i agree that bringing color as afterthought is bad advice... i disagree about the limiting.

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.

> 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

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?

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.

Yes thank you, I'm aware of how traffic lights work. They don't rely exclusively on color—clearly a different design philosophy from the advice of this article, which is to not use color at all for functional purposes.

From an accessibility standpoint, a design needs to work well in black and white / without color. Color shouldn't be functional in the sense that people need it to use a design easily and safely.

I used to do this a lot when I worked at a design firm and the branding/color hadn't been defined. It did help quite a lot at times. But for some clients it caused annoyance/confusion at first.

This is still visual design instead of content driven design. Design is how it works, not what it is supposed to look like when the content has been added after the project has been handed over.

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'.

Do you start from scratch, or with your own boilerplate that you have developed over time as a designer?

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?

To play the devil's advocate: I've been given rough wireframes without color before, where we didn't have enough time to add color later on. The feedback from customer was that the design looked unfriendly and out of touch with the rest of the product.

Then again - it might have been because I was unfamiliar with frontend coding, or that we didn't really go past the wireframes stage.

Wireframes are not deliverables! Your client has no more business seeing them than they have seeing the random diagrams/pseudocode your programmers are whiteboarding as they build out the infrastructure of the product.

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...".

You can’t exactly have it both ways, though? Either you involve the client and the client’s clients in iterations, which means they must occasionally see nasty, inconsistent, less than half-finished sketches, or you waste most of their money making the wrong concepts look nice.

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.

When just starting out with website development, I designed without color. It proved effective because I did not have to worry about fiddling with colors. However, I don't design without colors for the simple reason that I can easily incorporate colors into my design without thinking. I use a color scheme called open-color for all my projects. If I'm using sass, for example, I just refer to the color $oc-blue-2 for a light shade of blue. I feel designing with basic colors before putting in actual color values is much better.

I have being doing this for a while using Balsamiq Mockups 3.

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.

This is realistic within a an internal team of designers. It doesn't seem to fly with clients and non-sophisticated internal shareholders.

Agree. I've faced the same issue with clients before. But you can still make very attractive mockups in grayscale to impress.

Designing without color is textbook if you've taken a course in it.

Structure is just as important as _design_ or _style_.

Just different stages of _the process_ or _development_.

In the zeros I wasted hours with discussions about colors, in the 10s hours with discussion about fonts.....

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact