https://dataingovernment.blog.gov.uk/organ-donation-register-service-assessment/
Organ Donation Register - Service Assessment
The NHS Organ Donation Register service has been in place to capture people’s wishes to donate organs after their death. This new service that also allows users to register a wish not to donate, which supports new legislation for Welsh Residents that comes into place in December 2015.
The service allows users to express their wishes with regards to organ donation, should they die in the circumstances that would make them a suitable donor.
The service will replace the existing Organ Donation website, and back-end register, which only allow users to record a decision to donate.
Department / Agency:
NHSBT
Date of Assessment:
19/06/2015
Assessment stage:
Beta
Result of Assessment:
Not Pass
Lead Assessor:
S. Wood
Service Manager:
M. Charman
Digital Leader:
A. Bye
Assessment report
The Organ Donation Register service was assessed as a voluntary beta assessment. The service will not be on GOV.UK.
Outcome of service assessment
After consideration the assessment panel concluded that, if the Organ Donation service needed to be on the service.gov.uk domain, then it would not have been given approval to launch on GOV.UK as a beta service.
Reasons
The fundamental reason for the service not to pass assessment is that the team – although undoubtedly skilled and committed – is working in an environment that is much more waterfall than agile. For example:
- The organisation appeared slightly siloed, with IT talked about as a separate function.
- The team is spread over a number of locations. GDS advocates that teams are co-located as this is a much better way of delivering services using agile methods. This is because In Agile, teams are the unit of delivery and as such are encouraged to be self-organising, something that is not easy if people aren’t located together.
- One of the things we look for in an agile team is for it to be “led by a suitably skilled and senior service manager with decision-making responsibility.” It was evident that the service manager has the necessary skills to lead the team. However, she is required to get approval at a monthly board meeting prior to deploying software. This runs counter to the principles for governing an agile service, in particular: don’t slow down delivery; and decisions when they are needed, at the right level
In addition, the team spoke about recruiting a user researcher for the next stage. However, good service design requires at least one researcher to be in the team throughout the lifetime of the service. It was clear that the team had conducted some research on its own, as evidenced by its use of telephone surveys, a prototype of the service and online information architecture tools. Also, it is clear that the team is interested in, and responds to, what it learns about users, as shown by the change to using the term ‘cornea donation’ because of the emotions generated by the suggestion that eyes would be transplanted. Unfortunately this does not make up for the shortcomings caused by not having an experienced user researcher embedded into the team.
The assessment panel noted that assisted digital user research is undertaken through telephone surveys covering user needs and user satisfaction and through interviews with call handlers, which help to establish user needs and to improve the digital service. This is sufficient for this phase, but the panel would expect to see a plan for more targeted assisted digital user research in public beta, clearly identifying and demonstrating how the proposed support meets user needs. We would also expect the digital service to be tested with users who have low digital skills, not just low confidence.
The proposed assisted digital support design is appropriate for beta. Support will be provided by telephone through a contact centre (talk through and on behalf of the user), which is under the responsibility of the service manager and it has capacity to deal with increases in demand (usually following campaigns). There is also an agreement for registration to be provided face-to-face through GP practices. The support is existing so the team plans to continue to do user research and gather user feedback through public beta.
The service team has a good plan for digital take-up, without excluding or discouraging people from registering. This covers the full user journey, including understanding user needs in campaigns, working with partners to understand their routes to the digital service and changing policy to enable communication by email, rather than paper. However, the team lacks a dedicated designer, which has resulted in a rather confusing user journey.
There appeared to be a lack of usability testing, and no evidence that the service will work on a wide range of devices. Frequent usability testing is essential to see whether such a large and diverse audience can succeed first time.
There are two sets of users of the Organ Donation service: the public and medical practitioners. While the practitioner facing element was not discussed in detail at the assessment, the panel had concerns about the levels of testing with users, and particularly how easy the service would be to use on tablet devices.
The team talked about some technology choices being effectively predetermined by the supplier and their preferred tools. This has lead to a situation where they are tied to solutions, without being able to explain how that decision was arrived at. The assessment panel would have preferred to have seen a more conscious choice about how the solution was implemented.
The team had obviously spent some time thinking about how to measure the performance of the service, but the lack of dedicated data analyst, and the plan to release so infrequently, seems to miss out on an opportunity to improve the service as it’s exposed to the real world. We would hope to see more investment after the service goes live, to ensure that this opportunity is taken advantage of.
Recommendations
The panel recommend that:
- NHSBT consider hiring an agile coach to help change the way it delivers services to users
- The service manager goes on the GDS service manager induction programme in order to understand better the role in a GDS-style digital delivery team
- The organisation governs this service along the lines of the governance principles outlined in the GDS service design manual
- “Show and tells” are held at the end of each sprint and that stakeholders are encouraged to attend
- A dedicated user researcher is recruited to be part of the team
- A dedicated content designer is recruited to be part of the team
- The team co-locate (as far as is possible, given that the development of the service is already underway)
- The team look at how they will be making the source code open
- More attention is given to the medical practitioner side of the service, focussing on the needs of those users and the design of that side of the service
Separate recommendations have been sent to the team on design.
Digital by Default Service Standard criteria
| Criteria | Passed | Criteria | Passed |
| 1 | No | 2 | No |
| 3 | No | 4 | No |
| 5 | No | 6 | No |
| 7 | Yes | 8 | Yes |
| 9 | Yes | 10 | Yes |
| 11 | Yes | 12 | No |
| 13 | N/A | 14 | Yes |
| 15 | No | 16 | Yes |
| 17 | Yes | 18 | Yes |
