Protoshare: A software for developing Best practice of website development process flow

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.

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.