Family Context in Children's Services

We’ll run a 12-week alpha, using GDS best practice. We’ll work in the open, sharing outputs and learnings publicly.

The local team are project leads in each authority and steering groups of key stakeholders. They will support with project management and staff time for user testing, IG, tech build, and process and governance management.

We’ll continue to work with Social Finance (not-for-profit specialising in using data to support vulnerable people), who will lead on user research, prototype development and preparing outputs.

We will run six two-week sprints each with a product iteration, retrospective, sprint review and show and tell. We have one month leeway to ensure we get polished outputs on time.

The project phases are:

Inception (pre-project & sprint 1) – late Dec & early Jan

• Work with IG on data requests and schedule critical path meetings
• Kick-off with stakeholders
• Initial interviews with users and tech/data leads

Iteration (sprints 2-5) – Jan & Feb

• Develop mock-ups and wireframes for initial user testing
• Develop MVP: a view of whether just one service has engaged with family (family defined with manual match)
• Test with users against need
• Iterate prototype with release each sprint for ongoing user testing
  

Conclusion (sprints 5-6) – March
Produce, test and refine conclusion report covering:

• • User research report on needs & if/how prototype met these
  • Business case on impact on children’s outcomes, time/cost saving for users and costs of beta &live

• Beta plan: what to build, plan, team requirements etc.
• Beta-gateway – assess whether to progress to beta with key stakeholders
• Measuring objectives
  We’ll know our objective is met if users in more than one council choose to use the prototype to improve their decisions. If this isn’t the case then we will understand why not and if it would be feasible to adapt the prototype or develop a new prototype in a second alpha, if further discovery is required or if we should stop.

Benefits

Our user research shows that frontline workers across authorities need a quick intuitive way to access basic information on families and what services are supporting them. This would:

• Ensure children are safeguarded – it is essential to know who a child’s family are and what services support them to understand risk factors and ensure children are safeguarded

• Ensure the right decisions are made the first time – having all the relevant information in place means vulnerable children are referred to the right service the first time. This means they get the right support and also saves the significant cost of children bouncing between services or falsely escalating. This could be a significant cashable financial saving, given the costs of intensive support, with care placements costing upwards of £50k  per year per child
• Enable services to coordinate their support – currently lack of awareness of service involvement means that support isn’t always well coordinated, even resulting in several services visiting a family on the same day unaware of each other. Having a view of all services involved would enable a joined-up response, saving time and meaning vulnerable families get the best support
• Save time – Currently frontline workers can spend days collecting information. Saving time on this process would enable these highlt-stretched staff to instead prioritise:
  1) conversations with the other key services to better understand families’ needs
  2) time working directly with the family

Shareable outputs

We will share our outputs online, ensuring that any code is open source and well explained so that other councils can test and implement our solution themselves. We already open-source our tools, such as the “Signposts” single-view system on GitHub, and, for example, are helping Essex Council implement our open-source user-centric website. We will use blogs, twitter, github and Slack to share our user research, prototypes and proposed standards (e.g. on IG)

Our 12-week discovery worked to understand the value better information on family context would provide to Children’s Services, speaking to over 50 users in Stockport and Leeds. We grouped these in five key personas (EH, SWs, front door, analysts and leadership), creating profiles, pain points, workflows, decision maps, information maps and user needs for each. We tested these in show and tells with users, and prioritised with them which needs were most important. We worked with Leeds to ensure we understood user needs across councils and that our alpha would work for multiple councils.

The biggest priority user need across both councils was having information on a child’s family (e.g. mental health, police engagement, youth offending, substance abuse, etc.) for both frontline workers (EH and SWs) to make the right decision on what support to offer on case referral.

However, this information often wasn’t available systematically. This means:

1. Instead staff often get information from personal contacts, on an ad hoc basis. This is time consuming, adds risk of inappropriate data sharing and means key information can be missed – in the worst case meaning the wrong support is provided or safeguarding risk is missed
2. Workers don’t know what other services are involved with the family leading to miscoordination of support: wasting service and family’s time
3. Where data sharing is most vital, intensive manual processes are implemented (e.g. 10+ services meeting for several hours a day to share their data)

