Hacker News new | past | comments | ask | show | jobs | submit login
A Web Design Crash Course: From Developer to Developer (zen-of-programming.com)
224 points by aspit on Aug 21, 2018 | hide | past | web | favorite | 47 comments

I have a question about web design from a complete idiot: how do you do it? I mean, really, from scratch, how is it done?

I have heard that people used to design in a graphics program (Photoshop, Gimp) what the website should look like and then tried to translate that to CSS, html, and js, or maybe just to React these days. Is that how it's done?

Right now when I want something to look a particular way, I go into a CSS file, guess at what a good value might be for a colour or a size or a font, reload the page in the browser, see how it looks, and iterate a few times. Sometimes I use the web browser's webdev tools to try to see the changes in these numbers a bit more live.

What is it that people actually do? How do you even begin to do something as crazy as CSS painting?


I would love to see an intro to web design that starts like those intros to programming that begin with, this is how you install a text editor, this is how you use git, a programming language has variables and functions, and so forth, e.g.


How I do it:

0) Start with the content. Always design around the content and the target audience in mind

1) Starting on pen and paper, I sketch 5-10 layouts in a short amount if time then I try to evaluate them based on gut feelings. This is also a good time to experiment with alternatives, new ideas. Google "webdesign patterns" if you need solutions for a given problem

2) Sketch a black and white HTML+CSS version then try to add the appropriate paddings and margins.

3) I look for inspirations in web design galleries, pinterest, dribble, whatever I can find.

4) Pick a good font for display + text, good typography is key

5) Try to make something that approaches the websites you like, grab a color palette from http://coolors.co, images from https://unsplash.com

6) Iterate

This list is incredibly leaky, but more or less this is the process if I have to design something from scratch.

> Starting on pen and paper

This is really the secret. Pencil, pen, whiteboard, crayon, whatever. Anything that lets you rattle off half a dozen super low detail sketches in under a minute will work. It doesn't need to be pretty either. Just as long as it's enough to give you a feel for interacting with the page as a whole.

Once you have a good solid idea for how you ultimately want it to come together then you can move to a computer to drill down into the individual details, but for getting from zero to concept there's no substitute for analog tools.

This really sums up on how I design a website from scratch. I get more details when I get to do it by just sketching. Web design is also like an art, you have to draw it first. Plus, you get even more chance of artistic view out of it, in your own way. Then go out and browse some web inspiration about your decided niche this sure saves a lot of time.

Any recommendation of picking a good font for display? System fonts won't be sufficient you think? I guess there's not enough font-weights with system fonts

I highly recommend checking out this recent article from a list apart: https://alistapart.com/article/flexible-typesetting

As well as this continually-updated website: https://betterwebtype.com/web-typography-resources

Both give good high-level overviews of readability in digital typesetting and help with choosing the right fonts for the job

> System fonts won't be sufficient you think?

They are great and battle tested of course, but a good font is something that makes a good design stand out. I feel it's a 'hidden' component that many people can't articulate that they like it in a design. It totally depends on the project though :)

more on this: https://practicaltypography.com/system-fonts.html

The Typewolf blog is great:




sans-serif, serif and monospace are great! The actual default fonts for the platform will be selected when you use these. And these are pretty good usually and will match the user's chioce and what the user is most accustomed to seeing, which helps readability.

I run a little design agency (www.beaver.digital) where I do all the design and coding. I didn't study design (or coding for that matter), but over the last year or two I went from novice to advanced pretty quick.

I don't know what the precise rules of thumb are, but I usually start by creating the layout + content in illustrator, which would be akin to making any other type of art. Once you have the illustrator file, writing the code is actually the easy part. It's taxing, but the creative work involved in creating the actual illustrator file is always much more difficult (at least for me).

To your point, I've thought about sharing the actual process in more detail if people expressed interest. I've had a few friends and family members ask, but maybe I'll drum up some lessons someday if I'm convinced anyone might watch them :)

I know this is 5 days late and a dollar short, but I'd absolutely watch lessons following this process.

> Right now when I want something to look a particular way, I go into a CSS file, guess...

This is what I used to do, before I started really getting into web design. Then I discovered Sketch, which really changed the way I think about it.

When you design with CSS, you're also constantly struggling with responsiveness, HTML structure, and a bunch of little things that are sort of irrelevant to how it looks.

Sketch (and similar apps) let you focus just on the look, which is great. Need a div with a background color? Stick a rect right there. It really helped me get into the flow of "designing" instead of "building".

