Enter a search term such as “mobile analytics” or browse our content using the filters above.
That’s not only a poor Scrabble score but we also couldn’t find any results matching
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
I’ve been dealing with a few clients of late, most of which have heard the ruckus around this newfangled Web 2.0 thing, and most of which want to do something Web 2.0 with their projects. Some want to implement blogs, others are interested in Wiki’s and podcasting, and surprisingly most of them want some Ajax features. The list goes on.
That’s really good because I’m always happy to talk to people about getting more out of the web, specifically around creating better and more valuable user experiences, but the problem I have (and which I communicate) is that Web 2.0 doesn’t just stop at implementing a blog engine, podcasts, a Wiki or Ajax.
When you get down to the nitty gritty of things, the above technologies are the way in which we create a better or richer user experience, so that the user has a better affinity for our product or service but also so that we are able to better interact with them, or so that they are able to better interact with others on the site.
The technology itself is ambivalent, it doesn’t care what it’s used for or how it’s implemented. So, as a web practitioner it’s my job to remind the clients that it’s quite possible to implement said cool new feature, but what are you going to do with it afterwards?
This situation reminds me of the good old early days when clients asked you to build a web site for them, and then also expected you to write the copy for the web site, even though you didn’t know enough about their business or industry to do the job justice.
Similarly, when implementing these new Web 2.0 features, most of which are becoming easier and more mainstream by the day, clients and practitioners need to bear in mind that both the rolling out and post-implementation work need to be agile in nature, if you’re going to get the best from these new technologies promise.
Taking six weeks to write up a 200 page functional specification document isn’t going to win you much affection from your users, when they’ve already gone to the competition because they were faster, leaner and meaner, implementing the same functionality quicker than you to attract new users (including yours).
Likewise, taking 2 weeks to respond to a customer comment on your blog about why your new product doesn’t work in whatever circumstance isn’t going to win you much affection – rather it’s going to create a negative word of mouth spiral that you don’t want.
Neither will launching a new Wiki to document your product more comprehensively than your instruction manual does (think user generated content here), then spending a week adding some initial content, then never touching it again.
The bottom line is that any strategy which plans to engage users and draw them into a positive word of mouth spiral, whatever the technology underneath, must be implemented as quickly as possible and with as much involvement from users as possible. You must also have a follow-through plan that goes beyond the short term. Assigning someone responsibility with regular update reports is probably a good idea too.