Legal advice for civil servants alpha assessment

The report from the alpha assessment for GLD's legal advice for civil servants service on 22 May 2017.

From: Government Digital Service
Assessment date: 22 May 2017
Assessment stage: Alpha
Assessment result: Met

Service provider: Government Legal Department

The service met the Standard because:

  • The team had taken this large area of work and successfully defined a manageable minimum viable product with content focussed on Advice Lawyers and Civil Servants.
  • Feedback is informing the team, for example, changes to the home page, and login flow were directly made due to user research.

About the service

The service aims to reduce duplication of work by GLD lawyers and provide self service for some legal advice for public sector staff.

Detail of the assessment

The team were able to clearly explain the problem space - lawyers in government are asked the same question multiple times and the time spent answering similar questions would be better spent responding to more complex areas, and responding to civil servants more quickly. They were also able to give a confident estimation of the scope of the service, with around 3,000+ advisory cases open at any one time.

The team had taken this large area of work and successfully defined a manageable minimum viable product with content focussed on Advice Lawyers and Civil Servants. Starting with this limited scope means the team can focus on meeting their needs before extending the service to cover other areas.

Researching and understanding user needs [points 1, 2, 10]

The team has done an impressive amount of user research, and, as in the previous assessment, identified a whole range of users and stakeholders of the system.

By narrowing down to the two priority users, and a priority content area (changing the law), the team have been able to focus their questions and research time to make good progress in identifying specific profiles and needs.

User needs identified for each persona/user profile are specific and relate to the whole service, and they are based on research that the team have carried out.

Accessibility user research sessions have been carried out with 10 people, but as yet no improvements have been made. The team have attempted to find low skilled and low confidence digital users, but have not had success in identifying any potential people to take part in user research. I encourage the team to continue to try and find these people, and to make efforts to include them in research.

Needs have been clearly identified, however solutions have been reached quickly, for example content creator/lawyers are used to using pdf files. The team must work to understand how they are going to change and improve this.

Feedback is informing the team, for example, changes to the home page, and login flow were directly made due to user research. The process for user research informing the team is defined, with formal show and tells, prioritisation exercises and informal chats and meetings.

Some design patterns have been jumped to, without alternatives being considered and the user need thoroughly thought through. For example, the need for non-legal staff to understand legal phrases has been met through a glossary. However, the success of the service will depend on the needs of policy professionals to understand what lawyers are saying, and this could be met by enforcing a more stringent plain english policy on documents published.

While lots of user research has been done with policy professionals and lawyers and legal experts in departments, so far, there has been little research into the process of content production and curation, making it easy for people to publish good web content. And the team should make sure this is done in the private beta stage, as this will be a critical part of a successful service.

Running the service team [point 3]

The panel were impressed with the team’s attitude and approach to agile as an organisation new to digital. They should continue to encourage all stakeholders to attend show and tells and other agile ceremonies to ensure their buy-in and confidence in the team’s delivery.

One area of concern was knowledge transfer. The team was reliant on an interim developer and fast stream placements to fill key roles, however, they were working on limiting this risk through improving their documentation and planning for any change in their team. In addition to this, this technical risk would be reduced with a technical lead overseeing decisions at a department level.

One key role the team were waiting to fill was that of content lead. As this is such a content-heavy product, having a skilled content designer to lead this work, ensuring compliance, a process for keeping content up to date and the content cycle in place and working well is essential.

At the moment, content is prioritised by what seems to be useful at the time although there is no data to support this decision-making. There are multiple teams involved in creating, assuring and publishing content. It’s great to see the team working so closely with its stakeholders but there is a big risk that there isn’t a clear ownership of the content cycle across the service - ensuring it works and it consistent.

In beta, the panel recommends that a skilled content lead sets and takes ownership of this area of work, testing out various approaches until they are confident it works. Key areas are:

  • Testing the content cycle including document creation, the publisher process, understanding where content gaps are and how you deal with them
  • Keeping content up to date across the service
  • Overall quality and consistency of content
  • Discoverability and grouping of the content

The team should also get the support of a Performance Analyst to lead their measurement work and ensure they’re collecting the right metrics to improve.

