What is discovery and why is it so important?

A key part of the process we go through with any new client at Tech Works For Us is a "discovery" stage. We believe that this is a vital step, one that could save huge amounts of time, money and effort down the line. Generally, until it is done, our proposal for how to tackle the rest of the project is only provisional. It doesn't need to be a lengthy process (although it can sometimes be worth dedicating a significant chunk of time to it, depending on the project and situation).

We understand that sometimes taking something of a step back can seem like a frustrating hold up when you want to get to the good stuff right away (the actual user research, or building things). It might sound like going back over old ground. So we wanted to share more about what this process involves (for us) and why it is so valuable.

As we have argued elsewhere, we are not interested in getting into the weeds about what the "true" meaning is of digital development jargon, what matters is being specific and clear about what you mean in any particular circumstances (and that it is useful as a term). But let's briefly look at how "discovery" is used more widely. As a term relating to design it is found in the first stage of the "double diamond", where it refers to gathering information, insight, requirements, objectives and so on, in order to then define the product in appropriate detail (before going on to actually develop and deliver it). It has become a standard part of software and product development for many. For example, here is how the Government Digital Service conceives of it, but there are various different conceptions of discovery out there.

In the GDS example it is fairly specific to the sorts of projects that they are likely to be running but each client we work with is quite different. There isn't going to be a one size fits all discovery process. For example, GDS suggest it will take at least 4 weeks, but most of the clients we work with cannot afford that, and the scale at which they are working or type of project doesn't require it in any case. In fact, we have run very successful discovery processes in one day.

Broadly, though, the goal for discovery as we use it at TWFU is the same: to make sure that we and the client have all the information we need in order to start supporting you and that everyone involved is clear about the aims of the project. It is designed to ensure that clients are genuinely in a good position to start moving forward with their new website, app, research project, feature, or strategy.

It is always instructive to take a step back and review things with fresh eyes, we have never worked on a project where this first step wasn't useful. Conversely, we have in the past (as a solo freelancer) worked on plenty where we weren't able to do this for various reasons, and the projects so often suffered from poorly defined objectives, missed institutional knowledge and staff frustration at this being overlooked, lack of stakeholder investment or agreement, or a lack of audience understanding. The discovery process can identify these potential issues and develop a prioritised plan for solving them before further time and money is wasted. That's why we see it as critical for de-risking the project and saving money, time and heartache in the long run.

This process might involve:

• A kick off meeting to explore what the project team has done so far, how confident they are about their objectives and how those were arrived at, what they know and what they don't know about their audiences and products, what assumptions are being made, what the parameters of the project are (time, money, internal skills and experience) and how fixed they are. It is also a good time to start looking at preferred ways of working so we don't suggest a methodology that is likely to clash with these.
• Going through any existing project documentation and research to better understand and sense check any decisions made to date and again identify gaps and assumptions in knowledge. This also helps avoid duplicating work that has already been done.
• Interviewing staff and stakeholders to see what existing institutional knowledge is already held within the organisation, and what their individual or departmental needs, goals and ways of working are.
• Developing or reviewing project objectives with all stakeholders to make sure they are solid, agreed and actually feasible.
• Using insight from all the above to create a better defined plan for next steps. This might be quite different from what was originally intended! Perhaps some organisational issues have been identified that need tackling first, or assumptions that need testing with user research, or maybe the objectives don't match the expected output and, for example, an app isn't actually the best way to meet the needs of the intended audience.

A colleague on a past project described the process as "dragging all the skeletons out of the cupboard". This hints at the fact that it can bring out things that are uncomfortable (legacy software systems that are hampering development or tensions about the objectives from stakeholders, for example). A resistance to doing this is therefore understandable. However, these are exactly the sort of things that can bite you in the behind later on if you don't expose them at the start and deal with them. Better to know and have a chance to mitigate these risks at the start.

It can feel a bit odd to go into a process without knowing exactly what the outcome is going to be, but we are usually able to say from experience what that is likely to be, which is usually reassuring to clients, and can tailor those next steps to different budgets and available resources. It is increasingly accepted with more "agile" ways of working that you just can't know everything at the start in any case.

All the above is why discovery is a vital part of the Tech Works For Us process. It prevents future problems and enables us to get to the heart of client and user needs. As with everything we do, we are up front in advance with potential clients about how the process will work, and can develop the plan for it in collaboration with them. For some clients, this discovery work is the whole process for the moment, a discrete piece of work that will enable them to then raise funding or develop their own internal strategy. Everyone's needs are different, but our discovery process works with them all.