Discovering discovery

Not enough people actually begin at the beginning.

Often when I meet teams working on service transformation, or digital change projects, I find that they’ve begun somewhere else. Perhaps their work began when someone decided the organisation should be using a particular system, so they’re busy trying to implement that, or someone thought a particular process should be put online, so that’s what they’re doing. They’ve been presented with a solution and told to make it work.?

And all too often the people dictating those solutions are being driven largely by internal factors – the need to make short term savings, a contract coming to an end, a budget to spend by the end of the year, a boss to impress.

This tends to result in teams who are doing their best, but are feeling rather put-upon and disempowered; teams who find that the priorities and targets aren’t entirely clear, or that they keep shifting; teams who can’t really explain the purpose of what they are working on, or who it is for, or what will happen to it after they’ve finished their particular project.

Worse still, the people who ultimately have to use the product or service are also likely to be unhappy – faced with an experience that doesn’t really work for them, because it’s based on managerial assumptions, or because it’s had so many things bolted on along the way that it’s become unusable.

The art of discovery

In my experience the best way to avoid ending up in this painful and often expensive mess is to go through a ‘discovery’ process upfront. The time you spend on this, whether it’s months, weeks or days, will be time extremely well spent. It will help you to focus on your users and their needs, and to come up with realistic plans that the whole team can buy in to.

As far as I’m aware there’s no fixed formula for ‘discovery’ and although other people (like GDS and the Design Council) agree that it’s valuable there aren’t many detailed templates or guides out there. I’ve therefore developed an approach that makes sense to me, and (more importantly) to the teams I’ve worked with.  It isn’t possible to cover all the detail here in a single post, but I’ll share some of the main principles and steps.

It’s as easy as 1,2,3

The way I see it, there are three stages within discovery:

  1. Learning (about your users, and about business drivers and constraints)
  2. Sketching (generating and testing ideas)
  3. Refining & planning (prioritising and working out what to take into delivery)

I tend to present these as a diamond (similar to the Design Council’s) as this helps to illustrate that the team are opening up their thinking before focusing in on specific solutions and plans. (And it really is important that it’s a team going through this… more on this below.)

The main stages of discovery
The diamond of discovery

If you’re tight on time –  and provided you’ve got access to the right data, research and people – you can rattle through this in a week or two if you really have to. But if you’re working on something new or complex, or if you need to do some fresh user research then things might take a little longer. (The government Service Design Manual recommends 4-8 weeks of discovery.)

Who’s in the team?

There’s no one answer to this, but ideally you need to involve:

  • Someone to keep things moving along. In an ideal world this is the product or service “owner” e.g. in places where you have specific Product Managers. However,  this could also be a project manager supporting the service owner, or it might even be an external facilitator. The most important thing is that they understand the purpose of discovery and can bring together the right people in the right setting to keep things moving in a productive direction.
  • People with real insight and experience – about your users and their needs, about the business and its priorities and constraints, about the technology context and possibilities. A well run discovery process will tap in to all of this and help everyone to share what they know and work towards solutions they can all support. (Some of these people might just come along to certain workshops rather than being involved on a day to day basis.)  What you don’t want is observers and passengers – if someone doesn’t have relevant insight or experience to share then they shouldn’t be in the room!
  • The people who will be delivering the solution. Often these will be some of the people with the best insight and experience – so we’ve already got them covered.  You won’t be able to invite all the people who will be involved with delivery, but you definitely want the key areas represented. Often this will be an internal tech lead, perhaps your lead user experience person, and someone representing the business and/or customer service teams who will be involved with running the service. If your delivery is largely outsourced then you’ll need to involve your suppliers along the way to bring insight about how their world works – but be wary of letting them dictate solutions, particularly if you’ll be putting things out to tender.

Often the people brought together during discovery might never have met or spoken before, even though they’re all involved in aspects of designing and delivering a service. Discovery helps to cut through internal silos and bring together a group of people who can look at a service holistically and develop a shared sense of purpose and ownership.

Nitty gritty

