I recommend you don’t mockup the entire website at all. It only leads to misunderstanding and disappointment. Especially when creating a responsive website, which obviously is what is required today.
What I do is I start by showing the client an empty website template running on a local Web server on my MacBook, or a private staging server if I’m working with a team. I use a production-ready template and hand-coding, but you could also create a prototype in Dreamweaver or whatever you like. The client and I sit there together and we build out the template by adding the pages that we want, and adding in a little bit of content that they may already have, in some cases from a previous website.
I put a class in my template that makes elements appear to be sticky notes, and so I put any notes for each page in as divs and add that class and the fact that they are yellow blocks with drop shadows and a handwriting typeface makes it obvious to the client that those are notes, not part of their website styling. And I can set that class to hidden to hide all the notes, and we won’t accidentally deploy a note as content. The fact that the notes are overlaid on each in-progress page is much better than hiding them in a text document.
Pretty soon into this process, the client already feels like they have a new website. They can work the browser and navigate between the pages, they can see notes on those pages that say things like “headshot of John Smith goes here” and so on. The site is like unfinished furniture, but you can still sit on it and see if it is comfortable.
And since it is only running on a private server, I don’t have to worry about optimizing anything too early, I don’t have to worry about different browsers. That all comes way later.
At the end of that session, I’ll typically email them a PDF of each page of the website. I have an AppleScript that does that automatically.
Next thing you know, the client is really excited to get a new logo made, to pick a color scheme, to choose a typeface. That is when you start doing design proofs. But I don’t make them look page-y, I just do a logo card with some type under it, a nav bar, all against a color scheme. That makes it easy to do a few of them: light logo on dark, dark logo on light, maybe 3 color schemes, and I show them to the client like a home decorator would show color chits. I don’t give them a whole page to look at, just some choices of styles. It is much easier for them because they don’t have to visualize anything, and many people can’t visualize graphics. I’ve shown them on iPad or sometimes I print a few of the proofs as postcards and let the client shuffle them around and compare them. The client has a context for these design proofs because they were already hands-on with the website. Same as a home owner has already stood inside an empty white room when a decorator shows them color chits.
Typically, one of the cards excites the client more than the others and that is the one they want. No second design round. The logo of course then gets exported as SVG and we drop it into the top line of the responsive grid in the website. (I use Skeleton which is very simple and easy.) The text styles and color scheme from the design proof is — of course — put into the website’s CSS. You don’t have that step of recreating a print-style page layout because there is no print-style page layout in responsive design. You basically have one column of blocks on a phone that can expand to 2 or 3 columns (or however many you want) on a bigger screen. You don’t set text sizes based on taste, you set them based on what is readable on each device.
At this point, the client also has some more content ready — hopefully — so we load that in as well, replacing notes that are in there.
Then I sit down with the client and we go over the website again, focusing on the content, adding a few more notes, maybe an additional page.
Based on their content, I might suggest we do some animations, add some stock photos, create some call-to-action blocks for important pages (which go into the second column on larger screens and appear at the bottom of the scroll on a phone.) The design energy goes into creating/improving actual content in an actual website. We are way before launch and yet we are working the same way we might work after launch to improve the website. There isn’t much wasted energy at all. Instead of showing them mockups of imaginary website elements that they may or may not want, we look at their actual content and say: we can drive users to these 3 important pages with a set of 3 descriptive inline buttons. Or: we can do this photo gallery as a big, immersive slideshow that runs automatically and also offers forward and back buttons. Or: we should make an animation that explains this concept instead of just having a long page of text.
A key thing with this process is that you don’t overwhelm the client by asking them to visualize a bunch of stuff. You show them the in-progress page and you show them design proofs of elements and then you put that element in there and you move on to the next thing. You ask for some content or information, and you plug it into the website. You suggest a widget or animation for this spot here on this page and then you build it.
What little layout there is comes down to managing the responsive grid in such a way that your elements are appropriately sized for each other. You work mostly on the space between the elements and their relative size to each other, not laying them out within the browser window which you don’t have any idea how big it will be, or what shape it will be.
When you get the site so that it is basically ready to launch, at that point you switch to a deployment mindset and optimize, maybe move the whole thing onto a particular server and/or CMS the client wants. All the stuff that doesn’t change how it looks and feels. But you don’t waste any effort because the task is a straightforward one of improving and optimizing an existing Web document that is already full of content.
The best part is that the client feels like they were on the Web development team because they watched the site evolve from nothing. I didn’t show them a “finished” mockup that confused them into thinking the website was already built on day 1. They saw it empty, they saw it shaggy with notes on it, they saw it when the logo first went in, they saw it when the colors and type were styled. You don’t have to explain to them that a lot of work went into it, they saw that work happening in the browser view, piece by piece. When they see the deployed site they are proud of it.
In the past, I had a client express disappointment that a launched site looks just like the mockup they saw weeks before. [Sound of mind blowing.] That is a key thing: you have to understand that the client is not a graphic designer, not a Web developer, and may not even really make any kind of document regularly. You can’t necessarily show them lorem ipsum and expect them to get anything good out of that. You can’t show them a mockup that looks like an 8.5x11 page and then be surprised when they are disappointed to see just the top part of that page in a Web browser on their computer. But if you show them a raw piece of marble and say: now we are going to sculpt this into something custom for you, based on your needs and requirements — that gets them more excited than mockups with lorem ipsum in my experience.