My approach 

My approach is simple:

• Find out what the end-users need (I call these ‘user goals’). That isn't you, that's your customers. Who are they? What age ranges are they? What's their eyesight like? Do they like the colour black? It's all important. The smallest details about the end users can have huge impact on design.

For instance: teenage boys like the colour black, it's exciting, it reminds them of games consoles and big LCD TVs so most sites aimed at male youth have a black, green and/or orange theme. Older generations associate black with death, mourning, night, fear, etc - so maybe you'd be better off sticking with pastels or bright happy colours if you're aiming for them.

• Support these user goals first and foremost, make those individual goals easy to achieve with the site or software.

If I identify four main goals for a user visiting a site, I'll make sure those four goals are one click away and highly visible, not five clicks and hidden away somewhere in a small font!

• A little goes a long way. I believe in a little at a time, early releases, early feedback.

A system should be tested by the people that are supposed to use it and not just the ones responsible for creating it - I can help you make this happen.

The best tester is someone who has no previous exposure to the system and matches the profile of an end-user for that system. Developers and customers are usually too close to the project to truly test it.

• Documentation only when required

No big documentation. It tends to hinder rather than help production. The one exception being a 'functional specification' or 'storyboard' to agree the project’s aims.

• In other words: 'Keep It Simple Stupid' is my personal mantra.

Simple isn’t ‘lazy’, simple takes effort and discipline: to know what is enough and then stop there!