(Also, this design blog really helped me get started, coming from a web developer's perspective: http://learnui.design/blog/)

The problem with this approach is that you get nice screenshots that look great, but the implementation doesn't always match up. Sometimes that last 5-10% of the design that was so easy in Sketch is a complete pain to implement correctly, and it gets skipped. You end up with a half-baked implementation that doesn't look quite right.

That's fair, but if you're also a developer I think it's pretty easy to keep a "how hard would this be to implement?" in the back of your head. And of course, design/development is a process.

I'd argue that getting most of those development details mostly out of your head is well worth the creative freedom it affords.

One way I've sped up my work with Sketch has been the Zeplin plugin [0], which auto-generates CSS stylings for a page designed in Sketch. In my experience, getting a Sketch file from a designer and using Zeplin makes it very easy to translate into proper CSS.

[0]: https://zeplin.io/

Wireframe/design -> HTML + content.

That is the start.

When I worked at a startup, I was able to outsource ALL of our CSS work, as long as I gave them well-structured HTML.

I saw the look our designer wanted, broke it down into pieces that I could define in HTML and then made that.

I knew what CSS could do, was able to tweak their stuff, and could do it given enough time, but the lesson here is that it all starts with your structured document.

How does one go from photoshop to bootstrap aside from manually copying over ideas. 15 years ago we were slicing into 9 piece boxes and changing the side panels to the background image and setting to 100% height repeating the image. The trick was always to slice with this in mind.

A lot of designers are now using tools like Sketch which help with this process, providing exportable CSS for various elements.

You need to know a good deal of CSS rules to make that painting. Best to memorize these. Its like asking a fresh art student to make a style on par with piccaso or van gogh. You need to know a few art rules (rule of thirds, vanishing points, color theory, etc). Every website has its own unique art style and its own set of rules. Learn them before breaking them

In general, build a frontend template looks like this

1) pen + paper low fidelity markup. Also called "Wireframing". Your just making boxes inside boxes, and highlighting the relationships those boxes have with each other. Usually its some idea in your head and inspiration drawn from multiple sources.

2) [Optional] High fidelity markup in Figma / Sketch / Photoshop/ Gimp / AfterEffects Etc. This is where you can identify color schemas that work, font sizes and typography, and fine tune the final version of the end result

3) Inspiration from an idea elsewhere normally (dribble, existing site, a infographic printed catalog, etc). You can skip steps 1 and 2 if this applies.

4) You should have an idea of how all the major HTML and CSS components will work. What CSS properties you will msotly use (rotate, position absolute), etc. You have an idea on the big picture and how everything fits together. You choose between making things in pure HTML/CSS vs loading it as a image/SVG instead. Doing the latter option is almost always easier.

5) JS first or HTML first approach. JS first approach would utilize something like react, that's only if you are working complex UI interfaces that deals with alot of data binding (the example you linked doesn't qualify). You would best be taking an HTML approach first in this instance, e.g. write the HTML, write CSS, reiterate until done.

I highly recommend checking out layout land once you have a good fundamental understanding of basic CSS/JS/HTML. It teaches you "how" to think like a webdesigner, choosing between different CSS rules etc. The author is the head designer at mozilla


For more crazy mathmatical designs, you would need to learn SASS (precompiled CSS) as well generally, and some mathmatical principles (high school geometry is a must, etc). The best source to find these designs is in codepen/dribbble. For very advanced design CSS tutorials, I really enjoy watching @DavidKpiano and @shshaw for these.


Here's a nice ebook which will give you a feeling for what professional designers actually do. There are also links to sites for inspiration. This will give you a feel, for what is actually possible (crazy stuff out there).


Btw. if you want to trial&error your css theres this amazing online tool called jsfiddle. Theres a section for html css and javascript. If you do not need the javascript, just leave it empty.

Here's a simple example: https://jsfiddle.net/frq75sud/5/

Just edit the css and press ctrl+enter.

As an actual person employed as a designer and developer, I find articles listing arbitrary design rules very strange indeed. This is like someone enforcing you to use a coding style before you've even learnt the basics of programming.

All these rules will do is ensure you create a website that looks mostly like one designed by the person who has written the article. If you want to create a landing page for genericstarup.io, then maybe that's fine, but it's kind of like building a website by exclusively copy pasting tutorial snippets that you don't understand.

I also disagree quite strongly with the rules laid out in this particular article, but that's another issue...

As a back end developer that’s been slowly getting into web development, I find the article helpful because it informs me of some design decisions I should be thinking about. By no means do I expect the author’s opinion to always be correct, especially since the design should always be driven by the content and intended audience. But it helps to know I should think about serif vs sans serif, etc. and how it may impact the final product.

As someone with no design background whatsoever, what rules do you disagree with and why?

I've totally mixed the order (in a rush, about to leave the office) but for example...

> Sans-serif fonts are used for body text

