Built in 2 weeks – the Pendulum swings

Built in 2 weeks – the Pendulum swings

Q: How long should it take to develop a new digital product?

A: As long as it takes to get it right – within the limits of time, scope and budget (oh, and don’t forget the needs of the user… and the organisation)

I am a long-time believer in the User-Centred Design process. For me (and to most people in the business) this means (to a greater or lessor degree):

  • Gathering and understanding both user and business requirements
  • Developing personas, site maps, wireframes, content strategies and taxonomies
  • Creating and refining rapid prototypes for iterative testing with real people
  • Developing functional and technical specifications
  • Creative design and user feedback on design
  • Development and UAT
  • Launch – with the proviso there will be post-launch testing to ensure how you thought people would use your tools or transactions is in fact how they are using them in a live environment.

Of course it’s not just me who feels this way. Many commercial organisations, for whom web represents a significant means of generating revenue or reputation, follow these practices.

They know that there is value to be gained through increased revenue, decreased costs and customer satisfaction and retention when a digital product works well.

When it comes to developing digital products in government, there is a growing perception in some quarters that government isn’t capable of developing them in a cost effective, easily modifiable, user-centred way.

To counterbalance this issue, the development community holds hack days (i.e. Rewired State: National Hack the Government Day held at the Guardian) where they get together developers and data and spend a day hacking together solutions to address user needs.

Now, let me first say that I am a firm believer in open crowd-sourcing of ideas and solutions, allowing for innovation to occur by supplying people with data, inspiration and space, and looking for truly inspired ideas to float to the surface.

Where my optimism changes to concern is when the proverbial pendulum swings the other way.

To their advantage, the external developers have decreased development time (in most cases with simple services that do 1 or 2 simple things) and cost. Do they have durable, usable, sustainable services? Quite probably not. They have somewhat working prototypes. But this is not to say they couldn’t be developed into something sustainable.

It’s not the speed or cost that concern me.

It’s the quality.

In many cases, both the government and developer community approaches fail to utilise a proper UCD process. Neither will readily admit this.

Rushing the process and slashing the budget won’t provide a better service…

…just a more easily disposable one.

I would like to see more digital product development in government take into account the sometimes quite disparate needs of the organisation and the users – and the potential size of the audience.

This will allow for the scaling of robustness and a focus on quality – after all, if a site has 15 million users but only 2% of that audience are potential users of a specific digital product then the scale of product development should take this into account and a level of quality should be ascertained at the outset.

Ideally, I would like to see more collaboration and less mud-slinging between government and external developers. It creates division, not collaboration.

I think there are great people on both sides who really do want to develop with the best possible interests of users in mind. And together, I think that the outputs of such collaboration will ultimately lead to better digital products for everyone.

Recommended reading: The Inmates are Running the Asylum by Alan Cooper.