Front-end is so much more than building designs

I was unfortunately made aware of this tweet today and it felt like a blast from the past. Y’know what I’m talking about: the old days when you’d get a PSD from a designer and build it. It’s a real simplistic way of looking at front-end development so I thought I’d jot down what I do in that situation, hypothetically in definitely not a sub-tweet fashion.

To be clear, I am very much a designer who happened to get into front-end, so I guess I approach things differently than most. Also, I very rarely build things—let alone design them. These days I spend way more time doing pre-production work and spreadsheets, running my agency.

Still, maybe this will be useful to someone.

Hypothetical scenario: A high-fidelity design is plopped on my desk and I’m asked to build it

First up on this one: I’d straight-up not do this now because a hell of a lot of steps have been missed, but let’s persist with winding the clock back a few years. Let’s also say this is from scratch, greenfield stuff. Not an existing codebase.

Getting started

I’d start by printing out the mockups. You heard me correct: I would print them out.

Then, I’d grab a couple of different colour pens:

• One for landmarks (<main>, <article> etc)
• One for flow markup (headings, paragraphs etc)
• One for layouts: straight-up divs that I’d need to wrap around content
• One for pushback

I’d start with pushback—especially if there’s some show-stoppers in there. This will happen too because if a high fidelity mockup has just been put together without planning and circular communication between developers, designers, project managers and clients/stakeholders then there will be massive oversights.

Examples of pushback could be a complicated interaction that would be simplified with content strategy or content that follows no logical order, but looks nice, visually. Oh, of course, lots of pushback on the small grey text that would undoubtedly be present…

Ok, so let’s say the designer has done another pass now and I think we’ve got something cooking. It’s probably not perfect, but we’re ready to go (with a fresh print-out).

Landmarks

I grab my landmark pen and draw boxes (everything is a box on the web), making sure I get my <header>, <nav>(s), <main> and <footer> down first. Then I break content into <articles> and so-on.

Flow markup

With the main boxes in place, I start annotating the page with flow content. I start with headings: making sure a sensible heading hierarchy is in place. Then I move onto paragraphs, lists and so-on. After this point, we’ve got most of the core markup planned out.

Layouts

Time to get layout on. These days, that’s a solved problem most of the time because of Every Layout, but that doesn’t exist in the past, so I determine where flex can be useful and where grid can be useful. Remember these have had almost full browser support for over half a decade (even longer in flexbox’s case). For this exercise, I again, draw boxes and annotate them.

Time to build

With the plan in place, it’s time to write some gosh-darn semantic HTML. It’s a case of working through the printed plan in the same order I annotated it. By the end of this part, there should be a fully functional webpage that you could deploy right there and then. Progressive enhancement, baby!

Only at this point does any CSS more complicated than basic layout cross my mind. I’ve certainly not considered frameworks, that’s for sure. With a solid foundation of HTML already written, it would be a shame to then pollute that with more right?

Guess what, it’s time to go back to the printer, but this time, I get a pair of scissors out and cut out all the patterns and all the stuff I detect as global CSS. This helps me to organise and structure the CSS that’s about to be written and gives me precious time to actually think about what to name blocks and what to push up as high as possible in the CSS.

Then you know, maybe at this point, I’ve detected that some utility classes will be useful. I’ve also got a plan for what blocks, compositions and exceptions need to be written (but remember CUBE doesn’t exist yet, so let’s say we’re using BEM).

Only at this point do I feel ready to write a single line of CSS.

Going slow is fast

I guess the point I’m making in a way here is that I could never win a “dev race” because it takes me ages to even get to the point of writing code and that’s been the case for a lot of years now. The benefit to being like this though is I get to put out fires before they even start. If I’m racing along trying to write code as fast as possible, I’m gonna start plenty of fires instead. Short-terms gains with lots of long term pain comes from racing through code.

I’ve been doing this web thing a long time and let me tell you, I’ve started a lot of fires in that time. Only by starting those fires have I developed into a more experienced designer and developer who knows the danger signs and importantly, learned the value of working slowly and methodically. The irony is that I’d probably ship something of acceptable quality quicker than someone who is focussed on “dev speed”.

Flinging myself back to the present day and into my role at Set Studio, no high fidelity design is happening before there’s been a shit-load of planning and shaping of the work. A designer certainly wouldn’t fling a high-fidelity design at a developer either, like our hypothetical example.

Those folks are instead, working hand-in-hand with each other right from sketches, to prototypes, to lush high-fidelity output. That way, even more fires get put out before they even start!