There are various workshops and activities I use to take teams through discovery. These involve everyone in the team, a wall, and a lot of post-it notes and marker pens. Discovery is driven by conversation rather than documentation, so the approach needs to get people talking and thinking and sketching and asking questions. The wall becomes a living repository of all of this, and a reference point for the team.

Two teams mapping user needs
Two teams mapping user needs

The main events tend to be:

  • What do we know?workshop This sets the scene and gets people sharing existing headline data, research and insights. I tend to cluster things in a few key areas: User and their needs, Business context (drivers, targets, constraints), Tech and delivery context, and sometimes also Process and workflow context.  By the end of the workshop everyone has a shared understanding of the context they’re working in, and some of the problems they might want to solve. They’ve also identified and prioritised gaps in their knowledge to focus on filling in the next few days.
  • User needs mapping workshop This helps the whole team to walk in the shoes of their users, identifying needs from trigger to goal. It depends on having access to real insight about those users. I find it helps to start by building an empathy map of each prioritised user group, and giving them a name. These names are then a handy shorthand throughout the process, as everyone knows the set of characteristics and needs summed up by “Anita” or “Bill”.
  • Sketching workshop The team start to identify possible solutions to meet the needs of their external and internal users. I build things up in layers, starting with the user needs at the top, and ending with candidate solutions at the bottom.

In each case the workshops are designed to trigger the thinking, talking, researching, sketching, testing and planning that the team then go off and do. i.e. the real work happens in-between the workshops, ideally facilitated by daily stand ups in front of the wall.  This also presents lots of opportunities for other interested people to see how things are going – using the “show don’t tell” approach to governance and comms.

One of the hardest things is stopping people jumping to solutions too early. It’s really important to stick with needs, data and evidence until you’ve really understand the problem you’re trying to solve, and the outcomes you’re seeking to achieve – and only then get in to sketching solutions. You’ll be surprised at how many options you can come up with by doing this, giving you lots to then prioritise and potentially iterate – one “why” and many “whats”. Discovery can give you the foundations for a whole roadmap of service improvement.

So is this ‘Agile’?

I believe that a discovery process is valuable regardless of the approach you then take to delivery.

If you are going to be using an agile approach to delivery then a good discovery process can produce a prioritised backlog and a roadmap. (This could be a backlog of detailed user stories or perhaps just a list of epics to refine later, depending on the time available and the preferences of the team).

If your solution is going to be largely (or partly) delivered by suppliers you’re likely to be a much more confident and discerning client if you’ve been through discovery. You’ll be able to articulate your requirements in terms of the problems you want solved, and the outcomes you want to achieve, and you’ll be able to assess the solutions they propose based on what you’ve learnt in discovery.

And if you’re really keen you may even find yourself applying the principles of discovery to small everyday tasks too. If someone starts a conversation by stating “what we need is…” then maybe push back and ask “what’s the problem we’re trying to solve? What evidence do we have? How will we know we’ve been successful?”.  We all have a tendency to jump to solutions and to make assumptions – but if we do that, we’re not really beginning at the beginning. And as Maria once taught us – that’s a very good place to start.

Julie Andrews telling it like it is
Julie Andrews telling it like it is

If you’d like to have a chat about the detail of discovery, and how it might work in your organisation, then do get in touch via the comments below, or via my About page. 

Devo-digital

Could the devolution of power to cities and regions help super-charge the work on local digital services?

As I write this post the debate around the devolution of powers to UK cities and regions is

Bristol at night
With thanks to https://www.flickr.com/photos/lukeas09/

hotting up. No doubt by the time you read it the details will have changed – but it seems highly likely that whoever is running the country after May 2015 they’ll be conceding some powers and funding, or fundraising opportunities, to some of our larger cities and regions (“metros” as the City Growth Commission calls them).

Much has already been said about the approaches or models that might help deliver high quality digital services across local government – with “one site to rule them all” at one end of the spectrum, and voluntary standards at the other.

Much as I admire and support the great work being done by practitioners like LocalGovDigtal, my view is that bottom-up voluntary best practice isn’t going to be enough. Even if I believed that this alone would get us to consistently good and affordable services eventually (which I don’t), we simply don’t have the time to find out – the funding situation is too acute, and the expectations of citizens accustomed to interacting 24/7 online are already raised too high.

