How to Build a Website on Paper

I’ve got two reasons for writing this:

1. I worked at a PR firm doing graphic design when I was in college, and my boss gave everyone pads of paper emblazoned with motivational sayings. My notepad reminded me every day that “if you fail to plan, you plan to fail.” I took that advice to heart, and while I had always been a list-maker and organizer I really finessed my skills while managing multiple moving deadlines for important clients. I plan out most things in advance, and planning my site before I even begin to code has served me well as a developer.
2. I slipped on the ice and got a concussion last week. I’ve got a dramatic black eye and several bruises, but the real tender care needs to be directed at my brain. One of the most important things I can do right now is limit the amount of time I spend in front of a screen — which you can imagine is really tough for a web developer. I’ve consciously been doing even more of my planning away from my computer, and it’s made my sites cleaner, better organized, and quicker to code.

Before I took the HackerYou bootcamp, I thought that the entire web development process happened while sitting at a computer. While that’s often (and can be) true, there’s a lot of advance planning that you can (and should) do on paper before you even open your text editor.

N.B. I’m going to write specifically about a website build from a final design, assuming that things like wireframes, content mapping and inventory, and sitemaps have already been done. Even when you’re handed a final design, there’s still a lot that should be tackled on paper.

HTML first

The first thing I do when I get a PDF of a site is to look at the architecture. Where are there section breaks? Are there consistent margins? What chunks of layout are repeated? This helps me break up the page into sections, and each section into <div>s.

I mark up a printout of the PDF with information about things like section identities, background colours and images, and gallery layouts.

The walls of the house need to be built before the house gets decorated. HTML is the structure of the house, and CSS is the decor. By setting up all the walls first (HTML), I can easily figure out where my furniture (CSS) should go.

Determine hierarchy and relationships

What sections and elements should be given the most prominence? What parts of the site are the most important, and how are they going to be treated? What distinguishes main sections from sub-sections? Are there parent/child relationships that seem apparent when looking at design elements (a title and byline that always appear before an article, for example)?

Connecting these relationships together in clusters on paper can help you see where you need to create consistency with fonts, borders, and margins in order to maintain clear distinction between types of content without explicitly calling it out.

Look for patterns

A good designer will reuse elements in order to maintain consistency for the reader and give the page a clean and natural flow.

If you have the same title styles throughout the site, make a note about font, colour, or other identifying characteristics (does it have a border? a text shadow?), and plan to commit that to a particular set of attributes (maybe a variable or a SASS mixin).

Grids, whether official CSS grids or just geometric layouts, often repeat or have duplicate elements. How many of these can you reuse? How many lines of code can you eliminate by noticing repetition?

Become a Tupperware master

My mum always had one cupboard where all the Tupperware was stacked neatly, all nested in families from largest to smallest, and with all the lids lined up ready for service. This cupboard gave me such joy, and was far superior to the other Tupperware cupboard, where all the mismatched containers and lids went, nothing stacked together, and most of the pieces had been used for building sandcastles (sorry, mum).

Start looking at the way you can nest things inside other things before you start to build. Plan what you can group and what should remain independent. Sketch out the outer and inner containers, and how they’ll transform when screen sizes change. Figure out what needs to be wrapped with what other elements and what needs to travel together.

Plan responsive while building desktop

Whether you build mobile or desktop first, you should know where your design is going to end up before it even starts. A simple sketch of how elements will move to become small-screen (or large-screen) friendly will help you visualize the best way to organize elements as you build.

Spending hours creating forms or galleries only to realize that you can’t stack them in proper order when the site is viewed in a different viewport is maddening; save yourself the headache and figure out how things will collapse, expand, and hide at every size.

Building a website and figuring out the proper way to position multiple elements inside containers of variable and constantly-changing size can be tricky, but launching your text editor with a plan already in place will ensure that you’re not planning to fail before you’ve even begun.