How I present designs to clients
I’ve presented design concepts to clients in a number of different ways over the past few years: as JPEGs sent via email or Basecamp, as HTML and CSS, as flattened images in a browser, even using apps like Notable and ConceptShare. I’ve never stuck with any of them for long, but over the last year I’ve been using a method of presenting designs that has finally stuck. There’s nothing revolutionary about it; it’s really just about recognising which tools are best for particular tasks and being conscious of not repeating work.
My method of presenting designs to clients will be of most benefit to you if your workflow is similar to mine. I typically arrange to present designs for a maximum of 2-3 key pages, in order to establish a creative direction. I begin the design process with pencil and paper, sketching out rough page layouts. I then move into Fireworks, fleshing out my sketches into broad content blocks and exploring form, colour and typography. Having established the treatments of these primary design elements, I further develop page composition and refine detail elements before stopping.
By this point, many of us would’ve worked the provided text (or at least lorem ipsum placeholder text) into the designs and would be saving out the 2-3 pages as flat images to send over to the client. Almost everyone I know does this, but I think there’s a better way.
Markup is your friend
I know I’m not alone in saying that working with text in Photoshop or Fireworks can be a royal pain in the arse. Selecting fonts each time from the drop-down menus, trying to manage text styles across multiple pages, deciding which type of anti-aliasing to use, having to own the fonts you want to use in your designs, no way of showing :hover states… it’s laborious, cumbersome, expensive and incredibly inefficient when you know the pages will have to be built later anyway.
The alternative? Write the content out in HTML, style it with CSS and overlay it on top of the design in the browser.
Having already settled on a creative direction in my graphics app, I export the first page design. I then grab my text editor, centre the exported image in a browser and add repeating backgrounds—where applicable—using CSS. I write the content out in lovely old semantically-rich HTML, style it with CSS and absolutely position the content over the image. Here’s why:
- I've started writing re-usable HTML and CSS during the design stage, saving me time on build later.
- The text is rendered the way my client is used to; the way they're combination of OS and browser always does it. No decisions need be made about anti-aliasing styles.
- I've opened the door to a huge range of web-licensed fonts with Typekit, Fontdeck and @font-face, negating the need to purchase them outright.
- I can now easily manage all text styles across multiple pages using CSS, an otherwise painful task in a graphics app
- My client can interact with :hover and :active states for links.
- I can quickly turn around those small, annoying text changes my client has just requested without having to open a big clunky Adobe app.
Of course, you can take it further by creating elements with HTML and CSS to replace those in the exported visual, bringing you closer again to final build. For example, I tend to weigh up the time needed to grab a jQuery plugin (including time required to undo/redo any work) and throwing it into my designs, versus trying to explain to the client in words how it’ll work when it’s built. The main thing is you to work as efficiently as possible; don’t spend more time than you’ve scheduled realising elements from your visual in HTML and CSS if you know there’s a chance your client will reject them.
Do it right and nothing is wasted
Marking up your content in HTML for presenting designs means you can keep it all and you don’t have to rewrite it later. Even though you won’t be able to keep all of your CSS, the only thing you should really have to refactor are your positional styles. The point is that content is a constant. Though it might change, it’s not an element that’s going to disappear. Anything you can do to manage it’s associated styling more efficiently and ease amendments to the content itself is good.
Now, let’s look at an example:
The example is an adaptation of a site design I’ll be launching for a client next month. Every bit of text is inline. My client sees the mockups in their browser from day one, which is of course where the website will live anyway. My client also understands immediately how the ‘Featured case study’ fade in/out works, saving me time having to explain it or point them to someone else’s jQuery tutorial page. The main background and footer background always span the full viewport width using CSS, so the client doesn’t have to imagine how their site will look when it’s repeating background(s) aren’t being chopped off at a width of 960px.
So why not do it all in HTML?
If you’re reading this, chances are you’ll have read at least one or two the cases put forward for mocking up entirely in HTML, avoiding graphics apps altogether. It just doesn’t work for me. I get sucked into a hyper-analytical coding bubble too early and it really inhibits my creativity at what should be a design concept stage. I’m glad it works so well for the guys at 37Signals, but to that end: the methods you use should be chosen as the best match for the type of work you produce. Fireworks and Photoshop are still necessary evils for me; there are tasks I can achieve quicker there than with HTML and CSS. More importantly, there are often times when I’m simply more comfortable creatively in Fireworks and Photoshop. Whilst it’s good to push the boundaries of ones knowledge, I think it’s equally important to know when you’re comfortable with your tools and to make full use of the benefits that brings.
The caveats
If you’re not comfortable working in HTML and CSS, the way I present mockups probably isn’t for you. That said, I’m neither the quickest nor most proficient front-ender around. Any opportunity you have to brush up on (or begin) learning HTML and CSS is one you should take. I’m also not claiming that this technique is applicable in every situation; I’ve found it to work most efficiently when presenting 2-3 pages for client approval. I wouldn’t recommend presenting 10 pages like this, as you’re going to make more work for yourself recfactoring your positional styles.
It’s important you have some existing CSS to use when doing things this way. Don’t write everything from scratch; it’ll take too long. I use a continually evolving default folder and file structure for all new build projects, including a structured CSS file providing a framework for common element styles, a reset and a sprinkling of other bits and bobs. This helps to speed up the process of writing the CSS I need to present my designs to the client.
Depending on your working environment, my techniques may not work for you either. If you’re a one-man band, then of course you can usually do whatever you want. If you work as part of a larger team, it’s important to bear in mind your team members’ capabilities. If someone has to pick up and amend your designs but they don’t know HTML or CSS, it’s going to screw up the process, along with your timescales.
All that said, if you can see the potential benefits of my method working for you, just give it a shot. I’d love to hear how you get on.