There are also far too many chief execs, service directors and elected members who don’t yet understand the need for digitally enabled service redesign (including assisted digital), or the scale of the opportunity, or the extent of culture change required to bring it about.

We need to get their attention.

Even amongst the more engaged there seems to be a leadership vacuum. At events I’ve been to with representation from DCLG, the LGA, and Solace as well as execs and councillors from local authorities, everyone has been happy to agree that standards need to be raised, skills developed, opportunities seized, and that some leadership is needed… But no one has been prepared to step forward to lead, or even to suggest who might.

In central government, when GDS was created, it wasn’t enough to have a team of experienced people, or to say what good looked like, or even to show it via Alphas and exemplars – the new digital standards had to be made mandatory, and tied to access to funding (specifically spend controls). Yes, there’s a nice juicy carrot in positive user feedback and improved performance indicators (including savings), and ideally this would be enough to incentivise change, but I don’t think this alone will bring about the shift needed. I suspect we also need some stick.

I believe we need a new mandate or settlement or hard incentive to accelerate the pace of digitally-enabled change across local government – and that perhaps the devolution of powers to cities and regions might provide that opportunity.

Imagine a devolution deal which insisted that x% should be spent on digitally enabled service redesign, to an agreed set of standards and even a timetable. Or, if that degree of ring-fencing is too strong, how about mandating standards or expectations with targets and metrics attached, regardless of spend? In July Ed Miliband suggested that his version of devolution would come with “checks and balances”, with the introduction of local public accounts committees and the requirement to publish performance data. If this approach gets developed I’d want to see digital and service design standards as part of it.

Sticks aside, stronger cities and regions could also lead the development and sharing of digital expertise. Some commentators and practitioners are, probably rightly, sceptical of a central (London based) digital team for local government – but what if there were centres of excellence in each of the large cities, each perhaps running digital academies or events for council staff in the surrounding authorities?  Would it also be more acceptable if the guardians of digital standards were up the road, rather than inside the M25?

So, do I think we need national standards for service design and digital? Yes I do. Do I think these need to be mandated in order to be truly effective? Yes. Does this mean a central team in London taking control? No, it needn’t. I think we need many centres of excellence, not just one, and I’m hoping that if we get devolved cities they might help lead the way.

GDS for local? A shopping list, not a monolith.

There’s been a lot of renewed chat recently (see below) about  “a GDS for local government’ or “GOV.UK for local goverment” but I’m curious about what people really mean when they use these terms. What is it that “GDS” represents in these conversations – a central team of specialists? A set of standards? A publishing platform? A mandate? All of the above?

I’ve only spent a few months looking into and working with local government, so my thoughts are still forming and I still have much to learn and observe. However, even with that caveat, I’m already convinced that the current approach – where over 300 authorities spend their increasingly scarce resources independently trying to meet the same set of needs and solve the same set of problems – is fairly bonkers. Particularly when in many cases the solutions they end up with are way more expensive and less flexible than they should be. Oh, and not great for their customers either.

This isn’t sensible, and it isn’t sustainable. It’s also not fair on the amazing people in local government who know it isn’t ideal but who don’t have the tools, or support, or budgets to change things. It’s one of the things that got me out of GDS and involved with this in the first place.

Being a user-centred agile kinda girl I’m not comfortable jumping to solutions before I fully understand the problem, but I’m also not comfortable with the way that “a local GDS” and “GOV.UK” are being used – sometimes interchangeably – as shorthand for some kind of fairly abstract all powerful centralised solution, something “monolithic“. (With apologies for Rob for singling this out!)

It may well be that some of the approaches GDS have taken, and some of the things they have delivered, should form part of how local government delivers information and services in the future. But that covers a lot of different activities and products. Maybe we should think about which of those might be useful in the context of local government – to move from the abstract concept of “a GDS” into the constituent parts.

So as a starter for ten – if there were a shopping list based on the types of things GDS is currently providing for central government, which would you be buying into for local government? And who might be providing them?  That list might include these kinds of things (illustrated with central gov examples for now):