In addition, the panel were concerned that the service would go into ‘business as usual’ delivery at some point in the future. It’s important that there is a team in place that can keep improving the service after it goes live. This is because internal IT teams are often not equipped to iterate a live service so there’s a risk that it will deteriorate after go live.

Designing and testing the service [points 4, 5, 11, 12, 13, 18]

During alpha the team had been tested and iterated the production service and as they go into beta they plan to test assumptions using the wireframes and prototyping software. We would recommend testing high fidelity prototypes using existing design patterns with users to avoid rediscovering interaction issues that have been previously resolved by other teams. Resources for prototyping can be found in the design section of the Service Manual.

The team had produced an alpha service that is generally consistent with GOV.UK design patterns although I would encourage them to share any cases where the patterns do not work for their specific users’ needs with the cross government design community. When defining new patterns you must be able to demonstrate a clear user need backed up with thorough user research.

We would suggest the team explore ways of defining legal terms which is currently being handled with a tool tip. This will likely be solved when they have a content designer working to set best practice for writing legal content for the web.

We would also recommend exploring other ways of informing users of future content. Blogging for example could help solve this need but also help promote recruitment for user research participants.

Technology, security and resilience [points 6, 7, 8, 9]

The panel were pleased to see an approach being adopted to ensure knowledge sharing and refactoring of the code base as they move towards private beta. The team have recognised the problems inherent in having had a single developer working on their project and are actively taking steps to address this.

Choices in technology were chosen for sensible reasons and are based on open source technologies.

Currently the code is hosted on a private GitLab instance, from which a process to regularly publish snapshots it to be enabled. The panel would suggest that this is a difficult and perhaps unnecessary process and would recommend that they look to run on a public source code management tool, utilising private projects for secrets, but primarily coding in the open.

The panel also noted the use of proprietary document formats in their workflow, and would recommend looking to use open standard alternatives.

Using the magic link style login process is interesting, and the panel would like to see research into it’s take up and also the best settings around automatic logout and so on, if this could be shared publically with the rest of government that would be beneficial.

Improving take-up and reporting performance [points 14, 15, 16, 17]

The panel were encouraged to see the team planning out what measurements would tell them if the service was meeting needs and help them improve. The team were focussing on search terms to understand where missing content may be, time spent on page and a ‘further question’ section. The team should set up and test some of these measures in beta.

Recommendations

To improve the service, the team should:

Researching and understanding user needs

  • User research into the process of content production and curation, to inform the design of a successful content strategy

Running the service team

  • Ensure their new content lead has ownership over the design, test and implementation of the full content cycle
  • Have someone responsible for performance analysis and measurement of the service

Designing and testing the service

  • Test high fidelity prototypes using existing design patterns
  • Share any cases where the patterns do not work for their specific users’ needs with the cross government design community
  • Explore ways of defining legal terms which is currently being handled with a tool tip
  • Explore other ways of informing users of future content
  • Be consistent with other internal services like Civil Service Learning, for example with headers.

Technology, security and resilience

  • Run on a public source code management tool, utilising private projects for secrets, but primarily coding in the open.
  • Use open standard alternatives, instead of proprietary document formats in their workflow

Digital Service Standard points

Point Description Result
1 Understanding user needs Met
2 Improving the service based on user research and usability testing Met
3 Having a sustainable, multidisciplinary team in place Not met
4 Building using agile, iterative and user-centred methods Met
5 Iterating and improving the service on a frequent basis Met
6 Evaluating tools, systems, and ways of procuring them Met
7 Managing data, security level, legal responsibilities, privacy issues and risks Met
8 Making code available as open source Met
9 Using open standards and common government platforms Met
10 Testing the end-to-end service, and browser and device testing Met
11 Planning for the service being taken temporarily offline Met
12 Creating a simple and intuitive service Met
13 Ensuring consistency with the design and style of GOV.UK Met
14 Encouraging digital take-up Met
15 Using analytics tools to collect and act on performance data Met
16 Defining KPIs and establishing performance benchmarks Met
17 Reporting performance data on the Performance Platform N/A
18 Testing the service with the minister responsible for it Met
Published 30 July 2018