While impressing your clients, don't forget that the clients should also be impressing you. Ian Coyle says you should "proactively interview the client to see if they're a good match for you, not the other way around. Each one must value my design philosophy before they're considered a potential to work with."
Research is one of those phases in a project that's easily overlooked, particularly when it comes to designers working solo on a project. However, it needn't take up much time – and research is a broad umbrella for a wide variety of pre-design activities, so it's not as daunting a concept as you might first think!
With the majority of the sites I create, the budget and timescale rarely allow for research on the scale you might find conducted by agencies, so I try to get as much done as possible within just a few hours. That means looking at the client's competitors to see what they're doing right and what they're doing wrong, and then developing ideas about values the brand should express.
"At its core, design communicates," says Ian Coyle. "Prior to designing, I work to discover what we're communicating and how we want the viewer to connect with it. Then I define an interaction model that's centered around that experience."
The brief I've read a lot about how different types of brief should be written (a creative brief, a technical brief and so on) but for smaller projects, this isn't usually necessary. Similarly, the lines between a brief, a spec or scope document and a contract can often be blurred. Even when they're combined, sometimes all that's needed is a well-written email in which the aims and expectations are clearly defined.
Essentially, a brief, spec or contract is just an agreement between you and the client about what needs to be done, and a formal way of covering yourself, should the client end up unhappy with the final product. Of course, that's not to say a formal contract isn't a good idea and you'll be pleased to know that, like the brief, writing a proper, legally binding contract is actually rather easy.
In fact, there's very little writing required at all, since Andy Clarke prepared a generic contract on last year's 24ways site: 24ways.org/2008/contract-killer.
"A solid contract is really important," notes Sam Brown. "Don't get complacent: if anything goes wrong, you'll have to rely on your contract heavily, so it needs to be able to hold its own!"
Structure and navigation
In my experience, the biggest area of client confusion or indecision comes not from the design itself, but the structure of the site, and how the pages and sections interact with each other. Some sites, even relatively small ones, can seem difficult to plan when there are many features, or if you haven't managed to secure a particularly thorough brief or spec document.
In these situations, it can help to focus the client on the site's navigation – to simply ask them what the main links will be. This can then be furthered by discussing sub-navigation that should appear on the various pages and, before long, a structure will appear all by itself.
It's usually at this point that it's sensible to start thinking about sitemaps, if they haven't appeared already through your conversations about navigation. WriteMaps provides a simple, out-of-the-box method and is an ideal web application for those clients who aren't used to more advanced tools such as Microsoft Visio or OmniGraffle – and even more so for clients to whom sitemaps are an entirely new concept.
Or, if you'd like to create a clickable sitemap yourself using HTML and CSS, try using SlickMapCSS from Astuteo.
Using wireframes
Sitemaps do a great job of seeing the 'bigger picture' of a website's structure, but sometimes more subtle interactions need specific focus. Take, for example, an order form that updates its fields without refreshing the browser window, or hides certain elements depending on the user's input.
There's no need to bog the client down with how it'll work technically, but it's important to get them thinking about the different interactive processes that their users will be going through. I've found that clients are more able to think of these detailed forms of interaction once they start seeing visuals, even if they're just 'grey box' wireframes.
If your client happens to be visually inclined and wants more input into the layout, then it might be an idea to let them loose with a tool such as Balsamiq Mockups, which generates rough wireframes in a hand-drawn aesthetic, using a library of common interface elements.
How much free rein you give to your clients with a tool such as this is dependent on the situation and the client, but it can help to ease the burden on you.
Once the approximate placement of elements on the pages is decided in your wireframes and signed off by the client, it's time to get down to the fun stuff: making it look like an attention-grabbing, aesthetically pleasing website. And this is what tends to take up the most time in a project, because the aesthetic layer is where things start to get emotive.
People have very strong feelings about colour, texture and, of course, the general atmosphere that's conveyed. This is why it's a good idea to really separate out the wireframe and aesthetic stages. Although they're both parts of what you could liberally call 'the design phase', they focus your client's attention on different aspects, one part at a time.
Very loosely, you could say that wireframes enable them to think about layout from an interaction point of view and aesthetics enable them to concentrate on the emotive experience.