This isn’t a complete list, but the point I’m trying to make is that GDS represents many things, some of which would be more difficult or controversial than others to apply across local government.

I’m interested in having a more practical conversation – one based on the needs to be met and the opportunities to be realised, and only then the models and structures and teams and technologies that might best deliver against those.  If you start by talking about the governance and politics you may end up in an unhappy place. If  you start with the problem you are trying to solve, and think about it in manageable chunks, you can end up achieving something extraordinary.

(Some notable recent contributions from Ben Welby, DXW, Phil Rumens, Rob Miller and Socitm. Also interesting to see the programme of events, training etc that DCLG are offering this year.)

 

Post-launch survival tips

On Friday I popped in to see the fantastic team at FutureLearn to congratulate them on launching their new MOOC platform. They invited me to share some tips on post-launch survival so I came up with my top 5.  This is my personal take, not anything official from GDS, but I do use government examples because that’s what I’m involved with at the moment. They’re pretty straight forward (and the FutureLearn team seemed to have most of this nailed already!) but here they are in case they are useful to anyone else…

1. Look after yourselves and each other.Look after yourselves
(Human bugs are more difficult and expensive to fix than bugs in your code).

We all tend to over-do it in the run up to a launch or big release, but you can’t survive forever on short nights, adrenalin and donuts.  Post-launch you’re responsible for running a live service and that is a long game, not a sprint. Most things CAN wait until tomorrow – especially if you’ve got good processes in place to monitor and resolve issues.  Happy rested people are more likely to come up with creative solutions anyway – and if “the unit of delivery is the team” you’re all going to suffer if one of you is suffering. If you’ve lost your sense of humour that’s probably a sign that you need to take a break!

Respect the process2. Respect the process.

Actually, respect YOUR process – you should own it (as a team) you should review it (as a team) and you can iterate it (as a team) – but always respect it. This could apply to the process for adding things to the backlog, or for triaging user feedback, or for responding to stakeholders or Tweets or the press. When things get hectic you all need to trust that the processes you’ve agreed will be followed, and that no one will be going off piste… something that is likely to generate more work and a lot of noise.

3. Know your story.Know your story
(And publish it!)

Everyone in the team should know or have access to the story you’re telling about the product you’ve just launched/your latest release.  Ideally this should be published -partly because it’s more efficient to say it once and link to it than to answer the same question over & over again – but also because you’ll be part of a conversation and the people who engage will give you valuable feedback.  (At GDS we famously blog about pretty much everything, or publish things as part of the Service Design Manual.) The same principle can apply internally, for things you’re not yet ready to share publicly. You can use a Google doc or a wiki page or another shared place to publish the latest on evolving thinking – that way everyone can take a look and if you need to get together for a discussion you can, rather than having distracting and repetitive conversations going on all the time.

IMG_21264. Use your data.

This should be pretty self evident, but the data you have about your users and how they are using and responding to your product should be informing the work you’re doing to iterate and improve, and also be a big part of the story you’re telling – internally and externally.  This is likely to be a mix of the usage data you’re capturing, but also insights from user research and feedback.  Decisions that are based on data are usually better decisions, and easier to explain and to defend (if need be!).  Have a think before you launch/release about the questions you’re going to want answers to post-launch. Are you set up to capture the relevant data? Do you know where to look for it or to to ask when you need it?

5. Manage your stakeholders.IMG_2127

Just as you’ll have processes in place to manage feedback from your users, so you’ll want to have processes in place for interacting with your stakeholders. If you don’t it could get noisy and frustrating for all involved. Be proactive and prepared. Let them know in advance the most effective channels for feedback, and the best way to get the latest info. Where should they look? What can they expect?  Ideally have someone in the team focused on managing this, to make sure you’re hearing the priority suggestions or concerns, and that your stakeholders are kept well informed. The amazing @jennijjmoss and @ElisseJones definitely showed us the way on this one at GDS.

Girl talk

October 16th 2012 was Ada Lovelace day and it prompted a small flurry of articles, posts and podcasts bemoaning the lack of women in tech and wondering what could or should be done about it.

Ada Lovelace by Alfred Edward Chalon
Ada Lovelace by Alfred Edward Chalon

