Ideal Web Development Workflow Proccess

[mountainlou]

Hi, I have been researching various workflows and am curious what suggestions you guys have. For software to follow proccess and the ideal workflows.

From start to finish, what general steps do you have and what software do you use to ensure economic use of time?

Here's my very simplified take:
1. Research, meet with client to get goals and intentions for the site.
2. Create graphical concepts for "look" Fireworks or Photoshop (pros/cons?)
3. Get revisions/sign off on graphics
4. Get content/images from client
5. Code site Dreamweaver / other?
6. Test model for clients
7. Sign off by client
8. Launch

Many thanks

[dnordstrom]

Hi, welcome to SitePoint. Nice to see you're checking out some different workflows. It's interesting.

Personally, I like Agile and I try to implement as much of the principles as I can but also try to simplify things as much as possible as to not confuse the client. Perhaps you have looked into Agile and XP already. I prefer doing things in iterations with stories/tasks and so on, and most importantly to be very flexible to change. Since change almost always occurs unless it's a very small project, we might as well make it as easy as possible to accommodate it.

Since I rarely do any of the graphics for projects, I mostly deal with the actual development/implementation. For me a small project may look like this:

• Talk to the client. Listen. Discuss. A design has magically appeared and we find out what is needed for the implementation right now, put it in writing and have the client sign off on it digitally, along with my contract.
• We write stories that the client can prioritize for me. I estimate them and figure out what tasks I need to take care of before it's done.
• We work in iterations by grabbing the top prio stories/tasks to cover one or two weeks.
• When a task is done, or really whenever possible, the changes are committed to a SCM repo and deployed to a test site for the client to have a look at. If the content was not provided up-front, we may also set up a staging area where it can be added—for example if the client needs to add a lot of products to a web shop.
• I have a kind of target cost pricing, so the cost is estimated but can vary depending on when we consider the project completed. If we finish early, the client saves some money.

A keyword here is "we". I want to have the client involved along the way, and work together with him/her to nail what he/she is looking for. It's very difficult to explain all of this briefly since it gets way too simplified but perhaps it at least gives you a general idea.

[oddz]

Content dictates design. So content *should always* come before design. Otherwise your just making stupid, presentational containers which is going to result in stupid, presentational mark-up alongside a design that is purely decorative, rather than helping to convey cognition of content and purpose of the site.

[tankianann]

I second this. Content should come before design. Form follow function.

In my projects, I often discuss with my clients
-> what the purpose of the site, then
-> decide what content to publish to serve this purpose, then
-> decide what content should go into which page, then
-> go into my mockups.

Content dictates design. So content *should always* come before design. Otherwise your just making stupid, presentational containers which is going to result in stupid, presentational mark-up alongside a design that is purely decorative, rather than helping to convey cognition of content and purpose of the site.

[Chronister]

I prefer the iterative process as that is the standard which is used in any form of development these days. When I talk to clients, I make sure to ask them what content will be on the site, what audience will be viewing the site, and how they want the site to be designed. Ironically, the problem that gets me is when the client wants something that I think would be a terrible idea, but I cannot talk him/her out of it.

[sg707]

I prefer the iterative process as that is the standard which is used in any form of development these days. When I talk to clients, I make sure to ask them what content will be on the site, what audience will be viewing the site, and how they want the site to be designed. Ironically, the problem that gets me is when the client wants something that I think would be a terrible idea, but I cannot talk him/her out of it.

Most of the time when I take the "iterative" life cycle then it's probably because the client's themselves doesn't really know what they want. They are typical "Show it to me first and then I'll tell you". If you have a client who is very specific, then I would follow your waterfall life cycle. I have a feeling most use "iterative".

[Ashley Wilis]

As far as possible, we try to use a standard process for our web projects. Although it can seem like overkill for smaller projects, one thing I've discovered is that when it comes to building web sites for large organizations, there really are no shortcuts.

If you cut corners, it will always come back to bite you in the end, whether it is in the form of last minute design or content changes or a site that just doesn't meet users' needs.

[Dorsey]

I agree with the iterative process that drives to closure, even though I "grew up" programming in the days when the set of steps in the first post were state-of-the-art to assure a successful project. Someone who owns a plumbing supply business can't conceptualize the site no matter how clever you are with PhotoShop and a projector; he or she has to "work the controls" and show it to their friends, and that can only be done by building it out as you go along.

I've had success using this approach, and my time during the iterations is not cheap. In the end, my customers remember that they like the site, and bask in the glow of compliments and new business.