Serifs are most commonly used for body (perhaps this is a mistake on the authors part?), but all manner of typefaces can be used for body text dependent on their design and legibility.

> The line-height is 1.5-2.0

I've been building websites, designing books and drawing type for a number of years. I've never used leading/line-height that large.

> body text isn't pure black on white

This is a huge myth imo.

> (backgrounds) Use a pattern or simple image

99% of the time use neither.

> A text shadow is used to make headings readable

I'd recommend this as a last resort generally, adjust the background first.

> Blocks of text are un-justified

Justified text can be fine in many circumstances.

> body text is 16-18px and is scalable

Totally dependent on the design of the rest of the page.

> There's padding between paragraphs

From a pure CSS standpoint, this should really be margins, not padding.

Sans serif fonts are more used on body fonts, because they're more legible on screens. On paper, it's the opposite. Text size plays an important part here, because the serifs in serif fonts makes the letters stand out better on a smaller font size and the serifs "guide" you to the next words, making the paragraphs flow better together.

With HD screens and proper font rendering, sans serif fonts are generally faster and easier to read. These are just some of my observations when doing A/B testing on a few products of ours and there's definitely also a cultural effect at play here. But the poster above isn't definitely in the wrong.

That's strange to hear, in my experience serif fonts are most definitely used more for body text (referring to paragraphs of text) on sites where legibility is a primary concern. Look at the websites of almost any well designed news outlet (Bloomberg, NYT, Guardian, Reuters, etc). I say this as someone who previously worked for a type foundry that has worked with major organisations on corporate type projects and now works as a web (and occasional book) designer/developer.

> Look at the websites of almost any well designed news outlet

Is it possible that some of this is news-site-specific, due to their heritage as print media, and an online design aesthetic that references (or harkens back to) that?

Yes definitely, this is what I understood by the cultural effect httpsterio was referring to. I still stand by my statement though, I've had far too many meetings discussing this exact topic.

>padding between

I feel like this is a pretty terrible basic mistake to make in a web design article... Thinking of padding as something _between_ elements, as opposed to the space between an element's content and it's border seems like a really basic design 101 mistake.

I think that we still need some explaining to do when it comes to developer friendly website design.

Truth is that, right now, in 2018, we can get rid of the hacks, libraries, polyfills and everything else needed to support old browsers. The old 'block layout' methods need to be forgotten and the new CSS grid method can be adopted by new developer/designers. Then this CSS grid needs to be specified with CSS variables for all the bits that change. Then media queries and vanilla javascript can be used to adapt to viewports and cater for interaction. There is not much too it unless you are writing a replacement for Excel in javascript for the web. But then you are writing an application and not designing a website of content.

Then there is the truth about design. A lot of 'design' has been artistic flourish that does not need to be there. We kind of know where the search box goes and what icon it has, there is no need for that to be 'designed' by someone that can't code. This is particularly the case when the 'design' places the search box in the footer with an eyeglasses icon just because the 'designer' thought that they could add their artistic flourish in such a way. (This did happen circa 2010).

The convention based UX that has won out over 'artistic flourishes' means that there is less to 'design'. Choosing fonts and colours is also a bit of a luxury, an existing brand will already have these things. If you were designing for Ford you have a good idea of what colour blue the headings and buttons will be coloured. Equally, if you are creating a site for just yourself then you can experiment with these things as you build out the content.

Anyway, this 'web design crash course' hinted at some of the CSS goodness we have today, e.g. the use of CSS variables, but I am wanting more, a wholesale forgetting of the hacks and cruft with a simple way to do stuff effectively and in a maintainable way with the new CSS shiny.

> Truth is that, right now, in 2018, we can get rid of the hacks, libraries, polyfills and everything else needed to support old browsers

Oh how I wish that was true

The way I have dealt with this issue for the past decade+ is to simply offer multiple tiered pricing for my clients.

By default, the lowest price is design that supports the most modern browsers. The older and more problematic the browser support required, the more it adds to the project cost.

This cuts out 99% of all the old browser support issues in my business. Very rarely does someone need more than "just ok" support for even IE 11 these days. And that isn't so bad even with css grid/flexbox.

Supporting old browsers isn't a technical problem, it's a time/cost problem.

Yeah, it just depends on your audience. It's still a problem in B2B situations. Most notably when a customer's IT is contracted. Unfortunately for me it's not a matter of price tiering, it's about producing a product that has been working for customers in outdated browsers that continue to expect it to work that have signed annual+ contracts.

Negotiations and communication can help resolve these kinds of problems. (in my experience)

The core motivator to start the discussion can be simply profit margin. I've hit points where it's not profitable, and therefore gets cut from our offerings. But if someone wants to pay extra, we can accommodate.

