What Works Best for Design Presentation?

Posted: September 22, 2008 Comments(5)

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.

There are also times where it’s applicable to include a bit of pseudo JavaScript interactivity at this stage. Sometimes for us it’s very difficult to explain in words the interaction that will be made available. Most of the time clients are hearing about Ajax for the first time and it’s quite difficult to thoroughly understand what’s going to happen.

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?

Get my newsletter

Receive periodic updates right in the mail!

  • This field is for validation purposes and should be left unchanged.

Comments

  1. As static HTML files. I should say that my work consists of writing WordPress themes and simple ‘brochure’ sites, so I don’t really need to do much more.

    This way the client knows ‘exactly’ what their site will look like. It also saves me work later on, as I’ll use the stylesheet as a basis for the final version. It also means I test across browsers right from the start — I need to be sure that my design won’t mess up when the client views it.

    I generally produce the mockup, get the OK, and then add the PHP/WordPress magic.

  2. Well looks like we do the same as Andy Clarke,
    we provide our clients a preview Version of the website with every step.

    But we got the same problems that our clients love to change their minds 🙂

  3. As a designer, my priority is to showcase the design comp within the best possible medium (usually opening the file in PS and displaying it on my iMac). I prefer to do this rather than displaying it in a random web browser on the clients monitor and having to give a quality disclaimer. However, while presenting with my own gear I think it’s important (not to say I always do so) to briefly educate the client on basic web discrepancies so they will know what to expect when viewing it later.

    I suppose this cut’s a lot of work out for the developer and set’s them up for the impossible feat of representing the comp perfectly across all browsers and platforms. Whoops! Putting myself in the developers shoes, I can only imagine this being extremely frusterating.

    Interesting topic to read from a developers point of view. I will take this into consideration before my next presentation.

Leave a Reply

Your email address will not be published. Required fields are marked *