What’s wrong with the mockup?
The mockup has long been ingrained as a key deliverable in our design processes. Designing a website for the local dry cleaner? You might agree to deliver five mockups, one for each page of the site. Each would be approved and tweaked individually, then implemented in code after everything was pixel-perfect. The problem with that approach, though, is the mockups lie. Never would the live website look like the mockup’s pixel-perfect vision of the world. At a bare minimum the type would render differently in each browser and each operating system that viewed the site. Certain features would not be supported the same way across those same browsers and operating systems. And that’s just in the traditional web design world.
Responsive concerns
But now, as always, web design continues to evolve. We’re in a world of atomic design, responsive design, mobile first, content first, and whatever other considerations and approaches are available to guide website creation. Mockups encourage us to focus on the pages in isolation rather than a reusable, modular design system.
Those mockups continue to lie the more we look at them. What does the site look like on the client’s iPhone or Windows Phone? What about on a customer’s larger Samsung phone? What about on another customer’s tablet? Now we have at least four different screen sizes to worry about.
That’s easy, though. We can just do a mockup for each of those screen sizes! Except now the budget’s increased exponentially. Now we’re creating 20 mockups instead of five. I’m sure the corner dry cleaner can afford to pay for all this extra work.
Design changes
Approaching each page as a mockup can become quite cumbersome, especially as you go further in the design process. If in the course of the design a button needs to change, you could have hundreds of places to go to change the mockups. What if the changes you need to make require reflowing or rearranging content? Anyone who’s worked with Photoshop, Illustrator, or Fireworks knows this can be a time consuming, cumbersome task.
Static, single-state, pixel-perfect focus
The mockup encourages the client to get hung up in a static, single-state scenario. All the mockup represents is a snapshot of what the site could look like. If presented too early in the process, it could lead to focussing too much on content, or visual design, or a myriad of other distractions that hold the design from completion.
These are just a few of the many reasons the mockup is dying.
So, can the mockup be saved?
The mockup can still thrive. It just needs a different job title and role in our process. Instead of a pixel-perfect view of future site, the mockup should be thought of as a communication tool. It should just be one of the tools we use to craft and share a design.
So if the mockup can live on as a communication tool, what does that look like?
Our first atomic design post introduced Brad Frost’s concept of atoms, molecules, and organisms. By focusing on these components of the design, we can communicate the design system both internally and externally as we develop it. Sketches and mockups of individual molecules can be used to explore designs rapidly. These mockups of molecules can be combined into a larger style exploration, be it a style tile, a style guide, or element collage. It allows us to communicate design direction and features without the downsides of presenting a complete, static mockup. Atomic design-minded mockups help the team focus on what is important at a particular moment.
What replaces the mockup?
With the mockup now operating with a different title and set of responsibilities, what’s fills the space left behind? The reality is there’s not one particular deliverable that could take over all of the mockup’s responsibilities. It’s a team effort, but there’s one type of deliverable that could be a solution: the prototype. We’ll have to leave exploring the benefits of a prototype to another post.
