ONS Digital

Our Data Discovery Alpha is coming to an end in April. It is still possible to review the work we have undertaken so far on our blog post and we would love to hear your feedback.

As part of our end-of-phase work, we recently attended a Government Digital Services (GDS) workshop to review the progress of the Alpha. As the ONS website is a live service, it does not need to go through a service assessment, but we felt it was important to have a review from external experts to ensure we are doing the right things.

We took a number of things away from the few hours we spent with the GDS team.

Data Discovery

• It is a good project with all the right people doing the right things on it.
• We need to be careful in how we describe the project to make it clear which existing ONS sites this work will replace.
• Working in the open is important and not many teams do it to the extent (or as well) as we do.

High-level feedback

• Less is more. We need to make sure that simple things appear to be simple to our users.
• We need to continue to iterate all of the technology and UX choices on the project and test a wide range of ideas.
• Testing with real users and fake data is better than testing with fake users and real data.

The workshop looked at a few areas in more detail. These have been compiled into these brief notes and suggested some actions or next steps to take into the Beta.

Design and content

A need to ensure that we look up and explore as wide a range of design patterns and options as possible.

ACTION – Do more prototypes. Fake more things. Be prepared to fail even faster.

A need to ensure we allow users to feel supported with the actions they are undertaking at all times. All interactions should take place with a given context. Examples given were around upfront badging of the number of steps needed to customise data, clearer orientation of what each screen was doing, and how that contributed to a user goal.

ACTIONS – Labels are important. We can use them to help users understand the mental models we are asking them to have (for example, is the customising experience a linear check out, or hub and spoke interaction?)

The answer might not always be to download. If the answer is simple, do users just want that in the browser? Do they want to see a preview of the dataset in a browser, to see if it is the thing they were hoping for?

ACTION – Consider what an inline preview of a dataset could look like and what to do if a user customises to the extent that the answer is a single value.

User Research

Contextual research is really important. We need to remember that users will try and be helpful and give us an opinion even when they don’t know the subject.

ACTION – Ensure that when testing with subject matter experts, we have data available in the area they most understand.

The difference between data and digital literacy is an important point to keep in mind.

ACTION – Be aware of the need to assess a user’s digital skills as a separate characteristic than knowledge of data.

Accessibility testing. We need to ensure we can test with users with a wide range of access needs. Again, these also need to be users who would actually want to use the functionality to ensure we gain the most value.

Team

We need to think about multiple agile structures and models to ensure we continue to adapt. All teams should evolve over the life of a project. On projects like this, which use an in-sourced service team, it is especially important to build knowledge transfer in from the start.

ACTION – Keep being agile.

Technology

API keys and user registration are going to be an ongoing conversation. How do we balance the need to report on and manage our users if the API is totally open, versus the impact on user registrations we may see from the API being restricted?

ACTION – Continue to work with our users and the business to best understand how to balance this need.

The architecture must meet our specific Non Functional Requirements (NFRs). Our site has some very specific NFRs that we need to ensure we build for from the start. This is of particular importance when thinking about deployment processes and hosting models.

ACTION – Pick our technology solutions with care.

The API needs to get into the data. Feedback from the data.gov team reminded us to ensure that we treat API users as different to others. They are not going to always be data experts, so we have to ensure that they can get to the information they need as easily as possible. This means that we will need to consider operations like paging and follow the patterns of our existing API.

ACTION – Ensure the Beta scope captures the need to access data via the API.

It was good to hear such positive feedback from the GDS team and we are ensuring we continue to take action on the items identified for improvements. If you are interested in finding out more, please do get in contact.

The above feedback, positive user research and testing undertaken with over 1,200 people during the Alpha, and an agreement from the relevant ONS boards to do so, means we will now look to start the process of formally moving this project to a Beta phase.