I didn’t join in at the time – perhaps because I was rather busy launching GOV.UK that night – I and many fabulous and talented colleagues, male and female. We reached over a million people on the first day and made it simpler, clearer and faster for them to interact with the UK government.

I could perhaps claim that being the proud if exhausted Product Manager of that product, on that day, was a more fitting tribute to Ms Lovelace than any tweet or comment or turn at a women’s networking event.

But that would be to suggest that, in the midst of all the hard work and euphoria, I was thinking about Ada, or even conscious of being “a woman in technology”.  And if I’m honest, I wasn’t.

What I was conscious of was everything that can be achieved when passionate, creative, experienced, proactive people come together and listen to and respect each others’ views and skills – regardless of their gender.

So it is only this evening that I’ve finally found and read those articles, and looked for those networks, and that’s because I went to listen to Martha Lane Fox speaking at a Nesta event and the subject came up. Again. In fact, I even tweeted Martha’s comment that women in tech should “Stand up, lean in & shout!” and in doing so I realised I’d sort of joined in, and perhaps it was time to form an opinion.

So here is my opening salvo.

What strikes me is that the discussion too often seems to centre around the relationship between girls and computers and how they need to be encouraged to “do IT “at school, or to write code – as if this alone will redress the gender imbalance at the top of tech companies and in the tech community as a whole. (The Indy took a broader view, but only just).

But surely computers and code are now a means to an end, many ends in fact – digital technology is about connecting people, and understanding their needs, and communicating, and being creative, and solving problems, and collaborating, and creating products that people want to use.

And, unless I’m missing something, I think girls tend to be quite good at those things – in fact possibly better than boys at some of them (I have no data – I’m just jumping on the gender stereotype bandwagon! But I also speak as a woman with a degree in English Literature who’s never written code, but who’s been able to work on some pretty big digital projects).

The computers and the code are the tools that make all of this possible, and yes, we absolutely do need talented people who know how to wield them skilfully – be they male or female. But TV is about more than cameras, newspapers are about more then typesetting, and creating great digital products and experiences is about more than computers.

So maybe, in 2013, we could talk less about IT and more about digital products, less about coding and more about understanding the needs of real people, less about “geeks” and more about creativity. And perhaps if we did that we might do better at attracting the full spectrum of people who will show us where digital technology can really take us… regardless of their gender.

Changing the world, 1% at a time

Last week I agreed to take part in a “global co-creation event” which would involve “running with the cheetahs” and meeting “fast moving changemakers”.  No, I had no idea what any of that meant either, but there were some enthusiastic Dutch people behind it, and it involved spending a day in the excellent Hub Islington so I thought I’d give it a go.

The gang behind the event run the 1% Club, which they define as:One Percent Club logo

The online platform that connects people who have smart ideas with people, money and knowledge around the world.

I was interested in the suggestion that people could lend their professional skills to projects in developing countries via a digital network, so was disappointed to find that there only ever seem to be 5 or so projects asking for that kind of support on the site. I’ve since realised that these are only the projects posted in English, with another 40 or so in Dutch, but even so the requests for funding seem to outnumber those asking for skills by a factor of 6 to 1.

The 1% Event, however, is all about taking this principle of donating skills and making a day of it.  They had identified 11 development projects from around the globe, and created 11 teams to tackle them.  Or at least, to spend a few hours trying to tackle them.  Four of the teams were in Amsterdam, with others in London, Nairobi, Cape Town, Kampala, Cairo, Buea and Ramallah.

I think the concept that underpins both the site and the event is an interesting one, and worth exploring,  but to my mind they fell down a bit on the execution.

The 8 locations were all connected via live streams and Skype, which was ambitious, and sometimes brilliant, but often unreliable.  There was also quite a bit of time spent on pre-amble, and even group singing (in Amsterdam… watched in bewilderment from London!), before things really got going and we were given our briefs.  This only left 3 or 4 hours for our small team to understand the project, do some research, discuss options with the project owner, refine, and prepare a short presentation.  I suspect some of the world’s problems may take more than 3 hours to solve… but perhaps it’s a start!

