Digital collective



Finding out customer needs, and whether we can help them

Initial meeting and research

The digital services architect will set up an initial meeting with the customer. This is an opportunity to find out as much as possible about what the customer wants and needs. Sometimes an initial meeting is not enough time to understand this information, and an additional 2 weeks is spent on further research.

Initial engagement

Cost, time and scope

Draw the triangle above and ask which elements are fixed and which are flexible. Explain that a restriction on one aspect on the triangle, e.g. cost, will have an impact on the other two; time and scope. During this conversation, try to establish what design package might fit this model (UX, Service Design or Transformation) based on their business case, budget and timescales.


Is there a business case for what your customer wants to achieve? The business case should detail the problems they are trying to solve and the potential value of solving them.

What are the problems with the existing service or situation? Capture as many of these as possible, but make sure you prioritise them to the top 3. If these 3 problems were solved, would the customer be happy?


Is there a budget for the work? If there is, how has this been calculated?

Is the budget an estimate based on a business case, or is it simply that there is only so much money that can be released for the project?


Is there a deadline for when the service is needed? If there is, find out if this is a real deadline. It could be that a licence is about to expire or some software is going out of date.

However, people will often attach made-up deadlines to boost priority. This can be quite harmful, as an unreasonable deadline could mean the work does not get completed, or is rushed to an inferior standard.

Ask why the deadline is in place and if there is any flexibility.

Risks and restrictions


Examples of risks are:

  • Limited funding
  • High user rate expecting a certain standard of experience
  • Limited access to data
  • Burning platform


Examples of complications and restrictions are:

  • The service must integrate with an existing system/software
  • The service must comply with legislation or governance
  • The service supports more than 1 team
  • The service needs to migrate a lot of data

Ultimate goal

The ultimate goal is what the customer wants most – it’s the reason they’re talking to you in the first place. It should be a single sentence which describes the overall aim of the project, followed by a series of quantifiable objectives.

For example: To provide an automated and seamless experience for parents who wish to check their entitlement to education welfare benefits

  • Reduce letters sent by the service to confirm eligibility by 80%
  • Decrease the amount of time it takes to determine eligibility by 50%

A good way of finding out the ultimate goal is to ask the customer to imagine a front page newspaper story about their service. What’s the story headline? If it says ‘Council saves £250k’ you know they are driven by savings. If they say ‘Customer satisfaction increases by 50%’ it’s a very different motivation.

Knowing the ultimate goal helps the design team to tackle the most important problem, and keeps people on track throughout the process. Things you should capture:

  • Prioritised list of problems to be solved (this might be challenged during the design phase)
  • Definition of success and service priorities

Another way of understand the need, is simply to ask what the problems are with the existing situation/service. You might find that the customer gives you a long list of things they want to improve. This is fantastic and definitely worth taking a note of. However, you will find this even more valuable if you ask the customer to put their problems in order of priority – what is causing the most pain? What is the thing that is totally unacceptable?

Sometimes the customer isn’t sure what their ultimate goal is. This is fine too – but you should explain that you can’t move forwards until they know what they are trying to achieve.


Keep your ultimate goal in mind when researching and designing, to make sure your service improves as much as possible, and is relevant.


Review your ultimate goal at every demo to make sure you are on track.

Design package

Discuss the different options for service design.

  • UX (simple/small)
  • Service Design (medium)
  • Transformation (complex/big)

If the project is under £35k or 126 days, we would consider this a small project with essential functionality.

Most other projects fall into the Service Design category, where we would design key parts of the process, or design/redesign a process from scratch.

Further engagement

Journey mapping

We map the end to end “as is” customer journey in the initial engagement phase so that we can understand what the service is there to provide and how customers interact with it.

Stakeholder mapping

During initial discussions, it’s important to find out who has an invested interest in the service. This should include, at the very least the budget holder, who will be required to provide the budget code before work can begin.

You will also want to engage other stakeholders such as the Heads of Service, Customer Service Centre/Contact Centre, the Business Intelligence team and local IT and web teams. It’s better to engage too many people and let them decide it’s not for them, rather than miss them out completely.

Ask your customer to draw a flowchart or write a list of all the different stakeholders involved, and their needs for the service. You will need permission to speak to as many of these people as possible, to make sure you don’t disrupt their user needs.

It’s a good idea to capture email addresses and job titles as well, so you can assess how widespread the service will be in the council and contact people for an early engagement.

Service design toolbox

This is a 13-page document that compresses the process of service design including methods and techniques.