Search Engine Marketing - it's only as good as the underlying website you're promoting.  I often ask marketers how the development process works for them. Do they have visibility into the project to make sure the website meets their goals?  Are they satisfied with the speed and results of the development process?  Frequently the answer is no.  From experience, I think a lot of the blame for this is on current web development best practices.  In this article, I want to briefly write about how current processes fail, and about how marketers, managers and other team members can participate in a better web development process that results in a better site in less time.

Current best practices for web development almost always follow some variation of the waterfall model. It’s known as a “waterfall” because once you cascade down to the next level, you're not supposed to need to go back to the previous level.  If you have to, you usually need to start the process over.  Anyone who's tried this knows it doesn't work very well. In reality, the waterfall method is more of a mad flow that feeds itself.

1) Generate Website Spec Doc - A complete, thorough and authoritative description of what you plan to build.

2) Creative/Design - Put a nicely branded look and feel on the spec.  To the extent you don't understand the spec, the spec is incomplete or doesn't make sense, just add/alter the design to show the changed/completed/altered functionality.

3) Build - Based on the two authoritative sources above, work to create a third.  Fill in the holes, pave over rough spots, and generally do whatever it takes to make the end result function and still appear to be based on the spec and design.

4) Deploy - Test to make sure you've satisfied the spec.  Which spec?  Take your pick from the various steps.  The specs just kept changing. Go back to the step of your choice now that everyone's had a chance to really look at what's being built and repeat until you just have to deploy or until everyone is reasonably satisfied. 

It's not that the four steps are wrong. They are a good guideline, and it makes sense to plan before attempting implementation. But the waterfall method does not map to how human creativity works.  It's hard to know if your web project does what you want without having a chance to interact with it. Trial and error is a more natural mode of decision-making and creativity, and it's hard to engage with a written specification compared to a functioning website.  The waterfall development method is like trying to teach a child to walk by having her read a book about walking as opposed to letting her fall, get up, and adjust until she gets it right.

What are the alternatives?  There's the rapid application development paradigm.  Its philosophy is: if you can develop really quickly, just start building and adjust as you go.  Do as much iteration as you need to get it right.  I actually like the trial and error aspects of this process, and I think it gets all stakeholders more engaged, brings out more ideas, and makes it more likely that the best choices see the light of day. However, it's just not practical or cost-effective, even with the best rapid development environments.  Building functioning web applications takes too long.

What is the answer?  Follow the general steps of the waterfall, but with many, many iterations along the way.  Use collaborative tools to visualize and simulate the final deliverable before designers and programmers start building the website.  This gives you the benefits of the rapid development paradigm, but without the costs, because iterations are fast and painless.

In 1999, we started as a web development shop; we struggled with many of these issues and know the pain points. We've now transitioned to a software company, and our latest product is a collaborative tool called ProtoShare. In my biased opinion, it can help you revolutionize your development process the same way that it helped us. And it gives marketers and other stakeholders visibility and input into the process at a much earlier stage.

What is ProtoShare? It's a web-based tool that enables real-time collaboration with clickable wire framing.  After you set up a ProtoShare account, you take a first pass at architecture, create some wireframes of pages, and then invite the other teams to review and comment on it. Now you have the development team, the marketing team, the designers, executives, clients, and project managers all engaged and involved — whichever stakeholders make sense. 

1) It's rapid: Instead of spending three weeks pulling together information and maybe creating a wireframe or prototype, get started in a few hours.  Review and iterate on the prototype.  ProtoShare has a lot of functionality that makes the process easier.

2) It's collaborative:  Stakeholders and team members can view and comment on the prototype.  Multiple developers can work on the same prototype. This is really empowering for all involved, and vastly improves the process and the end result.

3) Design is added to the process:  Once you're satisfied with your prototype, upload design comps for side-by-side comparison.  Stakeholders can comment on the design comps as well.  This prevents the 'multiple authoritative document' problem that plagues the waterfall model.

4) It's iterative:  Is something not working?  Change it.  All of the information stays in one place.  Want to try a different approach?  Duplicate a section of your site and rearrange it. Try new layouts, navigation, and colors. Change is good.

For me, it's the best of both worlds. It's an easy way to minimize the work of designers and developers, while allowing both creativity and experimentation to emerge earlier in the process.

We used ProtoShare to develop ProtoShare, and the effect was revolutionary on our process and product.  We didn't eliminate meetings, but we had fewer, and they were shorter because everyone was on the same page when we got into the room. And because there was a single authoritative source for ideas, they stopped falling through the cracks. We released the product on time as design flaws and issues were exposed earlier and once programming started, there was very little thrash or rework.

I'd love to hear from SEOmoz readers about their development process issues and what they think about ProtoShare.  You can get a free trial at www.ProtoShare.com

Andrew Mottaz, is the CEO and co-founder of Site9, Inc. and is a Portland, Oregon based developer of collaborative web development software.