In spite of my cynicism, the serene Dr Fatumo who gave us our brief seemed genuinelySomali women pleased with what we came up with, and hopes to make real use of it. She works for a charity called Hirda working on a range of projects in Somalia and they were looking for ideas to help boost a campaign they’re running to combat FGM, which is rife in Somalia with 80-90% of girls being circumcised by the time they are 8 years old. (For the less squeamish amongst you, FGM stands for Female Genital Mutilation, which isn’t something I thought I’d be learning about on a sunny Friday in London, but I’m glad that I did!).

The aspect of our proposal that was most relevant to SmallSeeds was the suggestion that they use radio and the fixed and mobile internet to tell the stories central to the campaign.  Both a fictional story (perhaps creating a radio soap that follows the lives of a range of families, those that do and do not practice FGM) and the real and very powerful stories of the women who are willing to share their experiences.  The World Service recently ran an item on the use of soaps to deliver health messages, and Hirda have already found that the most success they’ve had is when girls share their stories – the web and mobile can help amplify those in a vast country with some of the highest mobile phone usage in Africa.

So in spite of the heat, the group singing, the flagging live streams, and the insanity of trying to understand a complex and sensitive issue in such a short space of time, I do feel it was a day very well spent.  I also think there are some interesting ideas worth pursuing around how people in an increasingly connected world could make quite a big difference by lending a small amount of their expertise.  I’m sure there are other organisations out there who are also exploring just that, so my plan is to find them and see how they stack up.

In the meantime, hats off to those crazy ambitious Dutch guys, and thanks to The Hub for their hospitality!

We, the people

As I type, and one week in, the 42nd most popular petition on the government’s new epetitions site asks that our parliamentarians “Don’t listen to idiots signing e-petitions“. Joseph Blurton who posted it states:

We, the people, are idiots. Please, for pity’s sake, ignore us more often.

Currently 117 people agree with him.  I, for one, am not planning to join them, as I happen to think democracy is probably for the best (particularly given the violent alternatives playing out around the world at the moment). However, a scan of the 41 petitions currently more popular than Joseph’s doesn’t seem to be a particularly encouraging demonstration of e-democracy in action – or not yet anyway.

Regardless of the subject matter, it seems that we, the people, are not very organised. In the top 40 there are currently 5 separate petitions calling for a return of capital punishment, and 5 against it. There are 2 petitions calling for F1 to be free to view in the UK, and 2 asking for the legalisation of cannabis/recreational drugs. And there are many more on all of these subjects further down the list.

OK, so it’s only the first week, and the numbers are fairly small (10,621 against capital punishment, and 7,555 for… and only when you add them all up), but it’s a shame that none of the larger more organised campaign groups or charities seem to have taken advantage of the early publicity. Admittedly the Speaker only announced the launch of the site a week ago, but there’s been talk of it for a while, with government giving the project the go ahead back in December.  I would have thought a big campaign group or charity could have galvanised its supporters, particularly those they already engage with online, and made a bit of a splash in this first week.

Daily Mail front page 4th August 2011
Daily Mail front page 4th August 2011

Instead we’ve had a rather hysterical press reaction to the capital punishment petitions – in spite of the fact that the numbers are relatively small, there are repetitions and inconsistencies, and there are actually more people (currently) in favour of maintaining the status quo rather than reintroducing the death penalty.  It’s been given a fair bit of coverage on the BBC over the last couple of days, including on Newsnight (42.30 in), and several papers gave it a lot of prominence (including the Daily Mail yesterday which lead with the front page headline “MPs to vote on death penalty”.)

Regardless of whether you think epetitions, and the UK government’s latest initiative, are a bit of a gimmick, or a genuine evolution of democracy in the digital age, this week has shown that it’s possible to use these tools to grab the headlines and push the debate off the web and onto the front page.  We don’t yet know whether petitions from this site will influence government policy, or change laws, but we have seen that they can raise awareness and spark a debate.

I’m sure there will be more organised and larger scale use of the epetitions site over time, just as there have been on Avaaz. It’s just a shame that none of them were on hand to take advantage of the press hype around the launch.