6 Tips for Wireframing before Coding

What to do before jumping into a PSD to HTML conversion

First of all, what is a wireframe? According to Wikipedia, a wireframe is

a visual guide that represents the skeletal framework of a website. Wireframes are created for the purpose of arranging elements to best accomplish a particular purpose. The wireframe depicts the page layout or arrangement of the website’s content, including interface elements and navigational systems, and how they work together. The wireframe usually lacks typographic style, color, or graphics, since the main focus lies in functionality, behavior, and priority of content. In other words, it focuses on what a screen does, not what it looks like.

Even projects that seem obviously simple need a wireframe first. You never know what issues might crop up later, and a wireframe helps you identify these problem areas before you begin writing code. It’s way easier to ask a designer questions and finesse your plan when you’re working with scribbles on a piece of paper instead of thousands of lines of code in Sublime Text.

Our instructors at HackerYou suggested doing this before jumping into our first project, and while what they said made sense, I only kind of followed that instruction, because it just didn’t seem that necessary. (It was kind of like when your Grade 8 teacher made you submit your outline with your essay and you wrote the outline after you finished the essay.) As they say…hindsight is 20/20.

That being said, here are a few key steps to make while wireframing as a web developer once you get a design mockup… so you can avoid the mess I made with my first foray into Project One.

1. Look for repetition

Repetition of groups of elements or styling can help you write DRY code. Flag these areas now with class names or semantic elements (e.g., <h1>) so it’s easy to pop these into your CSS file later.

Note: I used Adobe Creative Cloud Assets to inspect my PSD. When you go to the “Extract” tool, you can find all kinds of information about your Photoshop file.

2. Check that it all makes sense

If there are elements or functionalities that you don’t understand, now is the time to clarify with the designer. If you interpret one thing as a hero image and find out later it’s meant to be a slider, that could seriously mess with your code.

3. Think about semantic elements and accessibility

As you work on interpreting the design mockup, make note of what semantic elements belong where and what kinds of elements you will need to include to achieve the layout desired (read: divs upon divs upon divs).

4. Notice fixed widths and heights

Ideally you are designing a responsive website so these dimensions can’t stay. (But even if you aren’t, you can’t make every aspect of every element fixed.) Convert to percentages or ems/rems when possible, but you can view the mockup at 100% and your wireframe/website at 100% and measure pixels to ensure the approximation and conversion to percentages is correct.

Also take note of any instances of placeholder text and how the design might need to scale should there be more or less text than anticipated.

5. Ensure the design is practical

Make sure that the font stacks make sense and the designer hasn’t used commercial fonts that can’t be distributed. Ideally you’ll be able to use Google Fonts or Typekit. Another issue may crop up if the designer has you using fancy fonts or effects that can only be achieved with images. If the site grows and has 30 pages, the designer is going to have to hand letter all 30 headers.

6. Figure out what effects were intended

Make sure links are differentiated from body text by colour and/or style. Failure to do so is a major design and functional flaw. Also consider any HTML, CSS or JavaScript effects such as rollovers or animation that will not be visible in a PSD mockup.

The point of making a wireframe after receiving a design mockup is to map out a plan for yourself as the developer. If you go in with a game plan and a basic structure of your website, it’ll save you time messing around with your code once you realize halfway through you’ve failed to consider an issue of reflow or the fundamental functionality of an element.

I’m Kait Sykes, a front-end web developer from Toronto. I love the internet, learning new technologies, and efficient best practices. I come from a background in book publishing so I’m pretty handy with a pen, too. In my spare time, I’m working my way through L.M. Montgomery’s journals, learning how to knit, binge reading the latest YA fantasy, or searching for the best patch of nature in the city. Come hang out with me on Twitter!