Statistics.gov.scot improvement project: discovery user research report

Co-design sessions

Two sessions were held on 01/08/24 and 05/08/24, both hybrid, being in-person at Victoria Quay and online using MS Teams. 18 SG staff took part; 10 of these having previously participated in the research, and 4 being members of the project team. The sessions were facilitated by Tom Farrington from Storm ID.

The aim of the co-design sessions was to discuss and sketch out ideas for improving specific aspects of the site that had been identified during the focus groups and workshops. The main activity involved small groups sketching in response to specific briefs, either on paper or in a digital whiteboard (in this case Mural). The workshop outline and sketching briefs were agreed in consultation with the Open Data Team, and are included in Appendix D, along with screenshots/photos of the actual sketches.

The sketches were subject to a basic qualitative content analysis by the facilitator, described, discussed and refined with the project team, which generated the following:

Underlying principles

Clarity: designs should prioritise clear, plain language across all pages.

Consistency: the gov.scot design system should be applied consistently throughout the site to ensure a familiar, intuitive, and accessible user experience.

User-centric simplicity: focus on essential functions and information, reflecting the needs and behaviours of users. It is important to remember that data publishers and those managing the site are also users.

Performance: the site should be optimised for speed, with particular emphasis on fast search results and dataset preview.

Details of sketches and discussions

Design and layout

Participants expressed a preference for simple, consistent design, e.g. use of the gov.scot design system throughout. This was particularly emphasised sketches of help and guidance pages, which currently look and feel different to the main statistics.gov.scot site.

A clear, introductory statement of purpose appeared on sketches of the homepage. There was also the suggestion that some indication of how complete the data on the site is would be useful, perhaps giving an idea of what’s missing. This could be further down the page.

Most participants chose to sketch desktop-sized screens, likely reflecting their use of the site at work.

Up to five icons appeared in headers, allowing the user to navigate to the homepage, to search, and to log in to their account (e.g. as a data publisher). There was also the suggestion that topics might appear in headers, although which topics would take priority was not specified.

On smaller screens, a hamburger menu including datasets, login, support, feedback and upload data was sketched. The first three of these were suggested as priority items. The suggested principle here is that the top tasks are to find data, publish data, and get help on using the site.

Search and results

Participants suggested that most people will start by searching, and so there should be a large, prominent, single search bar on the homepage, with consistent search icon/bar in header on other pages. There should also be a link below the homepage search bar to an advanced search feature, including search by date, theme, publisher, format, and licence.

Beneath the search bar could be popular ‘tags’ for datasets, potentially displayed as ‘chips’, to provide context and aid dataset discovery.

Search results should return all relevant datasets, i.e. offering related datasets below the closest matching dataset.

Search results should include a plain English summary of each dataset including the name of the dataset, licence info, and contextual information, e.g. who, what, where, when, to aid decision-making.

An icon to the right of the summary should indicate the type/format of file(s) available for download.

The search results page should offer filters (suggested in a column to the left of the results) and sorting (suggested above the results at the top right). Suggested filters were:

• Date
• Theme
• Publisher
• Format
• Licence

Suggested sorting options were:

• Relevance
• Date
• Name
• Publisher
• Date updated

Discussion indicated that there may be other sorting options that would be helpful. If the site is improved and gains this feature, then this would be useful to explore in future iterations of the site, through user testing.

Data publisher dashboard

Choosing a desktop size, participants suggested a dashboard be presented to publishers immediately on login. This would have a column on the left offering recently accessed datasets, a search for datasets, and a clear list of policy areas to allow publishers to quickly access relevant datasets.

Most of the page would be a list of the publisher’s datasets, with names and descriptions and buttons to view, edit and update.

A drag and drop upload feature was suggested, to provide files for download.

Clarity and simplicity are again the underlying principles here, along with some basic personalisation offering a sense of ownership of the dashboard.

Dataset landing page

Sketches here featured a navigation menu to get to various elements or presentations of the dataset, such as the preview (which should be surfaced on landing), metadata, dimensions/variables/data dictionary and potentially a filtering feature to allow partitioning of the data for download.

Sketched at the top of the dataset landing page were the name, a one-liner, plain language description, a button to download in various formats, and a button to access the API information. A note on the size of the dataset was also included here – this may include information such as number of rows and columns, and the file size.

The data preview was sketched showing the first ten lines of the dataset, to help users decide whether or not the data would be useful for their purposes. There was also the option to click ‘More’ to preview more lines of the dataset.

Help and guidance

The principle of consistent design was taken a little further here, with the suggestion that the landing page for help take inspiration from the main homepage. This would include a prominent search bar and ‘chips’ to signpost users to common help topics, e.g. ‘tips on searching’, ‘what data can I find?’, ‘there’s a problem’, and ‘methodology’. The topics here would require some refinement.

Another suggestion was for the help pages (which could either be the landing page, or surfaced following the search approach above) to offer a menu of help topics and sub-topics in the left hand column. Once selected, this would lead the user to step-by-step guidance on the sub-topic, with plain language and screenshots. https://guide.data.gov.sg/ was cited as a good illustration of this approach, using GitBook.

Performance

Despite not being something obviously sketchable, site performance appeared on sketches and was discussed by participants during the session. Unsurprisingly, the preference here was for higher speed, e.g. for search results to load quickly.

Language

A preference for simple, plain English wherever possible was expressed by all participants, avoiding technical language (e.g. pipeline) even during more in-depth processes such as data publishing.