It begins with the brief. The brief defines the project objectives, informed by business goals, tactics, requirements and restrictions. It should broadly outline the content required to achieve these objectives, be it information about the products your client sells; company background information; latest news. Whatever. Brainstorm with your client, conduct user research and study competing sites to guide discussion as to what content is required. If it’s a redesign, you might have rich analytics data to accompany all of their existing content. The brief is signed off before any IA or design work begins.

IA (Information Architecture, if you’re not into the whole brevity thing) isn’t simply about site structure. IA covers user research: user needs, aims, behaviour and knowledge. It allows you to look at content you have, content you need, how to plan for it and how to group it. It should explore and define required content in detail. Format, length, intended audience and relevance to any specific tasks. Is it structured content, like a product page, or unstructured content, like a once-occurring ‘About us’ page? IA is not just a sitemap.

Once you’ve communicated the IA to your client, content authoring can begin. Fail to communicate the IA properly and you can kiss your deadline goodbye. The client must understand what they’re expected to produce. I can’t stress this enough: make sure your client grasps fully the breadth, detail and purpose of the content they are expected to produce.

Your IA work should’ve given you enough of an idea about the content to begin designing the framework for it. With the IA signed off, your design work and your client’s content authoring begin — in tandem.

Don’t leave your client out in the cold. They need reassurance that the content they’re authoring is good, just as you need to know it’ll work harmoniously with the design. Communicate constantly. Writeboards or Google Docs are handy for this kind of collaboration. Provide feedback and incorporate the latest content into your designs. There should be a continual conversation between the developing design and the developing content.

As your client edits and refines, so you design and build. More time spent editing and refining means a better end result. No last minute content dump into the CMS. No long, drawn-out ‘content population’ process, delaying launch. No need to look on in terror as your templates implode with all the extra content they didn’t tell you about. Donna Spencer says it best:

“Content shouldn’t be treated as an afterthought, or something to be “poured” into the website. Content is the website“

I’m only scratching the surface of a workflow here. If you’re really interested in producing better web content, I’d highly recommend Kristina Halvorson’s ‘Content Strategy for the Web‘ and Donna Spencer’s ‘A Practical Guide to Information Architecture‘.

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:

Show me something fool

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.