How we provided evidence for the Digital First Assessment

Last November, we used this website to tell the story and provide evidences for our project Find Business Support (FBS) during our Beta Digital First Assessment.

What’s a Digital First Assessment?

If you are launching a new digital public service or redesigning an existing service in Scotland, it needs to go through the different stages of the Digital First Service Standard assessment.

• Digital First Service Standard assessment - Explains what is a D1 assessment
• Digital First Service Standard - Explains the set of 22 criteria

Context

At the start of the Private Beta phase (August 2019) new people joined the project delivery team. The Alpha team (about 12 people) became the work stream 1 and focused on the frontend and the customers. A new work stream 2 was created (about 12 people too) and focused on the backend and the partners and how they would provide the services and events for the end user: the customer.

The partners (Business Gateway, Skills Development Scotland and Highlands Islands Enterprise) were involved as much as possible, which added about 15 people to the project, who would access and contribute to the project documents.

We used a Sharepoint space to store the day to day project documentation, and another Sharepoint space was used to store the documents needed as evidences for the D1 assessment.

Problems we faced

• The sheer amount of documents produced by both work streams and stored in various folders in Sharepoint made it really hard to find the one you needed.
• Sharepoint doesn’t tell the story. This is just a folder structure, with many files whose name might not be very clear to everyone (even to delivery team members).
• Keeping everyone informed of the project’s progress was difficult.
• Providing the evidences for the D1 assessment became very time consuming and quite often added more work to the delivery team.
• When we got closer to the Assessment date, remembering what work had been done months ago, or what document or user research session had led to a design change could be difficult.

Approach we tried

A lot of the work we do can be shared publicly. The design team of Scottish Enterprise has started to design in the open as much as possible. This is what this website is about. At the time (Aug - Sept 2019), we had started to add project work to it. This allows us to tell the story, select and present the key documents to illustrate design rationales and produce a meaningful project timeline.

We worked backward to reconstitute what we had done, find the relevant document to share, and the dates where the work was done.

• The project space on this website
• The project timeline on that page

Positive:

• This doesn’t only help the D1 assessment team to see what we did. It also helps the partners and other people less involved in the day to day project work to see what has been done
• We have something to show anyone interested in the project and help potential new team members to catch up with the work done
• If done every sprint, then there is hardly any extra work when we prepare the assessment, this can also support our show and tell
• The timeline is an easy way to catch up with has been done if you have been away from the project for a while (holiday or else)
• It’s visible by the wider team who might not have access to your Sharepoint drive
• This can be shown on any device when you’re on the go, so you can show your work to anyone without firewall or other security issue

Negative:

• We had to convince some stakeholders that it’s ok to share, even when it’s a work in progress - We still have to do that quite regularly
• To be able to share some documents, we sometime need to modify them (delete names of team members or partners for example), so extra work before sharing
• We need to find another way to present the D1 assessors with documents which can’t be shared publicly
• You have to know how to use Github (add file, commit changes, etc…) and Mark-down language so need to train people or rely on the few who can update the timeline and other documents
• This is public so we need to make sure everyone are careful not too share something that should not be shared publicly
• not always easy to find the time to feed the timeline regularly

The result

This was very well received by the D1 assessment team. The project timeline was very clear and it was used to support discussions during the assessment sessions.

This was mentioned by the whole team as a positive at the end of the beta phase retrospective.

The partners also found it much easier to use than Sharepoint.

Next steps:

• Helping everyone in the team to add and write in github - training document is being drafted at the moment, and this website has a Help section for this
• There is a lot of PDF documents, which is not ideal from an accessibility point of view, we need to find alternatives (HTML pages or else)
• We need to get into the routine of adding regularly for each project
• We are trying to find ways to use this during sprint Show and Tell
• We are looking at communicating our findings with User Research participants, this is under construction and will be on this page

Note

We are using Github and Jekyll, but it could also work using Wordpress, or Umbraco for example. We could also imagine using something like the GOVUK prototype toolkit to create this website, as this could have the advantage to keep the team up to date by using it regularly.