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.
Nice post man,
still haven’t tried it, but I’m sure I will give it a go soon.
I know you’ve advocated this before, but I couldn’t help comparing it to Dan Rubin’s user testing method he presented at the DIBI conference.
Pretty nice idea, I’ve tried lots of ways of presenting but not this one.
One thing I wasn’t sure about from your explanation: do you still do the text in Photoshop initially, then switch those layers off to export the whole image without text? I’m not clear on whether you’re doing any typographic design in the graphics package, or you can somehow magically design without text? (I know I couldn’t!)
Love the vertical rhythm of your blog by the way :-)
Great Post Robbie!
I have always, drawn out the layout and any ideas on paper, then used fireworks to design the concept and then used a flat image on a html page. I always had to explain hover effects etc to clients, so i like your approach on adding more html elements to the table! i will give it a try and see where it takes me. I also use an ever changing template framework for new project to speed up the design process. Thanks :)
This is a real interesting way of presenting work. One I don’t know if it will sit comfortably with me. But I’m willing to give it a go, which is exactly what I’m going to do!
Definately a lot of food for thought!
I almost always write the text out in dreamwearver, adding the correct font style and size and overlay it on top of the design in photoshop, the main reason, as you state, is the anti-aliasing. Photoshop almost never renders text correctly so this way is much easier.
I love the idea of writing the content out in HTML, styling it with CSS and overlay ing it on top of the design in the browser.
My main issue I have with combining the design stage and the coding stage is that if you get the design wrong and the client doesn’t like it, you have wasted a whole bunch of time coding.
I will admit that any self respecting designer should have gained enough information, that when they are done with the design it SHOULD be almost exactly what the client asked for, however sometimes it doesnt work that way.
Personally, I struggle to do my initial design outside of Photoshop but your method does sound like it’s worth a go – how do you first decide how the text will look without first putting some into Photoshop?
I’ve done mockups using html and css straight in the browser before, yet have never migrated to anything like your method. Definitly food for thought.
Excellent post with an excellent style!
@Matt & @James: It really depends on the each particular design. I’ll often get a feel for the type treatment in Fireworks and experiment there before jumping into markup, but sometimes I just jump right into the browser and experiment with broad font stacks and Typekit. It never gets to the point where I’m entering large amount of text in Fireworks, as that’s when it becomes a royal pain to maintain!
@Alex: As you’ve hinted at, a good brief goes a long way to ensuring a suitable design direction is agreed on before anything is developed too much. That said, there’s no failsafe solution. Bad things happen. You’ve really got to find a balance between your graphics app and text editor that suits your particular workflow.
I’m pretty used to this kind of method, i love to put my hands on code and the some goes to the design. I just love this “work” it says: “I’m alive” to the client and the client usually like to put his hands on your work to test and say something.
But one thing I’ll try to do is to make a default project and start new projects from there. For now I just have one page full of elements that may appear on the projects. Need to change this right away!
BTW: real nice form effect!
Really interesting … I already think about it but never do it this way, because I always feel that I will be loosing time.
Next time I´ll try to see what happens …
tks,
Rodrigo
I have started doing things in a very similar way to this recently, I find it so easy to create a much more realistic way to present to clients. Cheers for the writeup, its always interesting to see how others work.
Interesting read. I still have to come across a project that allows enough time to present the design in such a way. It’s definitely a more realistic approach, but the time constraint is usually the problem.
Love the design, btw. Good luck with your new job at FreeAgent btw.
Kai
Hmm… very interesting.
Dan Rubin was saying at DIBI about the advantages of doing UX testing in high fidelity web pages over paper / wireframes as it allows the client to interact and the devs to change stuff on the fly.
Andy Clarke was also talking about how we shouldn’t be sending out PS comps as you’re entering a world of pain trying to explain why they look diff in diff browsers – this approach gets round this brilliantly as those with chrome will see the text shadows and rounded corners, and those with IE8 won’t… and quite likely neither will be aware of the differences!
@Kai It depends on whether or not you’re designing as well as building. If you’re doing both, any extra time you’ve spent writing HTML and CSS during design concept stage will be saved on development time, so there should be no need to factor in any additional costs for presenting in this way.
@Andy I was actually at DIBI and chuckled a bit when Dan was presenting his method, as I already had this post saved as a draft! The only real difference is that I use an inline image on which to overlay the inline elements (as opposed to a background-image), as that helps define the height of the page without having to set a height separately in CSS.
Hey Robbie,
If you wanted to start learning web design today (let’s suppose you’re already familiar with graphic design) how would you get started?
Would you learn HTML?
XML?
XHTML?
HTML5?
Not even bother and start learning a WSYWIG program?
Flash?
There’s so much out there I have no idea where to begin.
Thanks for your blog.
Personally I would say start with HTML and CSS (and within that aim for HTML5 and CSS3)
It may be a little more alien to a designer than perhaps Flash or a WYSIWIG setup, but ultimately its the best grounding for learning webdesign… and in that don’t rely on something like Dreamweavers Design mode – learn how the CSS and HTML are supposed to work – don’t pick up shortcuts and bad habits.
It can be interesting to try out. Never thought about this way, since it is needed to do some slicing anyway, it comes more natural (or istinctive) to just start laying out in HTML+CSS… but then, for sure you could get stuck with stupid floating/aligning problems and loose the focus.
It is quite a while i don’t make layouts ground up in PS, that is because in the few latest design i’ve done, i well knew what i needed and created only the single graphics elements (like a tiling background img), so i was making everything from the editor.
I’ll consider your way next time i’ll have to PS something.
But this is just the “N” article on the subject, it proves once another time that if someone comes out with a killer prototyping tool, he’ll make a s*load of money. I have some ideas for a tool like that, i just hope i will sometime be able to implement it :D
Hi Robbie, very interesting article and the trends toward early html and css has been continuing since then.
What I find really useful with tools like Notable, ConceptShare or Cage, is the ability to add annotations directly on the page, whether for me to explain some of my decisions or for the client to give feedback. Explaining in words graphical elements can be a pain for me and clients. I don’t know of any way of doing the same with html mockup (except making screen capture, but that would seem “awkward”).
Do you plan to share some thoughts on getting great feedbacks from clients in an upcoming article?
Thanks
Sebastien