Catching up on my Bloglines backlog, I noticed John Battelle’s post on a data bill of rights. Last year, I spent some time thinking about how the BBC should deal with personal data, and came up with a similar list of principles. The BBC currently has only limited authentication or profiling services, but there was a desire to do more, so I started some research work on how we should approach it. I was influenced by Live/Work’s Loome project, and commissioned them to illustrate some scenarios. As a structure for these scenarios (and as a contribution to the BBC’s 2.0 project), last summer I came up with 6 principles that I thought should inform the BBC’s attitude to capturing, retaining and using personal data:

Its Your Data
Authentication and profiling services should start from the principle that the data belongs to the user, not the company providing the service. This is a design principle, not just a philosophy – the service should be designed with this assumption at its core, and every part of the service that handles users’ personal data should assume that ownership, and therefore control, of personal data lies with the user.

It should always be visible
Following on from the previous point, the service should be designed to let users easily see their data that is held in by the service, from profiles to clickstreams to UGC. This is more than just the data transparency that Batelle calls for – its overtly designing the service with the data on the outside. By this, I mean that there should be specific views within the service that are dedicated to foregrounding user data, and making it trivially easy for users to manipulate.

Using data in a service should be a tangible experience
This is tough to do online without getting in the way of a seamless user experience, but I feel that services should be designed that make users aware in a subtle but recognisable way that their data is being used to modify the service. With off-line transactions, there’s a tangible token – handing over a loyalty card, for example – that signifies the exchange of data. For most online services, there is an initial login that sets a cookie, then nothing – the user is rarely reminded that they are leaving a complex trail of data that is having a huge affect on the service they are using. I think there could be some lessons from gaming here, where users’ data – experience points, etc – are a tangible part of the experience, and are visualised in a way that enhances user awareness and even affords certain behaviours. How could we design this kind of tangibility into other services?

Data should be tradable between services
Once users are aware of their data as a tangible part of an online experience, then why not let them ‘play’ elements of their data trail as tokens in other services? This is not the kind of under-the-counter trading between service providers that happens in schemes like Nectar. In these schemes, the user can only spend an abstracted value generated by their overall profile. What if users could choose specific aspects of their data trail to personalise aspects of other services? For example – if you’re taking part in the BBC’s Springwatch survey, how could you use your uploaded data as a fliter for a book search on Amazon? Ok, that’s a crass example, but I like the idea of users being able to trade elements of their data for more than just money off services. I’d like to be able to use my profile from one service to make a better experience on another service.

Users’ data profiles should be faceted
Very few data-profiling services let users decide which aspects of their data trails are relevant to the service their using. Most services use a just-in-case approach to profiling – they want to know everything they can about you just in case they might be able to string the data together into something meaningful for you and the service you’re using. At best, your data trail identifies you as a member of some abstract marketing profile. In the age of the Long Tail, its our specific quirky tastes that are most interesting, not the generic qualities we share with the rest of the population. How can you design a service that uses a just-in-time approach to personal data? In other words, how can you design a service that prompts the use to give you just enough personal data to enhance the service, without having to hand over their entire data trail for you to sift through? I’m a Spurs fan, I live in Hove, I’ve got two kids, and I’m interested in medium-format photography. I shop online for groceries, have a huge mortgage, but I’ve never owned a car (but do belong to a car-club). I’ve been reading a lot of books about the history of sleight of hand lately, and am still sticking with Lost, but am expecting to be disappointed. I’m mildly addicted to terrible mobile phone games, particularly driving and golf sims. I’m inspired by Sophie Calle, Forced Entertainment and Richard Feynman. Not all these things are related, so how can I choose which facets of my profile I want to reveal to a service? How can the service give me feedback that helps me understand how useful different facets of my profile are? How can this be a fun and engaging part of the service, rather than a dull box-ticking exercise?

Your data should be disposable
Finally, it should be trivially easy for users to permanently delete as much or as little of their personal data as they want. Its their data, after all, so they should have complete control over it. The service should warn you that the experience might degrade if your data trail is erased, but the final call has to be with the user. And this goes for everything from click-trails through personal profiles to uploaded UGC – text, pictures, audio and video.

Whilst at the BBC, we started a couple of projects to explore what services designed on these principles might look like. I commissioned Live/Work to illustrate some scenarios, commissioned some research from Simon Willison on OpenID, and the PMOG work that Alice commissioned from Justin Hall is a really interesting experiment in creating game-like interfaces for data trails.

