Joshuaink: Creating a site schematic

Please note that you may have been redirected (you might like to make a note of the URL in the address bar of your browser and update accordingly) This is a permanent archvie but is no longer actively maintained. Please visit http://joshuaink.com for the latest updates.

Creating a site schematic

Friday March 25, 2005

Wire frames, site maps, I am never sure what the correct term is but whatever you want to call them they are fast becoming my new best friends. I quite like 'schematic' because the end result sort of reminds me of a diagram of a printed circuit.

schematic screen grab

Disclaimer

I am becoming increasingly aware that publishing information such as this on the web is a responsible act, and for this reason I feel compelled to state that these are simply ideas and are by no means the correct way of doing things, just may way. This is only intended as a quick and somewhat incomplete overview, I have provided links to further reading at the end of this article in the hope of building on what is touched upon here.

The problem

More and more I am finding myself in situations where it's not just me and an individual client designing and building a website, there are usually a few other people involved: graphic designers, programmers and the client (which may actually be 3 or 4 people, one of whom is someone's nephew, who is a web designer don't ya know!). Often it also the second time around for the client's website and the project is considered a 're-design' of the old site.

To a client, the word re-design often means tart up the graphics and bingo, job done. To me a re-design means re-structuring the site, looking at where it works, finding out where it doesn't work, finding the areas that are confusing to use and, of course, turning the whole thing over to web standards. Communicating this in simple language that everyone can understand can be really difficult, finding out what the client actually wants is another great challenge, communicating all that back to the design team is another task in itself.

Over the years I have found myself in a number of difficult situations, all of them through bad communication, all of them leading to increased development time, ultimately leading to loss of profits:

Design don't fit

Clients really want to see some visuals, as soon as possible, and I have fallen into the trap one too many times. You produce some design mock ups then get the content and realise there is not a chance in hell that design is going to work with that content. Try explaining that to a client who loves the look!

Can you just add...

The dreaded feature creep, where the client requests a few 'minor' features and suddenly you find yourself with a load more work to do, or a situation where suddenly the design don't fit no more. The worst case I ever had was a site that was supposed to contain 34 pages and a password protected area, through misunderstanding and bad communication the site ended up with nearly 200 pages and two password protected areas. Because of the bad communication it was difficult for me to charge for the extra work, not good!

It's not what we were expecting

Not one I have suffered from often but only through sheer determination not to let the client down, this relates very much to the 'can you just add' request but this time the client says nothing until the launch and then realises they had actually wanted something different after all.

The bottom line is, I have had to learn, sometimes the hard way, that although a client may nod and agree with everything you are saying, they could well be thinking about the holiday in the Caribbean they are about to take, and it won't be until half way through the project that they will reveal the truth, ooooh! is that what you meant, I misunderstood can we change it?

Too many cock ups were starting to put me off the web design business and, credit where credit is due, it is only through reading the likes of Andy Budd and Malarkey that I have managed to bring some sort of order to my projects.

Trying to fix the problem

Before you can propose an appropriate solution for a client, you need to get to know a bit about them and this I find quite tricky. I often find myself competing against another web design group who, inevitably, say they are going to do it cheaper, faster and better. It's a bit of a balancing act, you don't want to reveal your full hand, giving away all your secrets to the other web designers (one member of the team also being the managing director's third cousin). On the same token you need to extract enough information to make the right pitch. I have started offering a really simple questionnaire for the client to spend ten minutes filling out (you can grab a sample PDF here). This questionnaire is not designed to answer all the questions that need answering but simply to give an overview of the client, if I win the project a second 'bespoke' questionnaire is sent and goes into a lot more detail.

Typically, the questions can reveal some interesting stuff, for example:

Would you like to update your own website? yes.
Is the person who will be responsible for updating the site familiar with HTML? no.
Would you like to add photography to your website? yes.
What software will you use to prepare your photography for use on the web? microsoft paint.

In just four questions I can already see that a text editor and an FTP client are probably not going to do the trick, and I might need to recommend Photoshop Elements with a wee bit of training.

I am straying off topic slightly but I just wanted to highlight this process of 'kick starting' the project.

The second stage of any project for me has become building a site schematic and you can see a simple example here(140k). This example shows a first build based on the answers to the questions given, the initial planning meet and, as is often the case, looking at the existing website. I would anticipate re-working this schematic as many times as it takes, until everyone is satisfied that the project is delivering what is needed. At this stage I will not have presented any kind of design mock up.

There are a number of reasons why these visual schematics appeal to me:

The home page

You can see instantly whether the home page is doing what it is supposed to, is it encouraging people to the parts of the site you want them to visit first? Is there too much information on the home page, or not enough?

Keeping it simple

If the schematic is starting to look really complicated then there is a chance that the website will end up the same. I find them really useful for looking at the usability of a site.

Who, what and where

I like the fact that you can see where data is sent to someone. Where should that go? To an email address or into a database? What happens to that data when it gets there? Are there enough points of contact?

On the example given there is no links page or indeed any other obvious 'exit point' but these can also be highlighted. It was something I did quickly for the re-design of this site and it is the reason my home page no longer contains a side bar full of links off to other websites, too many exit points for my liking!

A cure for magic wand syndrome

I find these visuals quite dramatic, even though I actually understand what is being communicated, and to someone who doesn't really know how a website comes together that must surely be increased. I don't excpect anyone but me to really understand what the hell it all means, so I always provide documentation to accompany the visual, or sit down with the client and talk them through it. What it does highlight though is that a website that works takes time and for that reason, it will take more than three days to put together.

For some reason I have started calling this the magic wand syndrome and it's the situation where the client thinks all we web designers do all day is have lunch with each other and then return to our machines, half cut on booze, three taps of the magic web wand, and the job is done. Some people find it difficult to believe that any effort goes into this stuff!

Summary

I think the real reason I like these schematic visuals so much is the amount of questions they generate. I am the first to admit that this part of the project can be hard work and a bit of a chore. What it does do though is give me back the enjoyable bit, the actual building of the website. With a seriously tight project brief and a very clear goal I can get on with what I love doing, HTML and CSS.

joshuaink

Creating a site schematic

Disclaimer

The problem

Design don't fit

Can you just add...

It's not what we were expecting

Trying to fix the problem

The home page

Keeping it simple

Who, what and where

A cure for magic wand syndrome

Summary

Further reading

Kev

David Horn

Martin

William Doyle

Joey

Keith Bell

Andrew Hume

Josh

Matthew Pennell

Rob Mientjes

Schultzy

Tom

Jeff Smith

Frank McClung

Vincent Grouls

Tom

Sid

Viking Karwur

Christmas gifts?

Recently

Geeky shiteMeta

Main navigation

Page foot