Discovery
Last updated
Was this helpful?
Last updated
Was this helpful?
Before we start to build a new product or service, we need to understand the problem we’re trying to solve. Then we can then address how to solve it. But narrowing down a solution is something we do in the alpha phase. In the discovery phase, we focus on the users and their needs. We also need to think about our client’s requirements. And finally, we need to think about considersations and constraints relating to the service, policy and technology.
A discovery is typically made up of 3 to 6 sprints lasting 2 weeks each. Sprints follow a standard structure. We plan out our work, prioritise what we want to cover in the next fortnight, do the work, share our learnings, and reflect on what we’ve achieved and what we did to get there.
This iterative structure repeats throughout every phase of delivery. It means our work is always focused where it’s needed most, and we’re constantly revising our plans based on the latest learnings.
Our projects are delivered in line with the Government Service Manual.
A discovery clarifies a problem, measures its impact and advises if and how to address it.
Clients come to us for a discovery because they trust in our ability to understand, define and refine a problem. And because we’re experts in people and systems.
We approach user research with compassion and curiosity. We need to understand the users’ context and experiences so we can help to deliver better services for them. Likewise, we approach systems and technology with capability and understanding. We work with a variety of technologies, and are experts in mapping the existing systems and strategically planning for the future.
As a result of our work, our clients understand their challenges better. They get a broad view of the context the problem exists in. And crucially they gain insight into the people who use their services and the staff whose job it is to provide those services. We recommend whether it is useful to proceed to alpha, and if so, what sort of solutions would be worth exploring.
Our recommendations empower clients to make the right choices about whether and how to proceed into alpha and beta. A well-done discovery lays the foundations for a better product or service.
The team for a discovery will vary depending on the specific needs of a client. But these are the colleagues you could expect to work with:
researchers and designers, including ReOps (research operations), user researchers, content designers and service designers
business analysts who provide detail and insight into business requirements, processes and service data
solutions architects who supports the discovery to explore the current technical landscape and make recommendations to inform potential future solutions.
Project leads are senior practitioners within the team who provide a strategic overview. They’re also the main point of contact for the client. The project lead is usually supported by a delivery manager who ensures the project is running well, to time and with the right resources.
The client is the final, and most important, member of the project team. They are external to NEC Digital Studio and come to the project as a Subject Matter Expert (SME) to help our teams understand their organisation. They help make key decisions on the project, and later will be involved in prioritising work in our backlog.
Before the first sprint begins, the whole team gathers for a kick off. This gives them a chance to:
clarify project goals and timescales
align on how we’ll be working together
set clear roles and responsibilities
share our aspirations as well as concerns about risks
meet new team members and refamiliarise ourselves with existing colleagues
Before the discovery properly kicks off, we review any existing documentation or research shared by the client. This helps us understand the service’s current context, as well as any existing thinking on future opportunities and requirements.
Once that understanding is cemented, we can start to define the context and problem. A problem statement is agreed between our teams and the client. This makes sure we’re all on the same page, and that we’re addressing what the client really needs.
For example, a client may feel they need an app to encourage more people to use their services. But in reality, the problem they need to solve is a lack of trust between them and the community. So our problem statement to address in the discovery would be:
There is a history of mistrust between the service provider and its users. This is resulting in a low uptake of services that are designed to help the community.
An app might be the solution to that, but it might not. It’s our job to get to the bottom of what’s causing that lack of trust and how we might best address it. Starting a project with a narrow objective could mean you miss finding the best solution.
Now we know our focus, it’s time to dive in.
Our ReOps team starts the vital job of recruiting the right participants. This includes users of the service, staff delivering the service and subject matter experts (SMEs) in the area we’re researching. Once the right people have been found, offered an incentive likea voucher (where appropriate) and scheduled, the research can begin.
The research and design team, along with a business analyst, look to understand 3 main things:
Business requirements and outcomes – What does the client want to achieve? We explore how their business operates and any constraints associated with that.
User needs and experiences – What are the current needs and pain points of various users, from members of the public to employees of the organisation delivering the service? We document user needs taking accessibility into consideration. Once the research is conducted, we map out the user stories (what the user needs from the service) and user journeys (the steps a user takes through a service).
System and wider services – What things beyond the service have an impact on its delivery? This could include government policy or technical innovation. It is usually discovered through SMEs and desk research to make sure we’re on top of what’s happening in the service’s industry or community.
While this research is underway, our development and technology team will be tackling the technical requirements and possibilities including:
System diagrams - Map out existing connections between different platforms
Technology – Scrutinise the current tech stack (infrastructure and applications that deliver the service) understanding opportunities and constraints
Data - Explore the quantity, quality, structure and security of the data
Next, we bring everything together. We analyse and synthesise the research and technical considerations to come to a shared understanding. This means aligning systems, contexts, constraints and possibilities with user needs and business requirements.
This holistic understanding allows us to identify and recommend the best opportunities to explore in alpha phase.
The discovery phase’s main deliverable is a report that recommends whether a project should move into the alpha phase, and if so, outlines everything a team would need.
We answer key questions including:
What is the problem that needs to be addressed?
Can it be solved by a service or product?
What do we know so far about the opportunities for or parameters of such a service?
What are the likely costs and benefits of solving this problem?
What technical constraints and opportunities should be taken into consideration?
This is supported by specific information and artefacts such as:
User needs and stories
Service maps showing the current state
Business requirements
Potential alpha scope
Transcripts and documentation of all interviews
Technical review
We may need to pass a service assessment before we can progress to an alpha.
