Posts
Traditionally, in my experience both in the private and public sector, the way to build a 'perfect' website has been considered to be;
invest a large quantity of resources, personnel and time at the start of the development process,
use this investment to build all the functionality that the developers can dream up, write all the content the communicators can think of and test it with audiences,
launch the 'perfect' website and hope it works, and then
replace the website (fixing most of the bits that failed) after 3-5 years by repeating the process again.
Personally I've never liked this approach. It places a lot of reliance on using past knowledge to guess future (organisational and audience) needs, involves investing a lot of resources upfront with limited ability to terminate or redirect projects until after they have failed and it also results in websites that degrade in effectiveness over time which can lead to progressively greater reputation and legal risks.
I'd like to see the process for developing a 'perfect' website reinvented. The new process must involve a low upfront cost, the ability to be flexible and agile to meet changing needs quickly and be capable of making a website more and more effective over time, improving reputation and reducing legal risks.
But how is it possible to achieve all these goals at once?
The answer is actually quite simple and well understood by successful entrepreneurs.
Rather than aiming for a perfect site on release day after an extended development period, the goal is to quickly build and launch a site that meets at least one critical audience need.
Once the site has been launched, ensure there are tools for monitoring how it is used and identifying user needs. Then progressively build extra functionality and write more content, guided primarily by the needs of your audience.
This approach ensures the site has enough value at launch to be successful, albeit in a more limited fashion than a 'kitchen sink' website (with more functionality at launch). It also ensures that the website grows progressively more useful and relevant to the audience you aim to serve.
In this way the site becomes increasingly perfect in a more realistic way - perfect for the audience who use it, rather than 'perfect' for the stakeholders who think they know what different audiences want.
We see this approach taken with all kinds of websites and products - from Apple's iPhones through to online services such as Gmail.
It's time to see more of this approach used with government websites as well.
After all - don't we want to create the 'perfect' website for our audiences' needs?
Friday, June 11, 2010
Subscribe to:
Post Comments (Atom)
Agile ftw.
ReplyDeleteI don't think Agile methods are the answer, because most people in the relevant communities of practice don't understand what that means yet.
ReplyDeleteIt would be far better to look at iterative design, in which you lay the building blocks for future enhancement and expansion in a way which doesn't create costly work down the road.
We could also go into the field of Service Design, but that's a whole new topic and has the same lack of understanding as Agile does.
Some of it is about language, some about financial models and a lot about legacy culture ("but that's how we've always done it")
ReplyDeleteIt is interesting to me how web development has solidified in some organisations, making it difficult to try different approaches (in order to get different, and better, outcomes).
Again this is an issue across the board - taking in both private and public sector organisations.