I am an idealist. Deep down, I know this, and I understand that it sometimes gives me the urge to push our industry toward the purest version of itself. My response to this Sparkboxing challenge is written from this idealist point of view because it’s how I believe we should always work through a project—begin with the ideal and adjust for the real.
We have been doing design reviews wrong since the beginning of the web. We’ve been showing pixel-perfect, static images to our clients and expecting them to be understanding when the final live site looks different. We are setting ourselves up for failure. The way around this is to get our designs into the browser as quickly as possible, even before our clients see them. For this reason, there should be two primary design deliverables in all web design (not just responsive web design):
An HTML & CSS Style Guide
A Design Prototype
An HTML & CSS Style Guide
Given the understanding that the web is fluid, we shouldn’t start our design process with fixed width containers. A style guide gives you an opportunity to start designing the components of your site instead of the container. These components should be designed and built (in HTML and CSS) with flexibility in mind, so that they will work in whatever layout they’re placed in. This is especially useful when designing a responsive site.
Showing this to a client will help in two ways. First, it removes the focus of a design review from the containing element and shifts it to the content. Second, it gives you the opportunity to talk about how these individual elements can be used on the site in any context, be it desktop or mobile. A client can get a great sense of the design direction by seeing these components. You’re also being honest with your client—web design is an iterative process. There is no way you can affordably have it all figured out at this point in the game. Don’t try to pretend that you do.
A Design Prototype
Layout is the missing component from the style guide. A prototype combines the component design from the style guide with fluid layout to give us a real sense of how the site will actually work.
If we’re designing responsively, we need to have layouts approved across multiple resolutions. While we could certainly show static images of a handful of these resolutions, we’re setting a dangerous precedent in doing so. How many of these do we show, just the highest and lowest resolutions? What about devices or browsers that don’t support CSS 3 (like media queries, border-radius, box-shadow)? Should we get a design approved for those as well? What if you can’t actually get the site to respond the way your designer originally planned? These are only a handful of the questions that have influenced my conclusions.
My Ideal
In a perfect world, I believe we should translate any static design into a fluid grid, static HTML/CSS template for client review in the browser. This means that those approving the work can see the design in their browser throughout the process, alleviating cross-browser comparison issues and demonstrating how the site will actually work.
Obviously, we are going to have to educate our clients about this new process. We’re not the only ones carrying the print mentality into our web projects. Clients are used to seeing static images to approve design, but now the influx of new devices and the rise in mobile browsing are magnifying the problems this presents. Of course, it will be a process to get to this point, and my above list of design deliverables may not be perfect, but I’m looking for some other idealists to help lead the charge. Just because we’ve always done it one way doesn’t mean it’s right.
Who’s with me?
