The Web was Build for Continuous Delivery

Apr
2
2013

Hundreds of cupcakes all the same from Edge of the Web 2011 conference

Interestingly Jared M. Spool waxed on recently about slowing down and changing the design process, from one large change to just hundreds of small testable alterations. Now this is nothing really that new.

In the early days of the web (1995 to 1997) I remember it was all about making small changes, validating them.

You know the drill make small changes, implement, test response, respond to test. These can be from changing a typeface, moving a heading, changing the location and size of a button.

Seeing what worked for your audience and what didn’t, sometimes you rolled back a change, other times we just tweaked the change a little to gather a greater improvement.

Advantages

Overall this staged approach to designing and presenting a web site allowed for a:

  • Very rapid response to influencing forces
  • Defined focus on the changes being made
  • Ease of validation of changes
  • Ease of customer acceptance

A change happened over weeks or even months not overnight. Most of the time users never noticed.

Somewhere along the way we lost sight of this and started making websites like print brochures and software releases.

Guess we applied the wrong processes that we knew to the (then) new medium.

Still need to Plan

Only issue with the continuous approach is that you have to plan and prioritize, and continuously ensure you plan is still valid with your customers. Without this you’ll just be rolling out outdated or ill timed aspect to your product.

Remember all this is pointless if you don’t have your customers involved in the process.

Of course if you wanted to be really trendy then it’s just all about Agile based Continuous Delivery. Which really isn’t anything new in the web industry.

But in reality it’s all just part of process in stopping the constant redesign cycle.

Tags: , , , ,

Looks like there is no conversation here yet, why not start one.