One of the more hefty, involved parts of client work is the approval process. There are a number of hurdles to overcome to make sure the details surrounding deliverables are clear. It’s very frustrating to feel as though a project is coming to a close, all the while your client has been under an assumption of something different. Beyond the clarity of scope or other project details, one of the more difficult things my company has run into is presentation of design comps.
Presenting a comp
Over time, my company has come up with a few ideas as far as ways to effectively present our designs. We’ve gone so far as to bring one of our own machines to a client meeting in order to make sure things were presented properly.
Very often, clients would have concerns about tints, hues, contrast, and other design elements. That is not to say a client is incorrect in doing so, these are issues constantly under fire simply by the medium that is the Web. We were doing ourselves a disservice by bringing our own equipment (which has been calibrated) and using our own software. At the end of the day, even if a client loves a design on your own gear, when the design is shown to a friend, it won’t look the same.
The issue isn’t inescapable, though. No matter what, when the client shows the site to someone else on a different monitor, that’s the way of life in Web design. It is important, however, to avoid creating ideal experiences when presenting Web design.
The way it should be
We had to keep in mind that we’re presenting websites. We’re used to compensating for the shortcomings of the medium, so why make things harder by presenting in an ideal environment?
We’ve come up with a quick and dirty development process just before the designs are presented to clients. During this process, the website will be loosely put together as a static, stylized document. The markup will be junk, and there might even be some inline styles. It doesn’t matter though, we’re just presenting a comp. The markup we’re writing won’t make it past the end of the day. It needed to be quick though; we bill by the hour.
Using this method, we’ve got a design for presentation that will be properly viewed in a browser. It’s much more effective to present this way not only because the client is in a proper mindset, but the design resides in surroundings which affects perception. Browser chrome can indeed have slight influence on a design when compared to a flat file viewed in another application.
Beyond that, and perhaps most important, is the fact that the client is viewing the design under their circumstances. Their OS, their browser, their color calibration, their habits and tendencies. All of their concerns will be effectively settled because they’re able to “work” with the design as it was meant to be.
Interestingly enough, Andy Clarke has just posted his thoughts on the issue on For A Beautiful Web and indicates that he takes this process even further. He’ll piece together quite a bit more markup and style than I’m used to, and simply work from there as the design progresses. With each iteration, a link is provided to his client and the cycle is repeated until completion.
While I think that’s a great idea, unfortunately I don’t see it working for my company quite yet. Our clients are far too quick to change their minds throughout a project, which would result in us taking numerous steps back, causing an awkward exchange when we bill for the design work that wasn’t ever used. Either way, it’s great to see another outlook on the process.
How do you present designs? What’s worked? What hasn’t?