GovWire

DfE Developer Hub Alpha Reassessment Report

Government Digital Service

January 23
13:43 2021

DfE Developer Hub Alpha Reassessment Report

From: Government Digital Service
Assessment date: 17/12/2020
Stage: Alpha Reassessment
Result: Met
Service provider: Department for Education

Previous assessment reports

Alpha Assessment August 2020

Service description

The Department for Education is adopting an API led approach to application integration. As such, there is a widespread need to establish an enterprise-wide approach to managing and governing APIs in order to:

  • promote innovation and support a more integrated approach for suppliers and third parties
  • provide managed access to the department APIs for third-party suppliers
  • increase re-use in APIs
  • simplify integration and enable data to be used more effectively across the department

The theme that runs throughout this assessment is a clear view from the assessment panel that the team are close to or at the minimum standard for meeting the service standard. The panels concerns and questions are around the broader context of the end-to-end service which they feel is weakly defined and owned by the team.

The teams practice generally meets the standard, but the scope of consideration needs to be broadened to solve a whole problem for users and not focus on a core registration transaction.

The panel understands that this means the team will have to work outside of its direct management domain to influence and lead the contributions of others and would look to see significant improvements in this service design and leadership to be fully confident in the direction of travel.

Service users

This service is for:

  • third party suppliers
  • developers

1. Understand users and their needs

Decision

The service met point 1 of the Standard.

What the team has done well

The panel was impressed that:

  • the team have learnt from other API services in Government e.g. HMRC and GDS
  • the team demonstrated a better understanding of why third-party suppliers might need to access these APIs e.g. to create more business opportunities
  • the team better illustrated the range of external users and explained why they had focussed in on the third-party developers
  • the team gave a good description of the user research undertaken so far including the range of participants and methods used
  • the team clearly explained their riskiest assumptions, how they had tested them and what they had learned
  • the team have improved their personas and demonstrated how the team are using them in the design
  • the team provided good examples of how the functionality of the tool had changed based on usability testing e.g. create an account
  • it was clear the whole team have engaged with the user research and acted upon the evidence

What the team needs to explore

Before their next assessment, the team needs to:

  • prioritise the work required to understand the needs of what they referred to as secondary or tertiary users. The design and build are at an advanced stage and not knowing these people presents a risk. These are the people who will help the team achieve the strategic project aims. At present, the design is biased towards people who have to use it as part of their role.
  • the user needs to be presented were still related to the function of the tool and contained some jargon. The team have some insights on the problems third-party developers are trying to solve and the users needs should reflect this e.g. meeting the expectations of schools/colleges

  • continue to review and update the personas with new evidence. As they are each based on the experiences of one person, they should be referred to as case studies or pen pictures to avoid confusion over what they represent. The team should be mindful of designing based on one persons experience. The range and subtleties of developers behaviours and motivations could be lost
  • prioritise the research with accessibility users. The panel was disappointed this had still not begun. This reinforces the importance of building accessibility into every phase of research and not seeing it as a job that needs doing from time to time.

  • fully impact their user research beta plan against the people required to deliver it. The team are carrying over a large backlog of feature development and are yet to start accessibility work. Add this to the normal beta workload and it is far in excess of what one person can do well.

In conclusion, the user research to date has been focussed on the functionality of the tool that has been built. The panel would like to see research and evidence that reflects the end-to-end service driving the team. For example, quicker response times than those proposed came across as a key user need but is yet to be addressed. It is assumed this is reflective of the pressures third-party developers face. Focussing on this is what will actually make a difference to schools, teachers and students.

2. Solve a whole problem for users

Decision

The service met point 2 of the Standard.

What the team has done well

The panel was impressed that:

  • the team have a vision of how their service will work for users, and the kinds of outputs and outcomes their products will enable
  • the team are taking clear responsibility for the interface between the ultimate user and the API owner which supports getting access to the required authorisations
  • the team has made an effort to engage internal and external users

What the team needs to explore

Before their next assessment, the team needs to:

  • support the development of the recently recruited service owner who understands the scope and takes responsibility to solve the whole problem of supporting the implementation of the API to enable an outcome rather than simply delivering an application process
  • continue to focus on maintaining a shared understanding of how the whole user journey will work with teams responsible for different parts of it rather than simply address one element of it

3. Provide a joined-up experience across all channels

Decision

The service met point 3 of the Standard.

What the team has done well

The panel was impressed that:

  • the team has a broad engagement with user research and investigation so there is a broad understanding of the user perspective
  • the team is testing and making changes to users experience based on the feedback they receive and their growing understanding of the audience
  • the team is beginning to develop consistent internal design standards and governance for the presentation and management of APIs
  • the team are working with the BAU team and have visibility of the mailbox which enables them to learn from problems that are identified, and use this to improve the service

What the team needs to explore

Before their next assessment, the team needs to:

  • understand that part of their role in leading the service is to set quality standards for the documentation that supports the API implementation and support API providers actively

4. Make the service simple to use

Decision

The service met point 4 of the Standard.

What the team has done well

The panel was impressed that:

  • the team has worked hard with GDS to address previous comments and the Developer hub is a significant and exemplary improvement to the previous iteration
  • the team has demonstrated a clear process in place for content publishing and governance for their federated model
  • the team have provided endpoint documentation

What the team

Related Articles

Comments

  1. We don't have any comments for this article yet. Why not join in and start a discussion.

Write a Comment

Your name:
Your email:
Comments:

Post my comment

Recent Comments

Follow Us on Twitter

Share This


Enjoyed this? Why not share it with others if you've found it useful by using one of the tools below: