Funny, I actually had this window open to type, but you know, something good on TV came up so...
it almost always starts with me and the client and a pot of tea and a few hours, a notepad and pen and most importantly my ears. 2hrs should do it...
after that I'll piece a proposal together and PRESENT it to my prospective client. I wont email/post it. I've lost the job if I've done that. if they like it I'll grill them for some more info, and then before a single keystroke is made on the project. draw up a contract with impetus on the SCOPE of the project, and provisos for work that falls "outside of scope" usually an hourly rate.
Not all clients want a responsive design so its a case by case basis but that info is needed to be gathered BEFORE a project begins...retrofitting a website to be responsive is a horrible nightmare. dont do it!!!
if you can, gather content as early as possible. a design built around content is much smoother, but thats not always possible...also any assets the client can provide are worth getting. if they do not have any, or their current "look" is rubbish, offer a rebrand.
set realistic timeframes and keep the client in the loop the entire time. a client who doesnt know whats going on is an unhappy client.
as for the build, this is something everyone differs on. me I sketch the design first, then build in the browser. I create a sprite sheet for buttons and image assets. I build an html wireframe first, then add the css and js. review all the time. I build 50/50 in firefox/webkit (chrome+safari).
pick your battles with legacy browsers.
ie6 I do not support at all, ie7 and ie8 I give a bit of love but leave the bells and whistles off. again this is a personal preference but two quotes I've heard recently. "
When we build for the future, we actually build the future" and
"If you design a site to work with yesterdays browsers it looks like yesterdays website" both are very true.
one of the most important things when building a website for me is testing (and this is pre-testing before the client gets to it.) as its very easy to get too close to a project when you are the sole contributor. I find two testers. 1. A technologically savvy, 24/7 net user and 2. someone you know who "struggles" on the internet. your mum, your partner, a friend, etc. both will find different issues. both will find issues that you wont see. 1. will be UI issues 2. will be UX issues 90% of the time.
always set aside time for testing and crossbrowser. thats always the first thing to get cut when deadlines are looming...
I havent mentioned a great deal about "coding" in this as, to be perfectly honest, it is such a small part of the bigger picture, but code tidy and semantic. if you cant read your code like a book then its messy. it should be easy to read by anyone who will ever need to work on it.
SEO - see above. and then post launch you'll need to NOT put all your eggs in the google basket. a lot of people forget that there are other (more effective) ways to advertise your website but the SEO dinosaurs like you to believe that their "dark art" is something thats worth a million bucks. dont fall for that BS. Once people finally get that all they effectively are doing is burn your money and the net wont be littered with all their tripe. idealistic I know but a man can dream!