But this is barely scratching the surface. I think data-literacy is one of the most important issues in society at the moment, as it touches so many other issues, from surveillance to ID cards to identify theft and even bio-technology and genetics. There is an urgent need for more products and services that are built from principles like the ones above; that inform users about how their data is being captured and used, and empowers them to play an active part in these transactions.

John Battelle’s Data Bill of Rights is a good start, but we need actual projects to illustrate why these principles will lead to a better user experience. We need a founding set of principles, but we also need projects that develop data-literacy amongst users, so that they can demand better practise from the rest of the industry. Open ID seems to be a good base to support these kind of applications, so how about a design challenge based around OpenID? Anybody want to help set this up?

Continue reading →

I’m on the last of this year’s BBC Innovation Labs, and have been following the debate around the Economist’s crowd-sourcing project – Project Red Stripe. Project Red Stripe is a team of 6 people who have been given 6 months and �100k to come up with new business models for the Economist. As part of this, they’ve launched a web site to encourage ideas from the web community.

The Economist is a well established old media brand, so jumping with both feet into the trendy worlds of crowdsourcing and open innovation is bound to raise some interest, and not a few heckles.

It would be too easy to add more criticism to the heady brew they’re stirring up, but I do think its worth adding some pointers from what we’ve learnt at the BBC. About 3 years ago, Tom Loosemore and I developed an open innovation strategy for new media. This was in recognition of the amount of informal projects we were seeing out there that used BBC content as a base, and my own theoretical interest in the writings of Henry Chesbrough and Eric Von Hippel. As a result of this, we started a series of experiments – Backstage; Innovation Labs; Participate; and a project with the Arts and Humanities Research Council. I wouldn’t say we’re experts in this, but we’ve learnt a few things about how to run open innovation projects, and are still learning – one of the lessons of running open innovation projects is that once you’ve opened the door, you can’t close it again afterwards…

It might seem obvious, but the world outside your organisation isn’t one homogenous blob. The web is just a small sub-sector of this world, and that, in turn, isn’t one homogenous blob either. Its easy to just stick an invite for ideas online, but its a pretty crude way of starting a conversation, and leaves you open to getting crude responses back.

We identified a few generic communities that we wanted to build conversations with – Corporate Peers, Academics, Indies and Lead Users – and tried to think about the dynamics of each community. The projects we’ve designed are very different as a result.

Backstage is a very open, broad community. Its based more on ‘gifts’ (feeds to BBC content) than briefs, and we try to play the role of benign host, rather than catalyst, for the community. As a result, its very social, with a high traffic mailing list. The list includes BBC staff as well as lots of outside developers (about 3000 at last count), but we try not to have an official ‘BBC voice’ on the list – Ian and Matt, who run Backstage, very much speak for themselves. Some of the ideas are starting to be picked up by BBC commissioners, but its important that they’re owned by the individual developers, not us. In a way, Backstage is a way of listening as much as it is a product development pipeline. By engaging and supporting a community of interested developers, we find out about trends, and give our own development staff a way of talking about issues facing the BBC with peers.

Innovation Labs and the AHRC project are very different. Labs is aimed at indies, and has two goals – commissioning prototypes from pitched ideas, and broadening BBC commissioners’ knowledge of talented indies from across the UK. So Labs follows a more traditional ‘pipeline’ model – we start with commissioners setting briefs, which are more open strategic questions than specific “we need a website for XXX” briefs. We then do half-day sessions with the commissioners and interested digital media indies around the UK – we did 13 in Oct/Nov 2006 for this year’s Labs. This is a way of starting a dialogue about what we want from proposals, so that people aren’t pitching into a vacuum. The ideas can then be submitted via a form online, using a simple Needs/Approach/Benefits/Competition format (that we nicked from SRI). We then got the commissioners to score the ideas (there were 507 submitted this year), then picked the 10 best ideas in each region for the Lab itself. The ‘winners’ get paid to attend a 5 day residential Lab where they work with BBC and other external mentors to develop their idea. On the last day, they pitch to the commissioners, and they choose the ideas that get taken forward for further development.

Labs is very different from Backstage – its very task-focused (commissioning new innovations); marketed very directly at its target audience (digital indies across the UK) and based on setting the brief in advance, rather than leaving it open to see what people want to build. But this is because of the nature of its target community – indies want real commissioning opportunities, they want to understand what the BBC’s strategy is, and they want to meet the commissioners to build a working relationship. From our point of view, we want to find ideas at an early stage, we want to steer them towards our strategic needs, and we want to get to know the indie – their skills, expertise, etc – before collaborating on projects with them.

