Developing tools for open journalism Design entire systems, not individual tools, and avoid reinventing the wheel, says Martin Belam

The Guardian (blog) 
What we are able to do digitally is ultimately shaped by the tools that are available to us, and open journalism is no exception.
Over the last few years I've had a hand in designing more than my fair share of tools intended to elicit a response from the audience – here are four key things I've learned along the way.

Give users achievable goals

One example that is often cited as "crowd-sourced" open journalism is the Guardian's MPs Expenses app.
When the UK Parliament released redacted versions of MPs expenses, the Guardian invited readers to trawl through and note anything of interest worth investigating by a 'proper' journalist – a chart on the front of the app showed the progress made.

The Guardian's MPs Expenses app We quickly learned that actually the chart was a bit of a disincentive. It showed the user how even ploughing through a hundred documents was barely going to make a difference. When Parliament released a second, admittedly much smaller, batch of documents, we changed the design of the tool.
A redesign of the Guardian's MPs Expenses app The documents were broken down into much more achievable tasks – by party or by members of the shadow cabinet – and the users whizzed through them. Since it was easier to see that you could achieve a goal, the rate of processing the documents increased.

Prepare for volume (and lack of it)

Often the biggest problem for traditional media organisations is not in designing the tool that will handle open journalism, but in processing the volume of potential submissions.
Last year the Guardian's Book Blog had a series called Summer Readings where staff recommended a book they had read during a particularly memorable summer.
It was perfect for opening up to audience participation – if you could solve the problem of sifting through the submissions. A smaller book blog might get a handful of submissions, and actually be able to publish them very quickly. The Guardian would still need to employ a more expensive production process including sub-editing and checking for potential plagiarism.
You also need to design for a lack of engagement. I am on an advisory panel for one of London's museums and they were asking us about the "worst case scenario" for a project they are running that requires user-generated content.
One of the panel members replied simply with one word – "apathy". You need to think carefully about how you populate a service so that every user who comes to it feels like they are standing on the shoulders of giants, rather than watching tumbleweed blow past.

People are unpredictable

People never do what you expect them to. As Seth Godin just observed:

Whatever we build gets misunderstood, corroded and chronic, and it happens quickly and in unpredictable ways. That's one reason why the web is so fascinating – it's a collision between the analytic world of code and wet world of people. No software design survives a collision with the user.

A typical example of this is @replying and #hashtags on Twitter. Although both of those activities are now actively supported by the service interface, both of them were originally improvised by users trying to work around the shortcomings of a system that didn't quite allow them to address non-followers directly, or didn't quite allow them to build an impromptu community around a topic of interest or an event.
If you design a tool, you inevitably design possibilities for the tool to be used and misused.

Don't overlook existing tools

Beware of reinventing the wheel. I recently saw infogr.am criticised on Twitter by Tom Royal for "inventing the spreadsheet".
If you are thinking about building a photo-uploading tool, think about whether you can achieve 90% of what you want to do for free with a Flickr group.
If you are asked to build a showcase for user-generated video, can you do it just as easily using a Vimeo channel? And don't forget that a lot of the interactivity on radio and television still relies on people emailing and texting in.

Design systems, not tools

In that light, you begin to realise that whenever you start designing a 'tool' for open journalism, you actually need to be designing a 'system'.
I find it really helpful not just to draw diagrams of what will appear on 'page x', but to draw out entire system maps. For the tool to work, it needs to fit into a system that includes the original call-to-action, the user response, and the way that the journalist or editor is going to curate and publish the outcome.
Martin Belam runs the user experience team at the Guardian, working across its award-winning website, mobile platforms and Facebook app. He blogs about user experience, journalism and digital media at currybet.net – follow him on Twitter @currybet
http://www.guardian.co.uk/media-network/media-network-blog/2012/jun/08/open-journalism-tools-developing-apps?newsfeed=true
This content is brought to you by Guardian Professional. To get more articles like this direct to your inbox, sign up free to become a member of the Guardian Media Network.