It is no secret that the web evolves, adapts, introduces and retires technologies faster than you can throw your craft beer at. I'm never too sure how fast it moves in comparison to other industries, however from my own experience I can certainly vouch that the tools I use, skills I exploit and methodologies I endorse never remain consistent; they have always been tweaked or dismantled to improve the products and projects I am involved in.

So if we are working within an industry that has the capability to adapt at such a pace, why are so many of us endorsing workflows that are the antithesis of such versatility? The waterfall approach has long been the prominent approach to web production over the years, yet in my opinion it has become far more of a square peg in a round hole in which it struggles to suitably mould to the modern web; a web where it is now dangerous to try and predict what device or internet speed a user will be entertaining.

How familiar does this sound:

1. Client kick-off meeting
2. Design high fidelity comp to get signed off
3. Pass comp to developer to cut up and build
4. Client hand over meeting
5. Snag list

Perhaps a simplification but the premise remains: a waterfall approach focuses on the entire project from a start-to-finish perspective which in itself can cause a magnitude of issues and friction between a team and a client. Why try and design and build everything from day one when it is unlikely you will ever have all the content and ideas through by that point? You may think you know exactly what you want/need to do but it is rarely the case, and no one involved in a project should ever be discouraged in coming up with new ideas and approaches at any point during a project timeline.

An alternative

Instead of giving ourselves such headaches I believe the answer is already out there and should be something I think all developers and designers should be encompassing: working agile. In comparison to the waterfall approach, agile focuses on individual areas of a project and works on constantly iterating them during weekly sprints. Once a sprint is over, a sprint review will be organised with the projects stakeholders and a prototype of the product will be presented allowing for rapid feedback and deliberation that can guide the project's future path. So for arguments sake, an agile workflow may look something like this:

1. Client kick-off meeting
2. Scrum (deliberating with your team internally)
3. Sprint
4. Sprint review (deliberating with stakeholders)
5. Repeat

Not everything you show to the client each week will be perfect, but each time they see it, it will be clear how the prototype has developed and evolved

You may be asking yourself, "but Josh, what if something takes longer than a week to build?" and you would be asking a good question. It remains true that some projects involve tasks that take considerably longer than a weeks-worth of work. However a sprint should not be viewed upon as linear process. You may well be working on the same template or piece of code for 3 sprints but within each sprint the focus will change depending on the feedback and research you obtain in each sprint review; that way, any issues or problems can be immediately dealt with. The beauty of agile is that it not everything you show to the client each week will be perfect, but each time they see it, it will be clear how the prototype has developed and evolved, allowing people outside of the development team to feel a part of the projects progression.

No longer should you have a snag list longer than your arm at the end of a project as those niggles or new ideas that your client came up with 3 weeks into a project (if appropriate) can be heard, actioned and refactored as soon as they crop up. Not only pleasing the client who is a human remember and likes to be heard, as well as your team who no longer have to become jaded at the task of adapting a design/development that doesn't fit this new change, which is notoriously content!

A byproduct of working towards such immediate feedback also aids you and your team leaving your egos at the door by allowing decisions to be questioned and elements to be changed. Feedback is so fundamental to a projects success, it is a no brainier that the more interaction you get from real users, whether through usability testing or feedback Q&As, the more rounded the project will be. It also keeps you on your toes, especially in terms of design, as discussion flows both ways and explaining decisions to a client backed up with sound justifications prompts everyone to think objectively, not subjectively - a good place to be for any project.