Home » Articles »

Pen first, pixel later — why you should sketch before you computer

A blank screen is a daunting prospect. There’s a strong temptation to get right in there with your wireframing software and start drawing boxes. But don’t give in. It’s a trap.

Design User experience

Surface design can hide deeper problems. Emphasising visual design at the wrong stage of a project, or a focus on style before getting the substance right can mask structural issues which only appear when it’s too late.

Too much detail too soon. It’s tempting to spend time focusing on details or how it looks, before understanding fully the bigger picture. Like sitting down to write an article and spending ages choosing the typeface and colours before deciding the topic.

Overly attached designer. It’s easy to hone in on an idea you really like at the expense of the wider project. And it may stop you from exploring other, potentially better ones. Murder your darlings.

It’s harder to make big changes later. Once everything is laid out and looks great, it can be time consuming to make significant changes. You will find yourself less willing to do this as the deadline looms closer.

Instead, put down the mouse and draw.

What sketching is

Sketching is thinking on paper. It’s expressing ideas simply and quickly. Use pen and paper, your shiny iPad Pro, MS Paint, bits of old envelope, crayons, whatever, as long as you’re happy. The aim is to explore as many different ideas as possible, getting a feel for the site and its various elements.

Sketches can be a bit wobbly. It’s not a drawing competition. As long as they get across your ideas, you’re good. In fact they should be a bit wobbly. If you’re spending too much time on making them look great, you’re missing the point.

Sketches are low-commitment. It’s not wise to show highly finished designs early in a project. When things change, and they will, you’ll have to do round after round of amends.

By using sketches you can quickly get agreement on the approach first and finish things fully later, when there’ll be fewer big surprises.

Sketch with clients. They’ll love you for it. Clients often have a good idea of what they want but have difficulty expressing it. They say things like, “We want it round, but sort of square”. That’s fine. Expressing it is your job. As they talk, sketch. Draw what they’re saying, and keep iterating until you reach what they mean. Propose ideas, brainstorm. It’s quick, fun, and gets everyone involved in the creative process – which is great as people feel more ownership over something they had a hand in.

There’s a possibly apocryphal story of a product designer back in the 50s who learned to sketch upside down. He could sit opposite clients and still draw the right way up for them. He almost always got the got the job.

Here’s a sketch I did, not more than a scribble. It only took seconds, but it was really useful to explain how columns respond at different breakpoints.

Here’s another one. I put more effort into this, knocked out the background and everything. But the principle is the same: it didn’t take more than a few minutes, it’s a bit wobbly, and explains itself clearly.

Detailed wireframe sketch

What sketching is not

Sketches are not deliverables. By this I mean that sketches are not what the client is paying for. The client is paying for your problem-solving skills, your ability to design a site which meets their and their users’ needs. Sketching is just one tool of many to achieve this.

Sketches are not wireframes. You can’t just scribble a few pages and hand them over to a developer be built. Well you can, but you’ll enter a world of hurt and everyone will hate you.

Properly worked-up wireframes are vital. They do form part of the deliverables, and will be used by both the client and the rest of your team as a blueprint for the final site. Even if you’re building the site yourself, for yourself.

However, only once you understand the important parts of the site and have a feel for the various page elements and interactions – and most importantly get buy-in from everyone involved – should you finally get wireframing.

Further reading