What process does professional website building follow?

I've searched for a while, but I can't find anything related on Google or here.

Me and some friends were debating starting a company, so I figure it might be good to do a quick pilot project to see how well we can work together. We have a designer who can do HTML, CSS an开发者_JAVA百科d Flash, enjoys doing art, but doesn't like to do HTML and CSS... And 2 programmers that are willing to do anything.

My question is, from an experienced site builder's perspective, what steps do we do - in chronological order - to properly handle a website? Does the designer design the look and feel of the site, then the programmers fill in the gaps with functionality? Or do the programmers create a "mock-up" of the site with most of the functionality, then the designer spices it up? Or is it more of a back-and-forth process?

I just want to know how a professional normally handles it.

Update: A recap taking some of the notes from each post.

Step 1: Define requirements. What will your site/application do?

Step 2: Use cases. Who will use the application, and what will they do with it? This doesn't have to be done with a bunch of crazy UML diagrams, just use whatever visual aids you think work best for you. Find a CMS vendor, or a search vendor, or both. While planning, maybe do some competitor analysis, and see how those in similar fields have done theirs.

Step 3: Visual proof-of-concept. This is done by your designer, NOT your programmers... Programmers are notoriously bad at UI. Use an image program like Photoshop, not an HTML editor. Leave it fluid and simple at first. Select the three-color theme for the site (two primaries and an accent.) Get a sense of how you want to lay things out, keeping in mind the chosen CMS and/or search functionality. Focus hard on usability, add pizzaz later. Turn the created concept into JPEG mock-ups, or create a staging site to allow the client to view the work. A staging site will allow for future releases to be tested prior to moving it to production.

Step 4: Once the site is conceptualized by your designers, have your HTML/CSS developer turn it into markup. He/she should shoot for XHTML compliance and test on as many major browsers as you can. Also a good time to set up versioning/bug tracking/management systems, to keep track of changes, bugs, and feedback.

Step 5: Have your programmers start turning your requirements into software. This can and should be done in parallel with Step 4- there's no reason they can't be coding up the major pieces and writing tests while the UI is designed and developed.

Step 6: Marry up the final UI design with the code. Test, Test, Test!!

Step 7: Display end result to client, and get client sign-off.

Step 8: Deploy the site to production.

Rinse, Repeat...

Step 1: Define requirements. What will your site/application do?

Step 2: Use cases. Who will use the application, and what will they do with it? This doesn't have to be done with a bunch of crazy UML diagrams, just use whatever visual aids you think work best for you.

Step 3: Visual proof-of-concept. This is done by your designer, NOT your programmers. Use an image program like Photoshop, not an HTML editor. Leave it fluid and simple at first. Select the three-color theme for the site (two primaries and an accent.) Get a sense of how you want to lay things out. Focus hard on usability, add pizzaz later.

Step 4: Once the site is conceptualized by your designers, have your HTML/CSS developer turn it into markup. He/she should shoot for XHTML compliance and test on as many major browsers as you can.

Step 5: Have your programmers start turning your requirements into software. This can and should be done in parallel with Step 4- there's no reason they can't be coding up the major pieces and writing tests while the UI is designed and developed.

Step 6: Marry up the final UI design with the code. Test, Test, Test!!

Rinse, Repeat...

There is no one universal way. Every shop does it differently. Hence, a warning: gross generalizations follow.

Web development typically consists of much shorter release cycles, because it's so simple to push out a release, compared to client-side software. Thus the more "agile" methods are more frequently used than the "waterfall" models encountered in developing client software.

1. Figure out what, exactly, you're building.
2. Take care of all the legal stuff (e.g. what business entity you'll be forming, how will each team member be compensated for their work, will there be health benefits, etc).
3. Mockups. I suggest having the designers do the mockups since programmers are notoriously bad at UI design.
4. Set up some sort of bug tracking / case management system so that you have a centralized place for all your feature requests and bug reports.
5. Start coding.
6. Once you have a simple version of your app, get some people to test it out to make sure you're on the right path.
7. ???
8. Profit!

As a first step, I'd recommend doing a bit of up-front design using an approach such as paper prototyping, to lock down what it is you want your website to do, and roughly how you want it to look.

Next up, read up on the Agile approach to software development and see if you like the sound of what it suggests. It tends to work best with smaller, well-motivated teams.

Figure out the minimum amount of functionality you can create that you can deliver as a product so that you can get user feedback as soon as possibly. Then expect to iteratively add functionality to the product over time.

The Web Style Guide provides a pretty detailed overview of the process.

You should mix and match the lists provided here for your needs.

I just want to make sure you know one thing...

Customers are "stoopid" when it comes to web design.

You will have to claw, scrape, drag, gnash, rip, and extricate every requirement from their naive little souls. If you fail to do so? Guess who gets the blame?

The road you now look down is a hard one filled with competition, stress, and risk. It requires endurance, faith, patience, and the ability to eat ramen 5 of 7 days a week.

To add (or repeat) Dave Swersky's list.

1. Gather requirements from clients

2. Do some competitor analysis. Gather screen shots of competitor sites.

3. Build a sitemap /wireframe - What is the structure/content of the site?

4. Get designers to create JPG mockups. They may use the screen shots for "inspiration"

5. Get feedback from clients based on JPEG's

6. Create HTML mockups from JPEG's

7. Get feedback from clients. Go back to step 4 if necessary

8. Implement HTML using technology of choice

9. Unit test the site

10. UAT and obtain sign off.

11. Deploy to live

client feedback is critical, they should be involved in every step to ensure a successful implementation.

Hope this helps

In addition to the steps outlined in other answers, I'd add this (to be added somewhere near the end of the "cycle"):

x. Once you have a more or less end to end solution, set up a staging site.

y. Get client sign off on staging site.

z. Deploy to production site.

Celebrate! But not too hard, there's almost always going to be a few iterations of changes, because users rarely know exactly what they really want the first time around.

So, when (not if), the client asks for changes, you can work on the changes and promote them to the staging site first! This is important because a) it gives clients a chance to preview changes before the whole world sees them b) if the integrity of the data on the production site is important, you can hopefully weed out any issues on the staging site before they impact production data.

Just to give something on the other side of the coin. Where I work, we have for the past couple of years, worked on a redesign of the company's website. Here are some highlights of the process:

1. Identify vendors for various functions that will be needed. In this case that meant finding a Content Management System vendor as well as a Search vendor.

2. Get a new design for the site that can be applied to what was selected in the first step.

3. Using system integrators and in-house developers, start to build some of the functionality for the site and take the flexible, customizable software in 1 and make it useful for the organization. Note that this is where a couple of years have been spent getting this working and some business decisions ironed out.

4. Release a preview site to verify functionality and fix bugs, add enhancements as needed.

Note that in your case you may not have the same budget but there are various CMS frameworks out there to select as well as how much integration do you want to have for the site? Does it have to talk to a half-dozen different systems? In the case I mentioned above there are CRM integrations, ESB integrations, search integrations, and translation integrations to give a few examples of where things had to be wired up correctly.

In response to the comment, be sure you and the client know what is meant by "simple" as if there is any e-commerce functionality, forums, or personalization these are examples where it can be important to know what is needed now and have an idea of what is needed down the road as there can likely be a ton of things that customers may want but you have to figure out some of the nitty-gritty details at points in the future. For example, some people may think that Google is simple, and from an end-user perspective it is though how many computers does Google have running how many different applications doing how much processing 24/7? Quite a bit, I'd imagine. Simple is good, but sometimes making something look simple can be incredibly hard to do.