We tested these findings with our 12 partner authorities and found commonality and agreement on the prioritisation, with 2 of them joining for alpha. We also worked with Acquired Knowledge, a tech consultancy, to run an independent GDS-style test of our process, outputs and readiness for alpha. We’re now finalising the outputs from discovery and preparing for Alpha. Our discovery outputs are published at github.com/SFDigiLabs.

We will build and test our prototype equally in Stockport, Leeds, Surrey and Worcestershire to ensure it addresses user needs in all four councils and we could build a common beta-product together. Doing so we will test that we can “fix the plumbing” in multiple councils and ensure that we are building something that could work for every council.

We are also working in a partnership of 12 councils working together to build common solutions to shared problems. We’ve tested our discovery findings with this group, and collectively selected this alpha project. We’ll continue to engage, share outputs and learnings and test our findings with this group to ensure that what we build would work for these councils also. The members of this group are also keen to take a successful alpha forward to beta.

Beyond these immediate contacts we continue to work in the open, sharing and publishing our learnings and outputs publicly and engaging actively within the Local Digital Declaration community.

User Research Report
In alpha we will test mock-ups, wireframes and a prototype with users across all four councils. We will produce a report outlining this user research process and its outputs. This will cover our key user personas in more detail and assess how the prototype meets their needs, how solutions need to work in practice and how they will fit into workflows and decision making.

Prototype
We will be lean and build a minimum viable prototype, testing and iterating this with users to ensure it meets their needs. We will aim to make this platform agnostic so it will work for all councils. The output will be a open source prototype with clear simple documentation and implementation guidelines so others could use it.

Business Case
We will assess across all four councils what the impacts of providing family context are for decision making in terms of improvement in outcomes for children and time and cost savings for frontline workers. The business case will analyse these benefits against modelled costs of the solution, both for beta and live development and for ongoing operation in the three councils. We will also assess the wider benefits that the improved outcomes would bring.

Conclusion for Beta
If the business case is strong, we will present a proposal and plan for beta assessing the impact of the tool, and how feasible it is. We will assess with stakeholders whether to progress to beta.

The user research report and prototype will be ongoing drafts that we iterate and improve to ensure we de-risk the development process. The business case and beta conclusion will be agree in principle in sprint 4, develop in detail and test with stakeholders in sprint 5 and then finalised for publication in sprint 6, leaving headroom for unexpected risks.

User research objectives
Our objectives are to better understand user needs, how well the prototype is meeting these and what we need to build to better meet them.

Users

Our target users are:

• • Frontline workers: we will focus on Social Workers, Senior Practitioners and Social Work Team Leaders. These are the key users that make decisions on what support to provide to children and families with severe needs. Our prototype will focus on addressing their need for family context information
• Business intelligence and development: BI team lead, developers, development managers, analysts and troubled families analysts. These users understand the data and technology in detail and are essential for ensuring smooth access to data and successful prototype development and deployment
• Data owners and information governance: IG lead, data owners and SRO. These users control access to and appropriate use of and protection of data. We will work with them to ensure timely, safe and appropriate access and use of data

User research process and engagement

Initially (sprints 1-2) we will interview and test out potential designs with users, including through testing mock-up designs in realistic workflow situations. We will progress our user testing from fake mock-up tools (e.g. using Sketch to quickly make realistic looking interactable solution designs), simple prototypes that function on dummy data, then to a prototype with real data that can be used in day-to-day work (sprint 3 onwards), which we will continue to iterate.

Placing the product with a target group of test users and assessing how it is used in their regular working environments will enable us to refine the functionality, content and layout of the tool.

We will use the relationships and deep understanding that we’ve built in the discovery phase to ensure we get strong engagement and straightforward, honest feedback from our users.

We would welcome the support of the Local Digital Collaboration Unit to:

• Help further share results
• Engage with more local authorities
• Provide check and challenge on process findings

We have received philanthropic grant funding for the discovery phase of this project.