Built in 2 weeks – the Pendulum swings4
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.
I think you have a point there, Brian. I suppose there’s an inevitable tension because in government terms, UCD generally means thorough, slow and relatively expensive in the short term. Some external developers (and plenty of non-technical colleagues within government) find this simply frustrating – they know what they’d want, so why not just build the damn thing and see if it works? When it does, it’s easy to point to agility, speed and low cost. And when it doesn’t, the sunk costs are minimal, so it’s easier to move to try something else instead.
I suppose the happy medium for most projects is in light touch UCD: workshopped personas, guerilla usability testing, quick-and-dirty user feedback surveys. The number one problem I’m seeing is the headlong rush into digital projects without even a written down set of goals, audiences, risks or indicators of success (and I’m as guilty as any in this respect). Without being prepared to take an hour to reflect and agree on these as a team, it’s undoubtedly hard to deliver a coherent, let alone usable, output.
Hi Brian. You seem to be suggesting that some of these external developers (e.g. those of us who went to Rewired State) know nothing (or very little) of these software development best practices of which you speak.
This is the second time in as many days that I’ve had feedback from a relatively official channel indicating that the skills of the people who went to Rewired State do not overlap with those required to implement scalable long term solutions to the problems that were addressed. I find myself wondering why a bunch of interested and talented people with expertise in developing, delivering and supporting online software are not being engaged in a more proactive manner.
Knocking up a demo on a Saturday afternoon does not require the same attention to detail that you need to see a project through from start to finish, but let’s not forget that most of us are web professionals and develop professional software for a living. Designing, building and supporting great products is what many of us do best, and we wouldn’t approach a longer term project in the manner that we did that Saturday.
Where are your concerns over quality coming from? Can you be specific?
Steph has addressed this in the second half of his post when he states:
“The number one problem I’m seeing is the headlong rush into digital projects without even a written down set of goals…”
The issue, as I see it, is that there are individuals who will use the efforts of a hack day to try and push projects to move faster than they should – it’s taking the spirit of a “hack day” and perverting it by attempting to apply that rapid development mentality to projects that require a more UCD oriented approach.
I would ask – are a lot of these recent government microsite launches – developed in a week or two – addressing the needs of users or gratifying a personal need to feel some issue is being addressed?
Hey Brian! You stated “Do they have durable, usable, sustainable services? Quite probably not.” Those of us who have developed software for the aerospace industry often find it difficult to comprehend how non-aerospace software developers have been able to create such a huge body of code. Well, there is a good reason for this: if the industry one writes software for does not absolutely require very high standards for design, implementation, and testing of software then the quality (durability, usability, sustainability) of the software (and hence the end product) is almost always very poor. Nobody else (except the nuclear and medical industries) can afford to compete if they take on the expense of very high software quality (not to mention the impact of the inevitable “delayed release to market”). I love hacking out code – but hacking is really only useful as a tool to examine the feasibility of ideas. Too often these hacks morph into immature, unstable released products. So… until the consumers of software start rejecting poor solutions, I believe the chaos will inevitably continue.