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.)

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.

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.

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.