In the past I've done some HTML, CSS and PHP coding, but I've only ever worked on things that were already "finished" and I've never started a website from scratch. However, I recently purchased a domain and some hosting for cheap, and I'm hoping to improve my HTML, CSS, and Javascript skills so that I can become a bit more marketable as a web developer/webmaster.

Typically, what process do you use to start a website? Do you draw the layout on paper and then do the code? Or do you just start coding and tweak the output to your liking?

  • Made community wiki since there is no right answer
    – John Conde
    May 16, 2011 at 17:31

7 Answers 7


My process generally looks a bit like this:

1. Features. With pencil and paper, lay out the distinct features / pages that will comprise the site. This gets at the broad stroke questions - are you building a simple info and graphic site for your mom? an ecommerce solution for a small business? a blog / gallery for a photographer friend? Your answer will determine a lot about the build path you will need to follow. This stage may also involve considerable discussion with a client or whomever is driving the boat (if it isn't you).

2. Wireframe. With all necessary features laid out, work up a wireframe. Either on paper or with a tool like fireworks that will allow you to build in very simple navigational functionality. If you are working with a CMS like wordpress, how is your static content going to be handled? This might also be a good time to start thinking about file structure. If your project will need a custom database, now is also the time to start planning its design and implementation. This is a critical stage, as smart planning will save a lot of backtracking and reworking, should errors get made, or the project creep happens.

3. Technology. Once the planning stage is relatively worked out - pick your technologies. Are you doing straight html? a php cms in a lamp environment? .net mvc storefront? These questions may influence what hosting environment will be required, as well as costs to run the thing. If you are doing a storefront, security is a primary concern here (SSLs and PCI compliance, for example). Make sure you have a great testing environment (localhost, or otherwise) established.

4. Design / Layout. When your feature list and wireframe is pretty well determined, you can start thinking about the design of the site. Knowing what is going to fill the pages is, obviously, a pre-requisite. I like to work in photoshop, and make heavy use of folders as an analogue to your markup structure. I go so far as to name them with the intended markup and css identifiers. Though its probably wise to do some free form drawing before you get really detailed. I tend to make use of "layout" files that I will pull elements from, and place into "process" files - files that i use to output production graphics.

5. Markup / CSS. Once a pretty clean design is worked out (given that it will certainly flex a bit, as you go into production mode) you can start writing markup. I generally like to have a standard layout that will accommodate all content in the site. So - clean and flexible should be the key point here. Layout markup should be fairly complete before you start writing CSS, but I find they do a lot to inform eachother. You also will do a lot of SEO optimization in this stage (proper naming of images or A tags, meta info, doctypes etc...) Be thorough.

5.1 Theme Management. If you are working with a CMS, and your design will be employed as a customized theme, find some tutorials on how exactly to do that for your intended application. This can be daunting, frankly ;) I will always build a static markup layout with fairly complete CSS prior to chopping it up into theme elements.

6. Behavior. When your markup and css is looking pretty complete, and maybe your theme is in place, you can start developing behaviors (rollovers, etc.) Unobtrusive javascript is important, unless you are making use of features that absolutely require it (an ajax-heavy gallery, or data-driven flash content). The general rule is - if someone visits your site with javascript turned off, what are they going to see? I sometimes remove static elements and replace then with interactive versions at runtime.

7. Content. Unless the design is reliant on content (images are sometimes content, for example) = I generally use placeholder text/graphics until the design and behavior is pretty well established. Avoid doing work more than once. If you are filling in product data, careful error checking and testing will be required.

At that point, there always seems to be a period of reworking and fixing and polishing. But, essentially, its time to make it live. Then go have a snack.

Hmmm. I guess thats more than just "how to start". But maybe it helps, anyway. Good luck!

  • Finally, a beautiful answer
    – John Conde
    May 16, 2011 at 23:39
  • Well said... +1
    – Jeremy
    May 18, 2011 at 13:59

When designing a website I start by asking why?

The first part of my workflow is asking WHY? If I'm working with a client I need to make sure they have a clear defined vision of what they want the website to accomplish.

1. The Why Questions.

  • Tell me a bit about yourself and why you are doing this.

  • Who are the customers? What’s their specific need / pain? Please be able to provide me - with a few specific examples of different types of customers, what they need, what the website will do for them.

  • Tell me about the business. What is it that you exactly do?

  • What makes you better than the next guy?

  • If you were searching for the service your business provides what would YOU type into Google to find it?

If your building the site for yourself then you better already know what these answers are.

If you determine based on the answers to the questions above that these people are serious and actually have a good idea. Then proceed (Remember you are not getting paid yet but you better kock their socks off if you want them to hire you.)

2. The Research.

Spend some time researching the client and his business. Find out their past successes and any problems they have encountered. Are you the 3rd developer they have hired? What happened to the other 2 guys?

Find out what the customer needs. Who will you be building this site for. Is the customer a 60 year old retired veteren or a 16 year old pimple faced kid who plays Farmville on Facebook all day.

Find out who the competitors are. They might not even know. Do a competitive analysis of 5 to 10 competitors and find out who's ass we need to kick in the Serps. This is the stage you need to know what the key word targets is. Any later and your already failing.

2b The Proposal

Blow them away with your knowledge of their business and come up with a website agreement / proposal and be ready with your contract once they agree. Get the signed contract and a 50% deposit then proceed to step 3.

3. The Mission -- Have one

There’s a common theme here: in all of these cases, the mission isn’t about the product as such. The mission is “just” something that, if you’re really serious about, requires that the product become absolutely amazing, so you make that happen. If you prefer: these missions are all the answer to, why did we just add that new feature?, not, what new feature are we adding? --Benjamin Pollack.

