When we designers were in college, we were taught how to elegantly present design work. Black boards, spray mount, and $20 inkjet prints have been the norm for years for branding work and print design client presentations. When presenting web design work however, this method work causes many easily-avoidable problems:
No one is ever going to see your website on paper, so don't present your work on paper. The $1000 you'll spend on a decent projector will pay for itself when it comes time for eleventh-hour revisions due to poorly-presented initial work. Even if you don't have a projector and you need to pass a laptop around a board room, it's much closer to the end result than showing printouts.
Regardless of the tools you use to design, make sure your presentations are as close to the final medium as possible. If you're designing a normal website, export your design as a big JPG, place the image in an HTML file, and apply the appropriate background colors or images to display the comp as accurately as possible. Here's an example of what mine typically look like; feel free to copy the source code and use it yourself. If you have a dropbox account, you can dump these files in your public folder and you won't even have to worry about FTP connections, etc. Crazy simple. This little step goes a long way to make it appear like you've actually designed a web site, and not ...well, anything else.
This can also serve to remind you of the limitations of the medium as well. Look at your work in the browser often to make sure your fonts are a legible size, you don't have horizontal scrollbars, and your header image doesn't take up the entire screen.
Keep in mind that for some projects, users will print individual pages. For example, we have a few Real Estate websites where users print pages to take with them while they're researching home listings. We created a stylesheet that allows them to print a well-formatted flyer from each home listing. When that's the case, go ahead and show a printout to the client.
For the same reasons as those listed above, presenting mobile designs on a deskop screen isn't an entirely accurate experience. You can get close though – check out this 'window' that I created for an app that we're working on. (Again, feel free to swipe my code.) It's just two images and a little bit of CSS, and you scroll sideways to see the different views.
The other way I've presented mobile work is actually in HTML. If your client is looking at your work on an iphone, this certainly takes more time, but the CSS code will end up being mildly useful for your iOS developer in the long run. Here's an example of the full walkthrough in HTML – check it out on your phone, or shrink your browser window down to a phone-like width to approximate the experience on the desktop.
I write code for a lot of designers who don't, and I can always tell when the designer starts in a primarily vector application, such as Illustrator or InDesign. There's nothing wrong with that on the surface; any design tool can export a big JPG for me to slice up. The problem actually exists in the design process that is used when working in these tools. By the nature of how vectors and fonts work, you can't tell when you're designing an object while zoomed-in. If you must work in these programs, make sure you zoom out to 100% frequently, and understand that type below 11px tall is completely unreadable on most screens.
Also, problems sometimes arise when exporting from vectors. In print design, a pixel is this etheral concept that doesn't completely translate to anything real. (If you print something at 50 pixels-per-inch, much more ink goes into printing a pixel.) For this reason, vectors are great for print design. But when it comes to the web, you get much better control over your design if you work in pixels. When you export Illustrator or InDesign files to JPGs, the program has to create aliasing and guess which pixels to put where. Take a look at this example. Here, I compare a straight InDesign export to the file that I manually edited to clean it up after it had been exported.
Whatever you end up doing, check your work in context as often as possible, and present accordingly. There will be fewer surprises for you and your clients when your designs actually get turned into code.
30th March 2016