Skip to main content

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:

Date of Assessment:

Assessment stage:

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 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.


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.


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.


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