To deliver great digital work, your team needs more than just developers or project managers. It means bringing together a diverse group of people, including researchers, designers, frontline staff, and team members from different backgrounds.
Combining these varied skills and lived experiences helps the team understand the community they serve. By inclusion of these different perspectives, you can spot hidden biases early, ensuring the final service is fair, accessible, and genuinely works for every resident.
What this looks like
- Bringing together researchers, designers, developers, subject matter experts and frontline staff to work as one team rather than in siloes.
- Building teams with varied backgrounds and viewpoints to better reflect, understand, and design for your community.
- Ensuring the team regularly watch real residents test the work to build collective empathy.
- Delivering small, working improvements frequently to learn what works, rather than waiting for a single launch.
- Reviewing progress together regularly to share insights openly and unblock project challenges as a team.
The questions
- Does the team have access to the different skills needed to deliver good work, including front line staff and subject matter experts?
- Does the team include a diverse mix of skills, backgrounds, and frontline perspectives to understand our community?
- Has the whole team regularly observed real residents using the service to guide our design decisions?
How this links back to the Government Service Standard
This checklist point broadly maps across to:
Full guidance notes
To deliver services that truly work for residents, you must build multidisciplinary, diverse, and agile teams. This guide explores how to bring together the right mix of skills and perspectives to deliver good work, ensuring you can confidently answer the critical governance questions about team composition and empathy.
1. Breaking Down Silos: The Multidisciplinary Team
Historically, local government projects have suffered from a ‘waterfall’ handover approach. A policy team writes a specification, it is handed over the wall to an IT department or external supplier to build, and finally, it is thrown over another wall to the frontline staff in the contact centre or community hub to operate. This siloed approach guarantees that vital context is lost at every stage.
1.1 Working as One Team
To build services that solve real problems, you must bring together researchers, designers, developers, subject matter experts (SMEs), and frontline staff to work as a single, cohesive unit from day one.
- Designers and Developers: They bring the technical and creative skills to build accessible, functional, and secure digital tools.
- User Researchers: They provide the rigorous methodologies required to uncover what users actually need, rather than what the council assumes they want.
- Subject Matter Experts (SMEs): These are the policy and legal experts. They ensure the service complies with statutory requirements, such as the Care Act or housing legislation.
- Frontline Staff: This is often the most overlooked group in digital projects. Social workers, housing officers, and customer service agents possess a wealth of practical knowledge. They know the actual language residents use, the common mistakes people make on current forms, and the ‘hidden’ workarounds that keep broken services running.
Tip: Frontline staff should not just be consulted at the beginning; they should be core members of the team. Buy out a portion of their time (e.g., two days a week) so they can actively participate in the design and development phases. Their immediate feedback will prevent costly mistakes.
By merging these disciplines, the team avoids building a technically perfect system that is legally non-compliant, or a legally watertight process that residents cannot understand or use.
2. Building Diverse Teams to Reflect Your Community
Local government serves everyone. Therefore, the teams designing local government services must strive to reflect the rich diversity of the communities they serve. If your team is composed entirely of people from identical socio-economic, educational, and professional backgrounds, you are practically guaranteed to build services with significant blind spots.
2.1 The Danger of Groupthink
When teams lack diversity, ‘groupthink’ takes over. A team of highly digitally literate professionals might assume that a multi-factor authentication process is “intuitive,” completely overlooking how insurmountable that barrier might be for an elderly resident with an older mobile phone and declining eyesight.
2.2 Designing for the Community
Diversity in service design is not just a human resources metric; it is a critical risk-mitigation strategy. It encompasses:
- Demographic Diversity: Age, gender, ethnicity, and neurodiversity.
- Socio-Economic Background: Understanding the realities of digital poverty, shift work, or relying on public transport alters how you design access to services.
- Lived Experience: Having team members who have personally navigated the benefits system, used social housing, or cared for a vulnerable relative provides invaluable, irreplaceable insight.
When your team includes varied backgrounds and viewpoints, they naturally challenge assumptions. They ask, “Will this phrasing make sense to someone who speaks English as an additional language?” or “How will this work for a resident who only has internet access via the local library?” This internal challenge results in more robust, inclusive, and compassionate public services.
3. Building Collective Empathy Through Shared Observation
It is a common anti-pattern in digital teams to treat user research as a specialized function where the researcher goes away, talks to users, and returns with a PowerPoint presentation or a written report. While reports are useful, reading that “60% of users struggled with the payment page” does not change behaviour.
Watching a real resident—perhaps someone’s grandparent, or a stressed small business owner—visibly struggle, become frustrated, and ultimately abandon a service that your team built changes everything.
3.1 The Power of ‘Exposure Hours’
To build collective empathy, the entire team must regularly watch real residents test the work. This includes developers, product managers, policy leads, and senior stakeholders.
- Developing Intuition: When a developer watches a user misunderstand a piece of interface terminology, they instantly understand why it needs to change. They don’t need a formal ticket or a lengthy debate to convince them; the evidence is right in front of their eyes.
- Creating Urgency: Empathy creates urgency. A theoretical bug is a low priority; a bug that makes a vulnerable person cry during a testing session is fixed immediately.
- Guiding Design Decisions: Shared observation ensures that design decisions are grounded in reality, not internal council politics or personal preferences. When disagreements arise, the team can refer back to the user: “Remember how Sarah struggled with this on Tuesday? We need to simplify it.”
Tip: Set up ‘watch parties’. When user research sessions are happening, stream them (with the participant’s consent) into a meeting room or a video call where the whole multidisciplinary team can observe silently, take notes, and discuss the findings immediately afterwards.
4. Delivering Small, Frequent Improvements
Traditional local government IT procurement often operates on a ‘big bang’ launch model. A project is conceived, funded, built in secret over two years, and then launched to the public on a single day. This is incredibly risky. If the assumptions made two years ago were wrong, the council has wasted millions of pounds on a service that fails upon contact with reality.
4.1 The Agile Approach: Learn as You Go
Modern, user-centred teams work iteratively. They deliver small, working improvements frequently to learn what works, rather than waiting for a single, monumental launch.
- Start Small (Alpha): Build basic, low-cost prototypes. Test them with users to see if the core concept solves the problem. If it doesn’t, you have failed cheaply and quickly, and can pivot to a better idea.
- Build Working Software (Beta): Release a working, basic version of the service (a Minimum Viable Product) to a limited number of the public. This allows you to test the underlying technology and operational processes in a safe, controlled environment.
- Continuous Improvement (Live): Even after a service is fully public, the work isn’t over. Teams should continuously release small updates based on live data, user feedback, and changing policy.
Delivering frequently dramatically reduces the risk of project failure. It allows the team to adapt to new legislation or shifting user needs in real-time, ensuring the service remains relevant and effective.
5. Working in the Open and Unblocking Challenges
A multidisciplinary, diverse team working in an agile way can only succeed if they have the right culture. They must review their progress together regularly, share insights openly, and take collective responsibility for unblocking project challenges.
5.1 Ceremonies for Alignment
Agile teams use specific, regular meetings (ceremonies) to maintain momentum and transparency:
- Daily Stand-ups: A brief, 15-minute daily meeting where team members share what they did yesterday, what they are doing today, and—crucially—any ‘blockers’ stopping them from progressing.
- Show and Tells: Regular sessions (e.g., every two weeks) where the team demonstrates the actual working software or research findings to stakeholders and the wider council. This is not a status update presentation; it is a demonstration of real value. It fosters a culture of working in the open and prevents stakeholders from being surprised months down the line.
- Retrospectives: A safe, structured meeting at the end of a sprint where the team reflects on how they are working together. What went well? What went poorly? What can we improve next time?
5.2 Psychological Safety
For this to work, leadership must foster an environment of psychological safety. Team members must feel comfortable saying, “I don’t know how to do this,” or “The feature we built last week completely failed in user testing.” If bad news is punished, teams will hide failures, blockages will go unaddressed, and the final service will suffer. Unblocking challenges must be seen as a team sport, not an individual failing.