Figshare

1.The Mandate

Figshare’s main customers are universities and scientific publishers. Most of them are government-funded, which means taxpayer-funded.

New mandates appeared in UK and USA, around 2018, that specified that government sponsored digital products must be fully accessible with WCAG 2.1 AA in Europe and Section 508 in USA by the end of 2021.

In 2018, new UK and US mandates set a hard deadline: government-funded digital products had to meet WCAG 2.1 AA in Europe and Section 508 in USA ] by the end of 2021.

If Figshare was to remain the viable repository for much of its customer base., it had to become accessible by September 2021.

Outcomes and Learnings

2.Gathering Usability Issues and Conducting an UI Audit

In parallel with accessibility education I centralized two years of usability issues from support tickets and client calls, then ran a UI audit with the team to establish where every component stood, in design and in code.

3.Ideation, Sketching and Prototyping

One issue outranked the rest. Publishing on Figshare means creating an item which is basically research data uploaded, described through a long metadata form (Fig 2), and rendered as a public page (Fig 3). This is the core of the product and it was failing on colour contrast, keyboard navigation as well as having some unresolved usability issues. It had no room to scale so it went first.

I prototyped several directions for the item flow and put them through 3 rounds of user testing, in person and remote.

Each round ran off a written test plan with an explicit list of assumptions, tracked live so we knew which survived contact with real researchers. Findings went into Dovetail. Each round of testing would inform the changes the would be tested out in the next round.

The blueprint of the interview:

• Overview — What is the purpose of those sessions? What do we want to get out of them?
• Objectives — What do we want to test? Which areas? What do we want to learn?
• User types — Who will be in the sessions? What is their level of expertise with Figshare? What is their role at their university?
• Questions we want answered — We’ve made a list of assumptions and tracked them throughout the meeting to see how easy to use were our proposed solutions.
• Verification — A set of questions to understand the user and the role.
• Activity — Presenting to the users what they would need to do, to interact with the prototype.

After the first 3 rounds of user testing I had enough data to get good insights (Figure 8). Thous would fuel the final iteration that would go into develipment (Figure 9).

4.Building Figshare’s Design System

In parallel I defined the Design System underpinning the product. That meant the system needed to cover all of the success criterion of WCAG 2.1 AA and some of the Level AAA requirements. Some examples:

• pass the AAA colour contrast requirements
• be easily accessible via mouse, keyboard only and screen readers
• be large enough in font size and in click/hit area to work for people of all ages and mobility impairments
• offer meaningful context around each element of the page
• offer consistent and multiple ways of navigating around the product

With my 2 UX colleagues I set the foundations: a new grid, custom icons, accessible colours, refined type scale and spacing rules.

I built the atomic components with the lead front-end developer, then complex components, layouts and pages with the wider team, reviewing each in Storybook so design and code never drifted apart.

Atomic components build up into complex ones. Below is the Public Item Page, where researchers showcase outputs and metadata, and preview any file type in the browser. No download is needed.

• Master components combine into organisms -> higher-level components
• Page layouts are key screens that present, in context, how the final page will look like.

Outcomes and Learnings