The AHRC and Participate projects are different again, but that might the subject for another post. But perhaps its worth summarising a few of the things that we’ve learnt, and that the Red Stripe team might want to consider:

Know who you want to have a conversation with – all the people who might have good ideas for your company are not the same. Have some strategy for starting different kinds of conversation about innovation with different communities

Know how your community talks to itself – do they have already existing mailing lists, meetings, social media sites? Do they prefer to be approached via email? blog posts? conferences? Do they exist as a homogenous group at all? (one of the issues with labs is that, unlike TV indies, digital media indies are really 5 or 6 different types of company, so very hard to address as a group)

Be clear about the structure of your conversation– are you offering an open-ended conversation? do you have a particular need or strategy that you want to discuss? what are the rewards? Is there an end-point, or is it an ongoing conversation?

Not everything has to be out in the open– some of our projects have elements that are public and in full view, and some that are private. For example, pretty much everything on Backstage is in the open – either on the site, the developers’ own sites, or on the mailing list archive. But the ideas submitted to Labs are not revealed online, as we think that many indies will be rightly wary of submitting their idea to an open forum, and we’d get more ideas submitted if that part of the project was private. During the Labs process itself, we let all the participating teams write about their projects on the Labs blog. Not all of them do – some do not want to be *that* public, and many are just too busy on the Labs – so its important to let the people who own the ideas decide what to reveal and what to keep private. Which brings me to…

Make open innovation networks IP-free spaces– on all of our projects, the participants retain all the IP on their ideas, whether its on the backstage list, on the Innovation Labs, or on the AHRC projects. I believe that this is essential for promoting a collaborative dialogue, and that innovation comes out of dialogue, not secret conversations. Also, to be honest, I think that in the spaces we’re dealing with (generally, ‘web 2.0’) there is a hell of a lot of duplication, and the real value of an idea is in its specific context and application, not the generic insight. So an approach which aims to grab a share of the IP for every idea in a conversation is unlikely to make any money defending that IP for financial gain in the future. These kind of ideas are just too loose and generic for that – we’re talking about business and service model innovation here, not product innovation. Far better to not try and own the IP, and instead encourage a collaborative conversation about how you can make the bloody thing actually happen. To do that, you need people to drop their defenses and actually trust you not to rip them off. Keep the lawyers to one side until you’ve got something that you can actually build.

On the Labs, we ask the participants to sign a contract that says they own all the IP on the ideas they develop over the 5 day workshop, but we ask for a 90 day ‘first look’ clause that means they can only talk to us about developing it for that period after the end of the Lab. After that, or if we decide earlier that we’re not interested, the team can take their idea anywhere else, and we’ve got no stake in it. I think this is fair, as it puts the onus on us at the BBC to decide whether we’re serious about taking the project further, and then come to an agreement about how we’re going to do this, rather than locking up all the IP just in case we might want to take a cut of the action later. This was a bit of a battle, as it was different from our standard terms, but it was worth fighting for.

Finally:

Open Innovation is an evolving process – we definitely have not got everything right, by all means. But having an open conversation means that people won’t hesitate to tell you where you’re going wrong, and will suggest improvements. The Red Stripe team are actually being pretty good at this, but are maybe still coming across as a bit precious. There are some interesting comments on their blog referring to other comments about the IP issues, but the tone is a little ‘us and them’ – they point to comments anonymously and ridicule a few submissions, which is huge mistake – if you’ve got a private submission process, don’t then decide to reveal a couple of ideas, even anonymously, to take the piss out of them. It looks like you’re treating your participants as idiots, and treating their ideas (and IP) with casual disdain. Overall, the blog has the tone of people speaking to a community, rather than being part of that community.

But again, I think this is partly the fault of the project being too general, and not specifically targetted at a community. They suffer the single biggest problem with some open innovation projects – not being tactical enough. By broadcasting their competition in an undifferentiated way, they’ve got to somehow have the conversation on a number of different fronts, to a bunch of different communities, using a spectrum of tones, vocabularies and styles. No wonder the only tone that they can use is a rather patrician, broadcast one. But still – its an admirable experiment, and I hope it generates more targetted, tactical projects in its wake that will help them avoid the slanging match of the wide open web.

Continue reading →