https://dataingovernment.blog.gov.uk/rural-payments-service-assessment/
Rural Payments - Service Assessment
The Rural Payments digital service is the new way to register for the Basic Payment Scheme (BPS) and other rural payment schemes.
You can also use it to keep your personal and business details up to date, and to give someone permission to do your application for you.
Department / Agency:
DEFRA / RPA
Date of Assessment:
29/1/2015
Assessment stage:
Beta
Result of Assessment:
Not Passed
Lead Assessor:
J. Thornett
Service Manager:
G. Portman
Digital Leader:
J. Pierce
Assessment Report
Rural Payments service is seeking permission to launch on service.gov.uk as a Beta service.
Outcome of service assessment
After consideration the assessment panel has concluded that although the Rural Payments service has made significant progress since November’s mock beta assessment, the service does not yet meet the beta standard requirements of the Digital by Default Service Standard. Nevertheless, this is a complex service that has made tremendous progress in recent months, for which the service team deserve considerable credit. The panel believes that it is an achievable goal to pass the three outstanding points before the service is due to enter the next phase.
Reasons
The team has made substantial progress building the service, and it was particularly encouraging to see improvements to the delivery structure so that responsibility for decision making lies with the service manager, and product teams are able to make frequent changes to the front-end application.
There is a good understanding of the users that will be required to use the service, and the team’s approach to assisted digital (AD) support in particular is exemplary. The team has developed telephone and face-to-face support based on well-researched user needs and delivered this through appropriate government agencies and the third sector. The team proactively contacted potential AD users to make them aware that support is available and is testing a triage process. The team demonstrated that they are working closely with the support providers and are reacting quickly to feedback to improve the digital service, reducing the need for offline contact. Support has been designed to be scalable to cope with a likely peak in demand close to the claim deadline.
The service should now work to provide evidence of the following, that:
- The service is simple and intuitive enough that users succeed first time, unaided.
- The service is consistent with the GOV.UK design patterns and style guide.
- All new source code is open, re-useable and published under an appropriate licence wherever possible.
Recommendations
Service design & GOV.UK style
The team needs to address front-end development style; services on GOV.UK must work across a variety of browsers including on mobile and tablet (over 10% of page views of the service's start page are on mobile or tablet). Where pages are not responsive, clear warnings should be given to users on unsupported devices.
The recommendations from the accessibility report should be implemented. The team should check that all concerns at Web Accessibility Initiative (WAI) levels A & AA have been mitigated.
If AngularJS is used throughout the service. Care needs to be taken that users can use the service with limited bandwidth and that page changes are clear to the user. A fallback version of functionality that works without JavaScript should be considered throughout the service.
All pages should be checked to make sure that interactions conform to the current GOV.UK style guide. New interactions that have been developed, such as mapping, should be fed back into the design patterns Hackpad to see if they can be reused across other government services.
Focus on users succeeding first time
Hard deadlines stretching into 2016 appear to be putting considerable pressure on the team to deliver new functionality. Consequently, functionality does not appear to be being routinely developed iteratively based on user research and analytics. The service needs to ensure there is enough capacity in the teams to make the service better whilst continuing to add functionality.
There should be a designer, content designer, user researcher and front-end developer in each scrum/product team to improve the speed of delivery, and to allow more iterative improvements to user journeys through the service.
Designs should be prototyped and put into user research before complete implementation, and new functionality should ideally be trialled first with a subset of users to ensure it meets user needs. Live analytics should supplement in person user research, and functionality iterated until users can complete the prototype unaided and understand the process.
Make source code open
Defra owned source code being developed in-house by the service team should be published in the open and made available for others to reuse.
Summary
The team have been making great strides in building the Rural Payments service in recent months, and have demonstrated the ability to make significant changes to the service and the way it is being delivered since their alpha assessment. The service is on course to meet the Service Standard and it is expected that, at the current rate of progress, the service will meet the beta standard in the imminent future.
Essential feedback from the first users who have registered with the service is being gathered, and by adding this information to continued user testing and iterative improvement, the team is heading in a good direction for the future development of the service.
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 | No | 10 | Yes |
| 11 | Yes | 12 | Yes |
| 13 | No | 14 | Yes |
| 15 | No | 16 | Yes |
| 17 | Yes | 18 | Yes |
| 19 | Yes | 20 | Yes |
| 21 | Yes | 22 | Yes |
| 23 | Yes | 24 | Yes |
| 25 | Yes | 26 | Yes |
