The Stages of Web Design for a Client
An integral part of our job, as designers, is to communicate effectively. When we speak about our processes in front of a client, though, we often fail in this area.
We might not consider it jargon because these are names we use every day, but the client probably has no idea of the hidden meanings behind these.
I write ‘hidden meanings’ because although it’s obvious from their name that wireframes might just be outlines of what someone might see on a screen and comps (short for ‘composite layout’) are fully fleshed out designs in the final colours and fonts, those names don’t explain how these tools are used.
I realised this recently when speaking to a client: their questions and requests showed that, while they had signed off on the wireframe and information architecture, they weren’t really sure what they were signing off on.
We provide a phased approach to design so that the client can have input and sign-off at various stages during the process. This is supposed to be helpful and provide a sense of progress during what is the set of often unseen actions that it takes to make a website.
Perhaps we had failed in communicating the stages and their uses to the client because they started asking for functionality changes after we had moved past wireframes, they asked for menu items to be moved around on comps.
Many of these changes were barriers to progression on the project, as far as the client was concerned, but realistically had no bearing on the final product (which image was used on the comp in a placeholder section, for example), or required a return to a previous phase (changing the home page from a news matrix to three highlights in a carousel).
So I created this description for them. It runs through the phases of creating a website and what it means in terms of working with Floate. It identifies what is appropriate to alter at whichever stage of the process and what isn’t worth worrying about until later.
These are by no means the strict rules of creating a website. Everyone has their own process but we’ve found these phases (which all come after the research phase) are the best for walking a client at a large organisation through a complicated decision tree.
This is often easy to produce after a solid research phase and it can help form the decisions in the rest of the process. We start with a dump of all the things we think need to be on the website as a result of interviews and competitor analysis. Then we categorise them based on behaviours we’ve seen in the research. Sometimes we’ve already started thinking about functionality.
IA can take a number of forms: a two dimensional tree is common although not realistic with a site that used a CMS with categories and tags. It can be a quick sketch of a page that shows how much of a screen needs to be dedicated to different pieces of information. It can be a diagram that shows how the different taxonomies of a site are defined.
The two things to remember here are that none of this is set in stone, it can all be changed right up to and including putting the content in the CMS, and that there is no right way to do it. Everybody understands the structure of information in different ways. There might need to be several treatments before all stakeholders understand where the project is headed.
Universal comprehension is the goal when producing IA.
These are used to show user interface concepts at a very rough level. Content placement on these pages is vaguely indicative of final versions only. The key with wireframes is that they contain everything that is expected on a page in roughly the right spot, but without any specifics around the names of sections, wording in captions or colours (if any are used).
Wireframes are general and low fidelity by definition. They are the skeleton that defines how the website works.
Composite Layouts (Comps)
These are high fidelity examples of what a page might look like. They can be used to get a good sense of font-sizes, how images appear with text, colours used etc. As part of creating the comps we try to create all the elements that we plan to use in the website: what will buttons actually look like in all their different states (active, hover, passive), for example.
The comps create the rules we use for how the website looks. Again, the content may not be correct. The names of menu items might be wrong (we can change them when we build the site) and images might be stock photography rather than final product.
We try to make it as accurate as possible but the nature of using a content management system is that it’s easier to make these changes once we have the colour and shape of everything confirmed.
Chances are, the number of pages that we have wireframed will equal the number of pages we have comped so you can see progress. Together, these will inform the functional and visual build of the website.
This is the phase to get to the nitty-gritty. Once we’ve built the website, changing the way something works or the shape of a button is time-consuming and inefficient. We should have changed those in the earlier phases.
But wait a minute. That paragraph should appear above the image with the happy man standing in a field and the graph needs a caption of “growth over time”. That’s a change we can make really easily in the content management system.
The carousel on the home page runs too slowly, let’s speed it up, and we’ve just tested that form internally and we need a couple more steps for people
Seen a problem on the live site? Ready to go to your boss’s office and commit some horrific ancient ritual? Put the sword away. We can change that pretty easily. Some people may have seen the error but it doesn’t mean that it has to stay that way for all eternity. It might take a couple of hours to get the change through, though, because we have to change it on the staging site first, have it approved and then export the changed files, but it’s still possible.
Sometimes we are disappointed that we can’t do everything on the web that we can do in print. Other times we’re glad we can do so much more.
This post was originally published in the Floate Design Partners blog