The Make a Plea service will allow people to enter their pleas online for summary traffic offences; which would not result in a prison term for the defendant if convicted. This service aims to:
- Reduce the number of defendants attending court unnecessarily.
- Create a public plea entry for traffic offences.
- Provide a fee payment mechanism for guilty pleas.
- Allow the re-scheduling of hearings.
- Show results of cases and notify defendants online.
The scope of the initial Minimal Viable Product (MVP) is for summary, non-imprisonable traffic offences in Greater Manchester. The subsequent goal is to deliver a nationally scalable service (on behalf of the HM Courts & Tribunal Service (HMCTS) Common Platform Programme) by March 2015.
Department / Agency:
Date of Assessment:
The service was assessed against all 26 points of the Digital by Default Service Standard. We asked questions from the prompts and evidence for assessors, supplied by GDS. This document has questions and the evidence sought for alpha, beta and live phases. The assessment panel asked questions from the alpha section.
The service currently meets the requirements of the standard for an alpha. Areas of good performance against the standard included:
The team has been particularly good at understanding user needs. The initial assumption about the digital service was that it would reduce unnecessary court attendance, but the team’s research found that most people attending court did in fact need to be there.
The team therefore shifted focus onto:
- Making the information provided to defendants (the “requisition pack”) easier to understand.
- Simplifying the process of submitting a plea with the required supporting information.
The team has conducted frequent user research during discovery and alpha phases to create and iterate the prototype. They conducted 30 user interviews in discovery and have been running one user research session (with 6-8 users) each month.
Ongoing research is planned, with assisted digital (AD) being a significant area to investigate further.
The team was initially comprised of London-based MOJ Digital Service (MOJDS) staff, who have since handed over to a MOJDS team based at Manchester Coroner’s Court. The handover was completed fully with minimal disruption. The current team is empowered, multidisciplinary, has separation of key roles and is working with their counterparts on the Common Platform programme.
Stakeholder communication is good: two key stakeholders are co-located with the team; they share information from the wider organisation and participate in the team’s daily standups 2-3 times per week. The team provides a weekly update to a wider group of stakeholders, and monthly show and tells with HMCTS.
95% of users are successfully completing the process unaided and first time with the alpha service. Dropouts were primarily because users did not wish to answer questions relating to their employer (users were worried their employer would find out about the traffic offence) and their finances. The service was accordingly redesigned to request financial information only when required rather than for all cases.
The team will have an opportunity to feed changes into the content of Greater Manchester Police’s requisition pack in April. As an interim measure, the team has used a yellow paper insert to direct users to the digital service first. The digital service then guides users to locate the required information in the requisition pack allowing them to respond online more easily.
The team will also be sharing their user research and design work with the Metropolitan Police to help them iterate on and simplify the content of their own requisition pack, though this work is outside the planned scope and timescales of this iteration of the digital service.
- Bring examples of the requisition pack, yellow paper inserts and yellow envelope sticker to the beta assessment. Include details of end user demographics (including AD needs survey results and service development) and show personas for all users of the service.
- Introduce more objective prioritisation techniques for non-functional backlog items to ensure they are balanced appropriately with functional user stories.
Security, privacy, tools and standards
- Advise stakeholders on likelihood, duration (40 minutes, assuming complete rebuild and restore) and impact of service outage, and seek their sign-off.
- Abbreviate user’s surname to an initial in the optional confirmation email to users to remove personally identifiable information.
- Have an alternate / fallback email delivery system to current system.
- Introduce GOV.UK Verify (already on backlog) for identity assurance of defendants making a plea online.
- Establish anticipated levels of load for a national deployment of the service and run appropriate load tests during beta phase.
- Mitigate email noise and anomalous submissions by validating case uniform resource names (URNs) during the process.
Document the disaster recovery plan from the knowledge already within the team; include steps to recover from a hosting failure.
- Create Domain Name System (DNS) based holding pages for outage and forced shutdown.
Improving the service
- Automate the integration and smoke tests.
- Work with the policy team to start the process of identifying and potentially removing legislative barriers.
- Check if people are searching for information on how to make a plea online on GOV.UK as a potential alternative entry point to the service.
- Code in the open; nothing is stopping the team from opening up the source, so they should do so at earliest available opportunity.
- Update the GOV.UK design patterns and toolkit in use to the most recent version.
- Consider improving the layout and text size of the information on the first screen that lets users know that there’s a 33% saving if pleading guilty.
Assisted digital and channel shift
- Create a plan for AD channels, including details of costs and funding.
- Seek best practice from GDS on surveying user satisfaction for AD channels, frequency of surveys and describe how this will inform performance and channel shift plans.
- Focus on creating AD scripts to triage people efficiently in the call centre; make room in sprints for that kind of iteration.
- Ensure the survey is robustly estimating the number of transactions; consider sample size during the beta trial with the call centre, use assistance from Analytical Services to ensure robust statistics and data.
Analysis and benchmarking
- Ensure there is data available in the beta phase for the results of the user satisfaction survey.
Testing with the minister.
- The team has demonstrated the alpha service to Shailesh Vara MP on 15th January 2015 and plans to test it again with the minister before going fully live.
Digital by Default Service Standard criteria
Criteria Passed Criteria Passed 1 Yes 2 Yes 3 Yes 4 Yes 5 Yes 6 Yes 7 Yes 8 Yes 9 Yes 10 Yes 11 Yes 12 Yes 13 Yes 14 Yes 15 Yes 16 Yes 17 Yes 18 Yes 19 Yes 20 Yes 21 Yes 22 Yes 23 Yes 24 Yes 25 Yes 26 Yes