The timeline needs to be established so everyone will have their expectations in perspective.

4. The Workflow

This is where most people start so I will explain my process but you will have to decide what workflow is the best for your situation, team, client etc.

  1. For me The Content comes first. I make make sure that the client has a majority of it done before any code is written. We're not talking final draft proof editing but more or less the words of text that will be on the pages. If a marketing team is involved this could take a while.

  2. You should already have an idea of what the site will look like. You should have the content. Now you need to work on the layout and general design principles that will accomplish the goal you came up with in step 3.

    I HATE wireframes but understand that they are necessary. Just because you know what the site looks like your client might not. This is for your protection and the clients. When everyone is happy make them sign off on something that says "This is what we are paying you to build".

  3. Frontend development and UI - HTML, CSS and DESIGNING IN THE BROWSER, Andy Clarke's Hardboiled technique. I'm tired of wasting so much time in Photoshop when I know can demonstrate a more realistic faster mockup that also gives me a head start on the development.

4b. The Codebase

You finally get to have some fun. For yours and the clients benefit set up VERSION CONTROL before you get started. Since your doing version control you should go ahead and set up BUG TRACKING while your at it.

4c. Copy Editing

Remember that content we have? Now is when it has to be copy edited. I suck at this so I try and hire someone else or make sure a lot of people read it. Check and make sure those keywords we talked about in step 2 are optimized for SEO. If our content is great and is actually about those key words this should come naturally.

5. Beta and UI Testing

Get some real living breathing human beings to sit down in front of your site and start using it. I like to enlist my mother who sometimes calls and wants to know why her printer won't print (The plug Mom, It has to be plugged in first). These kind of users need to be able to navigate your site unless of course were using the 16 year old pimple faced kid example above.

6. Maintenance and SEO Plan

Make sure everyone knows who's in charge of fighting off the server beasts.

In a month refer back to the competitive analysis we did and compare our site to the ones we analyzed. Use this data to create your SEO plan and NO I'm not talking about the snake oil SEO, I'm talking about making sure your still generating relavent content, sites are naturally linking to you (because your so awesome) and your title tags match the body text. SEO is a long process unless your Stack Overflow and have an army of 14.1 million users to generate quality content for you.

There is a big difference between quality content and the stuff you find on "the hyphenated site", which I won't be linking. (To prevent the no-follow juice from even dripping on them).

7. Launch

Everything works? The mission of building awesomeness was achieved? Have a launch plan and execute it.

If you did everything right in steps 1 - 6 your launch will be a breeze no strike that you might you will have problems. Just be ready for them and fix any mistakes.

Send the invoice, rinse and repeat.

  • 1
    Great answer. My only issue may be in the workflow area: yours could only be considered "well practiced" - which is great, if you are well practiced and and have a squeaky clean process. If you are just starting out, as the OP seems to indicate, making use of things like wireframes and thorough mockups is probably wise. In other words - designing with markup alone would be, I think, be pretty awkward and constraining to someone who is still a beginner. At any rate - I appreciated the focus on assessing the landscape and really overshooting whatever expectations a client may have. Cheers!
    – Bosworth99
    May 25, 2011 at 14:48
  • 1
    Good points and I will agree that wire frames are needed. The flaw is that it's real hard for some clients to understand that it just represents a very basic structure. The key is to keep them primitive and so design, color or typography is not introduced because it's not time to talk about that stuff then.
    – Chris_O
    May 26, 2011 at 6:41
  • I still think designing in the browser is best practice for any case. Andy Clark argues the case very well in his Walls Come Tumbling Down presentation.
    – Chris_O
    May 26, 2011 at 6:44
  • +1 about clients and wireframes... Interesting presentation. I completely agree about adaptive designs and not being "pixel perfect" - browsers simple will push your css around, and thats ok - the key is to provide for flexibility. That being said, and maybe its just old habit, but I still like to "at least" rough out a design in pshop -
    – Bosworth99
    May 27, 2011 at 15:07

I like to start with <!DOCTYPE html>

Seriously though... first priorities:

  1. Find out what the client wants. Draw a rough sketch for the basic layout, come up w/ a color scheme, etc.
  2. Do a basic navigation and layout mock up (static) and work with the client to refine it.
  3. Actual production. Get CMS and/or static content in place. Confer with client again to make sure it's what they're looking for and they can handle the CMS/the CMS can handle their needs.
  4. Refine and repeat 3 until the client is happy.
  5. ????
  6. Profit!

First of all I would draw the basic layout and design it on paper before starting coding. After completing the basic design on paper,it is easy to code it in modular way.Offcourse php & css would be the best way to customize it.


I always like to start by making a mockup using some sort of photoshop software so that it can incorporate any and all images in your site.


Most of the answers already goes in depth, let me just add that you should use some framework or templates so you don't waste time rewriting the basics.

There are many PHP framework available out there (Kohana is my personal favorite) or many people use Wordpress as a base. Also you could use a CSS framework, again there are many out there, one of the most popular is the 960 grid system


When designing a website, how do you usually start?

Like you i found the need to market myself as a web developer / designer a few years back. I found my starting place to be to understand in my own mind, what information, image and message do i want to offer to visitors visiting my website? and what i wanted the user to accomplish/do whilst visiting my website.

Once i gained that understanding the design process became a lot clearer. It allowed for me to write down the elements of my homepage and subsequent pages that would communicate those items.

For instance i was very keen to make my CV easily findable and downloadable. So when designing my site i ensured that information about my CV and where it could be found where readily available.

The moral of the story is to be relevant. Everything on your website should serve a purpose, otherwise its just unecessary noise.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.