Web-Design for engineers
Insights from building Le Wagon’s design curriculum
By Boris Paillard, CEO at Le Wagon
I suffer from two serious handicaps when it comes to teaching web-design:
- First, I’m French. I live in a country where the word “design” literally stands for “graphic design”.
- Second, I’m an engineer. French engineering schools are great for sure, but they also despise topics like Design & Web-development. Too hands-on, too dirty…
When launching Le Wagon, a coding school for entrepreneurs, I had to find the right way to teach web-design without throwing away my great yet heavy background. Here is what I discovered.
“Web-design is more engineering than art”
It must respect patterns & conventions, such as programming. Nothing new for designers here. But for me that was a big discovery. Here are the main insights I’ve gathered for the last two years.
Thinking in terms of components
When building a website, beginners tend to start their design all over again for every new page of their app.
- Ok, let’s design the home page
- Now I need to design the login page
- Now the user profile
- And now the main dashboard
- And so on…
It’s a very inefficient way of working, you repeat yourself all the time. One big motto of coders is called DRY (Don’t Repeat Yourself). Designing a website one page after the other is the exact opposite of DRY. Other side effect, when you start a new project, you’re screwed, no way to re-use your page-specific design.
So what’s the good practice then? Well, good developers think about their design in terms of graphical components, elementary blocks that you combine to build your pages. I’m sure you have heard of such components: buttons, forms, navbars, tabs, avatars, dropdown lists, etc... You see them every day. Designing your app component by component is terribly efficient. You build yourself a library that you keep improving and fine-tuning. Cherry on the cake, when you start a new project, you just pick the components you need. BIM BAM BOUM, that’s it! That’s the most valuable secret of web-designers and resources like CallToIdea give you lots of examples of web components.
This “components mindset” is key. Still, you have to pick the right names for your components.
Well-designed naming conventions
Let me tell you a typical conversation I have with students when teaching them CSS (the language used to design web pages):
Me: Which name do you prefer, “button-red” or “button-signup”?
Student: I’d say “button-signup” because then everyone knows it’s for signup :)
Me: Ok, so let’s imagine I give you a component called “button-signup”, can you guess if it’s green, blue, big, small, rounded, or bordered?
Student: Hmm.. well, no I can’t
Me: And what if I give you a component called “button-red”
Student: Sure, it’s red.
Developers take a great deal of care when naming things. Designers should do the same. Any component should “graphically speak for itself”. Picking the right name is a part of design. A right name is a well-designed name, which means that other developers will use the component more easily.
Well-designed names for well-designed components.
Design is about structure
Good Front-end developers will all tell you the same story. If your page structure is weak (technically, structure means your HTML), then you can’t expect to design it the right way.
Such as a painter can’t paint a building without the proper scaffold.
Not art — just rules of thumb
I often hear engineers telling me “they are not good at web-design” because “they are not artists”. Of course, if you work in a fancy web agency making fancy websites, you need some kind of artistic sensitivity. But working on a functional web-app like Airbnb, Facebook, Product Hunt, Instacart [you name it] has nothing to do with art, it’s about respecting patterns and simple graphical rules, and mainly stealing others’ work.
“Good Artists Copy, Great Artists Steal” — Picasso
Here are my personal rules of thumb, known for ages by designers I guess (I’ve never read any design book really..)..
Don’t play fancy with colours
If you’re not born a designer, just use the gray scale and bring colour with small touches. That’s exactly what Medium does, using mostly gray values and a nice flashy green in very light touch.
Space matters as much as objects
The space that surrounds an object (text, image, etc..) is as important as the object itself. It creates boundaries and helps identify the different zones on the screen.
Beginners often start their design by using very big headers taking half of the screen, leaving no space for the rest. As their app does not have much content at the beginning, they are afraid of this empty space and try to fill it with big headers. Now imagine Facebook with a big “Latest Posts” title taking half the screen on your feed. That would be ridiculous :)
Our eyes need contrast
We can’t differentiate between contents without contrast. If everything look the same, then we don’t know where to look. We need graphical guidance. Here is an obvious example of contrast between a main title and a secondary one.
“Same size” is not “same proportion”
It’s not because images have the same width and height in terms of pixels that they have harmonious proportions.
Backgrounds need filters
When images are too contrasted, you need to put a filter on top of them to make your texts readable. Very obvious I know, but I guess pedagogy is about repeating simple things :)
Less is more
A clean design is the one you don’t notice at first sight.
Separation of concerns
In computer, separation of concerns (SoC) is a design principle for separating a computer into distinct sections, such that each section addresses a separate concern. — Wikipedia
SoC also applies very well to design. Let’s imagine you want to make an image rounded with a red border. For that you can write this “design task” and give it a name, like:
- Rounded-with-red-border: border is red + corners are rounded
But you can also separate those two tasks under two different names:
- Rounded: corners are rounded
- Red-bordered: border is red
The second option is much better since you separate elementary design tasks. Then you can either combine them or use them independently. Separation of concerns is not just for software and backend. It also applies very well to design.
The end
I hope this article will offer interesting and useful insights to engineers who think they’re not designers or designers who want to structure their approach. I would be very glad to hear your thoughts on design & engineering.
If you are interested in code, tech and entrepreneurship, we often write articles on our Medium account. And to know more about our 9-week program, check the curriculum out.
