Back in September, Andy Clarke re-issued his challenge to web designers to replace the fairly standard practice of designing static visual proofs in Photoshop or Fireworks for presenting to clients with (X)HTML/CSS prototypes. It's a pretty radical departure from the norm for most designers' workflows, and so I had anticipated it to be met with a lot of skepticism or hostility. After all, there's a number of time and money issues related to such a change.
The Conversation Thus Far...
Instead, I found myself surprised to see that by and large the response was cautious optimism, which reflected my own opinion on the technique, marred only by the nagging fiscal concerns. After all, wouldn't all that time spent writing HTML and CSS add to the design time, resulting in either a larger bill for clients or a bitter pill for studios to swallow? Wouldn't this slow down the design process, and bloat it with items that belong in the development phase? (aka, browser inconsistencies, bugs, etc.)
Andy's response was that the technique would help relieve the issue by ushering us into a post-progressive enhancement era where instead of trying to build a full feature set on the weakest browser first and then scaling up from there, we'd start with the fanciest appearance on top, and carefully utilize CSS3 properties now available to achieve this in a way that don't load in older browsers without harming the impact and professional appearance of a site's design. More to the point, we'd be front-loading a client's expectations by giving them the chance with prototyping to see the inconsistencies, liquid layouts, font stacks, simple interactions (like hover states), and other realities of a website from the very beginning, rather than surprising them later in the site creation process.
Conversations on the topic pretty much stalled at this point. Although most participants agreed that the technique was desirable, there was a large amount of disagreement on whether the design phase would expand too much as a result, making the technique moot for most studios' real-life situations and budgets.
To me, this meant that there was only one thing to be done. The prototyping technique needed to be tested. Theorycraft is all well and dandy, but nothing can prove or disprove something more effectively than actually attempting it. So with a Modest Proposal I challenged Mindfly (and the world) to take a chance and try it out. After a bit of examination to the proposed method to determine whether Andy Clarke was a complete nutter (which I suppose he could be, just not in regards to this) we all agreed to give the Ol' College Try.
The Design Phase
Janae, one of our visual designers, was tasked with testing the waters with a small e-commerce site she was designing. Here's a summary of the results of that project. (I'd link it, but this site has yet to go to a live publish).
For the first design phase, Janae went a bit over three hours over. Part of this was due to investing time in the (X)HTML/CSS prototype, and part of this was due to this being of Janae's first projects where she was solely responsible for the design. She was able to take this design to the client via the prototype and show (and not just tell) where the design would differ between browsers (IE's lack of rounded corners, etc), as well as how the site would behave (links hover states, navigation, etc). She found this process to be quite painless, and armed with the client's feedback she went into the design revision phases. These went rather quickly, and when it came time to design the differing appearances of other pages she found that she'd saved quite a bit of time thanks to the pre-existing color and layout styles that the prototype already had.
By the time the design phase was over, she was only three and a half hours past her predicted design budget. Not bad for a first try. It was at this point that I wrote the post The Ol' College Try, where I optimistically predicted that we'd come in under budget by the time the project was finished.
I'm pleased to say I was correct.
The Big Payoff: The Development Phase
The front-end build process (AKA - making the site) was fast. Incredibly so. Our CSS was already 90% finished, and most of the HTML that we inserted into the site's CMS system was modeled after what came from the prototype. This was pretty much what I expected, and I was pleased to be correct. What I didn't expect, but was even more pleased to find, was how few browser compatibility issues we encountered. Usually at some point in a website development process we get Internet Explorer balking at some point with how our CSS is behaving, requiring us to do some corrections to compensate for hasLayout bugs or IE6's complete lack of support for certain features.
However, because we'd made the intentional decision to use CSS3 styles whenever possible to support minor design features like rounded corners for modern browsers (and having these non-critical elements drop on older browsers) instead of going from a bottom-up approach of designing rounded corners for IE first (using old hacks like rounded background images, etc) we had a much simpler, streamlined set of HTML and CSS to begin with. Cleaner HTML and CSS meant less areas for non-standard browsers (aka IE) to screw up, which meant much less time correcting for design bugs. We ended up spending less than a third of our usual time with cross-browser glitches as a result.
That for me is huge, as it's the unexpected browser glitches that usually causes me to start dreaming of pubs before noon.
By the time the front-end was done, we'd gone from being three and a half hours over our projected time to being three and a half under. For those with poor math skills that means we saved seven hours in the front-end build process as a result of using prototyping! More importantly, the client feedback during this phase, which is usually a painful period of adjusting their expectations as a static proof becomes a dynamic website, was instead largely positive as she was already armed with the proper expectations and got to see those become a reality instead of adjusting her vision to match something more realistic than a proof.
This turned out to be incredibly useful, as we ended up with a last minute decision to change the e-commerce engine the site ran on, and were able to absorb the back-end development time that cost us without going over budget.
The Proof Is In the Pudding: AKA, It Works
Overall, this was one of the most pleasant experiences I've seen in developing a website, especially in regards to client relations. Using prototypes, rather than static proofs, not only helped us control our client's expectations with a presentation that reflected the reality of a website, it also saved us a tremendous amount of development time by making much of that design time usable in the finished product. Furthermore, by augmenting the procedure by relying on CSS3 to present advanced (but not critical) design elements that would disappear without generating bugs or an unpleasant result on older browsers. In the end, we were able to produce more results in less time.
It's worth noting that this was a first attempt. There's bound to be areas where we can streamline the process even more. I can't say for sure that this technique will work for all website creators, but based on our experiences thus far, I think any studio can glean some increase in efficiency from it. Go forth and prototype. You won't regret it.
