Making a PDF mockup for a client is a time worn tradition in web design, and for good reason: before HTML work begins, it’s important to get sign off on the site’s overall look. The client wants to know what they’re getting before you build it, and it’s important to provide them with assurances you will deliver something in line with their branding, identity and expectations of their site.
At Kobot, however, we’ve decided we’re not going to do PDF mockups anymore.
We know how counterintuitive that sounds. But what we’ve learned recently is that there are downsides to fully-fleshed out mockups, downsides we’d like to avoid.
The web is too dynamic to be faked
On first glance a mockup and a web page look the same: the mockup contains everything the site will. There’s the logo, up at the top is the navigation bar (or maybe it’s on the side), here’s where we’ll put some photos, a bio, whatever you need. When you look at the PDF, it looks the way the website will look when you first land on it.
The problem is that it doesn’t move the way a website does. What if the logo is pinned to the page, and moves with you as you scroll—that’ll leave a hole in the rest of the mockup, a hole that wouldn’t appear if the client could see how it’s supposed to work rather than just how it looks. What about dynamic elements—text or images that move, elements that emerge into the screen and disappear as you ‘, parallax? The mockup makes room for them, and you as the developer or designer know what’s going on, but when you present it to a client it’s flat and lifeless: it’s missing something.
Mockups don’t let you see past their deficiencies
Whenever we present mockups, the first thing a client sees is what’s missing, the holes where dynamic elements should be..
PDF mockups look so similar to a website that it’s easy to forget you’re not looking at a website. There’s no need to use your imagination because what you’re seeing is so similar to the finished product, it’s hard to fill in the gaps: they don’t, on first glance, look like they need to be filled. But as we delve into it, they become all too apparent.
So we end up talking almost exclusively about how the finished site will differ from the mockup that we don’t delve into what actual deficiencies our design might have, the things that need to be changed so that we deliver a website that fulfills our clients’ needs. The process of creating a mockup restricts our ability to communicate effectively with our clients. Everyone is so distracted by the problems inherent in a mockup that nobody can see what problems exist in the actual idea.
So, just what are we going to do?
Don’t worry: we’re not going to walk into client meetings and go, “Trust us, dummies.”
Instead, we’re going to expand upon a practice we already utilize: brown paper sketches and style tiles or mood boards (we know that style tiles and mood boards aren’t interchangeable—you can read about it here www.styletil.es—but sometimes we use the terms interchangeably, or create hybrid documents that do the job of both).
Sketching on brown paper lets us show clients where all the elements of their site will live once it’s finished, but the execution is crude enough that no one confuses the sketch with a real website—we can talk about the ideas contained in the sketch rather than the way they’re being executed because it’s clear they’re not currently being executed.
The mood boards let us discuss the graphic elements with our clients, finalize the look of logos, pictures, colours, word marks, textual elements, fonts and whatever else, before placing them on the web. Keeping these two processes somewhat distinct from each other forces us and the client to use our imaginations as to how they’ll fit together which means that, instead of finding problems with the mockup’s half-finished execution, we can see the deficiencies of the ideas behind the site.
The next step is to get into HTML right away, skip right past mockups and build a website we can show our progress on. It’s no big deal to show a client a half-finished website—we’ve found it’s a lot easier to fill in the gaps in HTML than it is on a PDF. Clients can see the site’s potential better when it behaves correctly than when it stays static.
Better communication, better websites, happier clients
The truth, of course, is that this won’t always be possible to do: sometimes a client might really want to see a static mockup, sometimes it will be the right thing to do for a particular build.
But the hope is that by moving toward a system that cuts static mockups out of the process, we can communicate more effectively with our clients, get to the heart of their needs rather than get hung up on the inherent deficiencies of PDFs in the context of web design. If we can better understand their needs, we can craft better solutions to their challenges, and we can make better websites overall.