Is it possible that by changing the requirements/costs of the product you would lose the account/business?

The way I started this discussion is with the phrase "web standards", and these are cheaper to build towards. So "non-standard" systems cost extra to support now. But this also meant I could lower my costs on some other work, so it wasn't smoke and mirrors, it was legitimately easier and less time consuming. (also, makes everyone happier to work on standards instead of spending most of our time with hacks and debugging because reasons)

Great question. As with all this stuff it takes time. As I know that I can't cover this fully in a post I'd just like to suggest a couple tools to aid you in this process. For a design application, use Figma. LevelUpTuts has a great series on learning Figma. Then use CodePen as a scratch pad for the css/html programming part. You can even copy and hack other people's code to learn how they do it. I'd strongly suggest watching CSSGrid.io for learning css layout. CSS is a mix between layout and style.

My biggest advice is to start by trying to code stuff that other's have already designed. I would recommend going to dribbble.com and searching for "websites" or "ui." This will give you a ton of designs that you can challenge yourself to make. Thus, the design work is done, you just need to practice the coding part. As a result, you will learn what looks good and how to make it. For example, try to make this with html and css.

https://dribbble.com/shots/2982612-About-Eisley https://dribbble.com/shots/4566630-Article-preview https://dribbble.com/shots/3585571-Creative-Design-Agency-We...

Good luck!

This is just my opinion but I find sans-serif harder to read for long pieces as opposed to serif. Lots of mix of fonts on this page. I have to run most of sites through outline.com to normalize readability.

Of all the MF websites my favorite is this one: http://bettermotherfuckingwebsite.com. It's got good readability like Ali alluded to while loading very fast. Very few colors so that you can focus on what matters most. I feel that unless changing fonts, colors, and sizes adds something legitimate to a user's understanding of the content, skip it.

> Black text on a white background can cause eye strain because of too much contrast. I use dark greys for my content. Then, there is still a lot of contrast, but not as much as there would be with black text.

Is there such thing as having too much contrast, in the context of text relative to its background color? I still feel that this blog's text needs more contrast, not less. Perhaps it's only me, but the gray text used here is not contrasty enough for my eyes, at least on my monitor, and I find myself straining to read.

My favorite blog design is https://paulstamatiou.com/. It has just the right balance in contrast, and the text's spacing is perfect. I can read comfortably. I wish I could explain how it is more readable, but it just feels right.

EDIT: It's probably just my personal preference. I do notice #333333 (gray) is probably the lightest gray that's acceptable for me. The blog is using #4a4a4a, which feels a little too light. Also, I find HN to be very readable (which uses absolute black text), and I'd rather have a black text with light background than a gray text on a white background.

It's an interaction between user preferences, equipment, configuration, and environment, and we don't really have the information to cut through all that.

An HDR monitor displaying ~1000 nits on black in the dark room is great for film, but no-one would want to read text like that. On the other end of the scale, if you're out in the sun, trying to eek out as much time out of your iPhone as possible, you've probably set the brightness so that you can deal with black on white, but reducing it further would be unwanted.

You can't know what your users are actually seeing, and even if you could, there's a layer of personal opinion on top of all that.

IMO, the only reasonable assumption you can make is that most people have their devices set up so that they're happy with the OS itself -- and every mainstream OS [but especially iOS] uses a ton of #000 on #FFF.

> Also, I find HN to be very readable (which uses absolute black text)

On a background that is not absolute white. It's a matter of contrast, not black vs gray text specifically.

> White has 100% color brightness and black has 0% color brightness.

There's no 100% black. People should stop with this nonsense. My monitor's black is pretty greyish by default. It gives nice illusion of blackness because it's also very bright with the whites, so contrast is high, but try comparing a black screen and turned off monitor screen. It's grey as hell. There's no standard screen. If people's eyes are offended by high contrast, they have a contrast knob on their monitor or video card.

I really don't appretiate all those designers' concern for my eyes. It's really not called for. If I want less contrast I can move the virtual knobs on my monitor, and I'll get it set globally. Now the concerned designers just caused a double decrease in contrast on their websites compared to normal readable websites wich use #000 for body text, which is now much harder to correct compared to moving a stupid knob.


Just read it yesterday. Can recommend his other stuff too.

How come the title of the submission doesn't match the title of the post, is that intentional?

Title of the actual linked article is 'A Web Design Crash Course: From one non-designer to another' which makes a lot more sense to me.

The link has changed. This is the correct URL.


Does not exists.

Here's a crosspost if the original isn't working! https://dev.to/aspittel/a-web-design-crash-course-from-one-n...

Yep 404 to me too. Slashdotted perhaps?

Applications are open for YC Winter 2020

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