For a few years now, I have had the feeling that we are approaching web design in the wrong way. Many designers—and their clients—have made the transition from the medium of print, and transferred the design processes too.
In print, we were all used to producing proofs with millimetric—nay, pixel-perfect—precision because we had to: the high-resolution of print meant that that one pixel gap was obvious when the material came off the press.
But it made absolute sense to produce these proofs—or composites (“comps”)—because print is a fixed medium: what you see is, pretty much, what you get.
Building a nightmare that never stops
Hence the bane of the website builder’s job: a pixel-perfect Photoshop comp married—in Hell—with a customer who doesn’t understand that their website is never going to precisely match that beautiful image proof that they have signed off.
The web has always been a fundamentally fluid medium: in print, the amount of text was often governed by the size of the printed page—in web design, the very opposite is true.
And this point is compounded when designing for a content management system (CMS), where the designer could not—and should not—absolutely control how much text a user can insert.
The death of the static image comp in web design
As such, I really believe that we need to kill this idea of using static image comps in web design and, a few weeks ago, Brad Frost succinctly summed up why in a post entitled The Post-PSD Era…
Throughout my career, I’ve watched immensely talented designers waste a shitload of time creating fully fleshed-out comps of what a website could look like. Pixels get pushed, details are sweated, pages are printed out, hung on walls, and presented to clients. Clients squawk their feedback, then designers act on it. They repeat this dance until everyone is content (or until nobody gives a shit anymore, which happens more often than you’d think).Only then do those pristine comps get handed (more like shoved) over to developers to build.
It’s an increasingly-pathetic process that makes less and less sense in this multi-device age.
As it happens, Brad wrote this post at roughly the same time as I was presenting a new design process to my fellow managers—and I found it when looking for some pithy comment with which to populate a slideshow presenting said process to the rest of the company.
Bringing it home
My company designs and implements websites on its own Content Management System (CMS). I have moved through different positions within the company over the last five years, but I was put in charge of the new Creative and User Experience Team in July.
In between delivering customer projects, I have been attempting to make our processes more efficient. It swiftly became obvious that there were a number of problems with the way in which we designed and build our websites and intranets.
Improving our process: driving efficiency
The first has been largely improved by the adoption of an increasingly robust CSS LESS framework.
The second, however, was more difficult to address—customers’ expectation that their websites would look precisely (yes, even in IE7) like the lovely images that they had signed off .
We were also duplicating work.
So, the first thing that we did was to push the responsibility for producing wireframes solely onto the Information Architects; wireframes were already an output of these workshops (driven largely by the Attention Mapping exercises), so duplicating this work seemed ridiculous.
Next, we created a selection of mood boards—with recognisable, non-techie names—which, combined with the wireframes, enabled our designers to get a very good idea of what the customers were aiming for.
Zombie comps that will not die
But, at the end, we were still producing fixed image comps that were taking too long to create and, importantly, amend. Customers were getting hung up on the positioning of elements when, in our CMS, you can place anything anywhere (just about).
So, in December, I my research turned up Samantha Warren’s styleti.es—a website dedicated to promoting the use of said Style Tiles.
Style Tiles are similar to the paint chips and fabric swatches an interior designer gets approval on before designing a room.
An interior designer doesn’t design three different rooms for a client at the first kick-off meeting, so why do Web designers design three different webpage mockups?
Style tiles are for when a moodboard is too vague and a comp is too literal. Style tiles establish a direct connection with actual interface elements without defining layout.
The sites and systems that we build are huge.
There is simply no way that we can proof up all of the pages that make up the tens of functional Modules that our customers may have bought.
Style Tiles and a way forward
As I saw it, Style Tiles—with a bit of modification—would enable our company to provide the important elements to our customers (the look of a menu system, how a Staff Directory entry might be displayed) without them getting hung up about where on the page these elements might appear.
After all, not only is the web a fluid medium but our CMS also gives the customer total control over their page structure.
With Style Tiles, clients could focus on the important details, rather than getting hung up on where those things appeared on a page. We would, in fact, be aligning our processes with the flexibility of our product and thus reinforcing its superiority.
There were, of course, other benefits, including being able to turn around work much more quickly and thus increase the productivity of the team.
It’s never enough…
But Style Tiles wouldn’t be enough—especially in the age of Responsive Design.
As such, we decided to build Live Prototypes alongside the Style Tiles. With our LESS framework (which has mobile @media break-points built in), and the CMS’s inbuilt styling options, this became a viable proposition.
The first run is scheduled for Tuesday morning: I’ll let you know how it goes…