People Finder aims to be provide an accurate, easy to maintain search service for staff to find where, when and with whom staff work within MOJ HQ. Currently used by MOJ Digital Services, the service is expanding to include an additional 700 users from two other teams within MOJ as a beta service. After completion of the beta phase, the service will roll out to several thousand users across MOJ HQ at 102 Petty France.
Department / Agency:
Date of Assessment:
People Finder service is seeking permission to launch as an beta service. After consideration the assessment panel have concluded the People Finder service has shown sufficient progress and evidence of meeting the Digital by Default Service Standard criteria and should proceed to launch as a beta service within the MOJ.
The service was assessed against all 26 points of the Digital by Default Service Standard and the assessment panel were particularly impressed with:
- User needs and scenarios of use clearly identified and expressed for user journeys through the service.
- Extensive testing in the target users’ real working environment.
- The mandate for change that the service manager had obtained from senior stakeholders to overcome any inertia - that managers will be responsible and accountable for populating and keeping the service up to date.
- The work the service team had done in designing a service so as to overcome the cultural, technical and organisational issues that had led to previous projects in this space becoming out of date.
- The thorough documentation and evidence the team had prepared for the assessment.
- The carefully balanced view taken when gathering feedback on a tool that is designed to encourage cultural change.
- Great practice in alignment with general HQ needs across assisted digital (AD) and accessibility, and identifying a target group for the next phase.
- Collaboration with GDS to reuse the code on a different project.
- The team’s close working spirit and ability to fully represent themselves in the assessment, despite the assessment occurring within a short period without a product manager.
The team have a very detailed understanding of their users and a strong roadmap for service improvements, some of which were already visible in the demonstrated service. They identified that AD users would become an increasingly large part of the user base, were the service to be released more widely.
We are also pleased that the need for a product manager had already been addressed, with the appointee due to start within days of the assessment.
We strongly recommend that the team carefully consider their release strategy to ensure initial user satisfaction and expectations are met. While the service is easy to use, it will still be unfamiliar and benefits will not be seen until more user data has been added. A cold launch to 700 users at once with no training may limit sustained channel shift; a more gradual release should be investigated as this would allow additional iteration and can create advocates for the new product.
In advance of the live release the team must:
- Create a clear statement for 'what success looks like' for the service users - it may take several forms.
- Ensure that you carefully plan the engagements of the proposed departments for public beta, and include clear research/communication elements to tackle behavioural change in use of Firefox away from IE, as the team have stated.
- Investigate implementation of search once higher volumes of data are in the system -the current approach of partial matching strings within words can lead to noisy results, and searching across different data fields could also potentially confuse (e.g. a person named Ruby vs. the programming language Ruby).
- Clarify the security accreditation status - whether authority to operate has been granted, and/or final security accreditation has been received.
- Ensure that the service has monitoring in place before expanding the service out to more users - at a minimum server load (CPU/memory/disk etc.) and traffic volumes (requests per sec etc.) should be actively monitored, with automated alerts to the technical team, alongside existing Pingdom setup.
- Establish with your security consultant or accreditor how security incidents should be reported.
- The technical team must investigate the feasibility of zero (or near zero) downtime deployments.
- Complete the documentation of forced shutdown scenarios, so that a member of a different team would be able to perform this task and escalate as appropriate.
- Gather feedback on icons in the organisational chart feature to determine whether these meet a real user need and if there are better ways to denote this.
- Test the ‘show everyone in this department’ feature, which could easily be missed. If this is an important feature it should be emphasised.
- Continue to test the skills and expertise tagging feature, changing it so that it avoids becoming cumbersome or full of duplicates.
- Perform specific AD needs and accessibility testing in good time for live assessment in order to demonstrate a reasonable AD service as part of the public beta (if the AD needs testing demonstrates an AD route through the service is necessary).
- Expand the HQ personas used to include specific personas - for live assessment we will expect to see People Finder user needs and documentation influencing the overall HQ shared documentation. The panel would love for People Finder user needs/scenarios/personas to influence the knowledge the department gathers about users for future HQ products and services.
- Ensure the team have a sustained period where they are able to concentrate on making rapid improvements on one single service as the userbase expands, rather than being divided across two HQ projects.
In summary the assessment panel are pleased to report that the service is ready to progress to a public beta stage. The work carried out during alpha and private beta to iterate and improve the service based on the needs of users was very encouraging and we are looking forward to seeing how the service further improves now that a larger number of users will be able to access it.
Digital by Default Service Standard criteria
|Details of criteria that are not applicable to this service|
|26 - not applicable to service with fewer than 100k transactions p.a.|