File Uploads for Peer Review Decision-Making

I led the UX effort to better support editors handling complex reviewer feedback, balancing usability, anonymity, and governance to create a more efficient and trustworthy workflow in peer review.

The Project

UX Designer

My role

UX Designer

Team

1 Product Owner,
3 Engineers,
1 QE,
1 Analyst

Timeline

Feb 2026 -April 2026

Overview

This project explored how file uploads could improve the editorial experience in peer review.

The initial request surfaced through reviewer behaviour, but the real design challenge was editorial: how to help editors work faster, make better decisions, and manage file-based feedback without adding unnecessary complexity or risk.

The challenge of file uploads

Editors are the decision-makers in peer review. They need to evaluate reviewer feedback efficiently, understand what can be shared onward, and maintain the integrity of the process.

Introducing file uploads had the potential to support this, but also to create friction if not designed carefully. At an enterprise level, this also meant designing for consistency, governance, and scalability across many journals and editorial contexts.

My role

  • I reframed the feature around editorial outcomes rather than upload mechanics alone.

  • Synthesised discovery findings and mapped editor workflows

  • Defined direction that supported decision-making rather than slowing it down.

Old site served one type of user.

Reliant on editorial pieces like reading lists and interviews with authors.

5 articles above the fold to guide the user to content.

Ideally, the strength of content would entice users to return to the site again and again, or venture to the product pages and retailer sites.

However, traction was low, content rarely visited, and entire user personas were missed.

Users were searching for other types of content outside the scope of the old hero section.

The old site looked after a very niche type of user, while neglecting others.

The analytics showcased the desire for access to company pages like 'Work with us' and 'Get published' as well as pages like 'Penguin Classics'.

Poor performance all round.

  • Users relied on the menu and search bar to find the content they were looking for.

  • 60% bounce rate

  • Home page played little to no part in clicks to retail journey

  • Typical journey = home page to search and back to home page - means users are struggling to find what they want.

A new component that reflects different user groups

For the home section

Designing a bento box grid allowed us to signpost 6 different sections of the site.

The idea was we could surface:

  • Discover hub

  • 2 corporate pages like careers

  • A link to the Penguin Shop

  • 1-2 Social Impact Links

  • 1-2 campaigns

Designing for other user cases

As well as the hero section, I wanted to make the component useful for other parts of the site. As well as the 6-box grid, I also included a 8-box and a 4-box grid in the designs.

The 8-box was developed as part of our MVP, while the 4-box has just been shipped. The 6-box version is expected later in the year.

Conversation with stakeholders led to decisions over trade-offs and a change in development

Because of dev resource, it was decided that we would first build the 8-box version of the bento box component.

This version was more useful across many different pages like social impact and the Discover Hub. Because of the extra use cases, it was prioritised over the 6-box version.

The idea was we could surface:

  • 2 content pieces around our books

  • 2 corporate pages like careers

  • A link to the Penguin Shop

  • 1-2 Social Impact Links

  • 1-2 campaigns

Individual elements to ensure it's success

Gradient background

One of the biggest considerations in designing this component was making sure all text was readable and complied with WCAG guidelines.

I added a linear gradient on the card and a drop shadow on the letters. This helped the text to pop and remain visible even if a subheading was used.

Interactivity & feedback

The old version of the site was extremely static and provided little feedback.

The new box has a gradient grows and an arrow appears when the mouse hovers over the box. This indicates the box is a link and encourages the user to click through.

Back-end experience

Working with the content team and the Product Owner, I set about improving the back-end. As well as providing a clean, easy-to-use front-end experience for the user, I wanted to keep the back-end experience equally straight-forward and simple. The component matches other elements of the site with a clickable preview and controls in the sidebar. I thought consistency was important here because of the many different editors and admin, so labels and descriptions are considered.

Editor needs were much more expansive than the other users.

From discovery and stakeholder sessions, it became clear that editors needed more than the ability to receive files. They needed confidence, clarity, and control.

Core editor needs:

  • understand what has been uploaded and by whom

  • quickly assess whether a file is relevant and safe to use

  • see useful file details such as timestamp, uploader, and sanitisation status

  • compare attached files with reviewer comments

  • decide whether a file should be shared, hidden, replaced, or removed

  • edit or replace files when necessary to protect anonymity or relevance

  • work efficiently without having to reconstruct scattered information

Editors also needed the experience to support the reality that not all reviewer feedback comes in neat, structured formats. For more complex reviews, files could help preserve important context rather than forcing editors to interpret incomplete or reformatted content.

Editors were at risk of inheriting the complexity of file-based review.

Even when file upload solved a reviewer need, it could create extra editorial effort downstream. I was wary of adding to an already massive workload.

Key pain points:

  • limited visibility into file status and what actions were available

  • uncertainty around sanitisation, metadata, and safe sharing

  • extra effort when comments and attachments needed to be reviewed together

  • manual work when files contained the most useful feedback but were harder to process than text

  • risk of confusion when files were replaced, duplicated, or attached incorrectly

Focusing on the moments that mattered to editors

I approached the problem by asking what an editor needed to move confidently from review intake to decision-making.

That led to a strategy centred on:

  • making file handling feel like part of the editorial workflow, not a separate technical task

  • surfacing high-value information early, so editors could triage quickly

  • giving editors clear actions over each file, including download, hide, replace, and review

  • designing for governance in a way that did not create unnecessary friction

  • reducing click cost and cognitive load by balancing visible actions with progressive disclosure of detail

Rather than over-designing for every legacy edge case, I focused on the moments that mattered most to editors: understanding the file, deciding what to do with it, and maintaining control over what happens next.

Closing in on a solution

My design direction emphasised clarity and editorial control.

For editors, this meant:

  • pre-input guidance on accepted file types and how files should be handled

  • quick access to uploaded files and associated reviewer comments

  • visibility into key file attributes such as name, type, size, upload time, uploader, and sanitisation status

  • the ability to download files, replace them to edit contents, or hide them when content should instead live in the text box

  • access to file details on demand, without cluttering the main interface

  • clearer review and triage of comments and attachments together

This created a workflow where editors could manage both text and files in one place, with more confidence about what they were seeing and what actions were appropriate.

Prototyping key interactions with AI

I used Figma Make to test ideas and get help iterating interactions. While the results weren't anywhere close to what I would be happy shipping, they were good as an exercise and helped me show my thinking to my squad.

#1
#2
#3

Shipped design 🚀

Abilities

This work produced a clearer editor-centred direction for file uploads and helped define how the feature could improve editorial workflows rather than disrupt them.

The expected outcomes for editors were:

  • faster triage of reviewer feedback and attachments

  • better visibility into file status and sanitisation

  • stronger control over what is shared, hidden, or revised

  • reduced ambiguity when handling complex or annotated review material

  • lower manual effort when managing uploaded files alongside comments

  • greater confidence in maintaining anonymity and process integrity

At a product level, the work also helped shift the conversation from file upload as a reviewer convenience feature to file upload as a capability that could strengthen editorial decision-making when designed well.

Actioning valuable user feedback

Talk about how editors work: might be weeks or more before coming back to the manuscript

Limiting abilities to ensure the process isn't hindered

Talk about logic of comment / file / both

Sanitisation

Talk about the process and edge cases where it fails

Results

The main result of this work was a more focused product direction built around editorial value. It clarified how file upload could support the editor’s role by improving oversight, reducing friction in triage, and making complex review material easier to manage.

It also created stronger alignment across design, product, and engineering around the conditions required to make file upload viable in an enterprise setting: clear status, clear actions, and clear governance.

Impact and learnings

For me

This project was a good example of senior-level UX work extending beyond interface design. The value came from identifying that the real success measure was not whether users could upload files, but whether editors could use those files effectively and confidently within a high-trust workflow.

My contribution was to bring that editorial perspective into the centre of the work and translate a complex, multi-stakeholder problem into a clearer, more actionable product direction.

Traffic to company pages

Looking after all our users was a key goal of this project. Highlighting company and publishing pages saw visits to our 'work with us' pages going from 9 visits to 3,924 over a four month period.

Similarly, our podcast page went from 0 visits to 1,500 over the same spell. Highlighting these types of pages is great for brand awareness and acquisition projects.

Bounce rate increased by 15%

We saw a dip in engagement on the page and an increase in the bounce rate. See below for my thinking why and some proposed solutions.

Lesser reliance on search/menu

Use of the main navigation has reduced by 60% as visitors choose to explore the site in other ways. Search use was also down by 10%.

What I'd do differently now

Back to 6-box version

My initial thinking is that having 8 boxes instead of 6 or 4 is causing decision paralysis in users and increasing the load. As Hick's Law shows, presenting users with too many choices can be overstimulating and reduce Psych levels.

Personalised options

My team is currently testing out using the bento box as a way to surface personalised content to returning users. If a user has visited specific genre pages on the site, they'll see different articles here related to their interests. So far, we've seen a 50% uptake for readers interested in history.

Have questions?

Send me an email or find me on LinkedIn

Have questions?

Send me an email or find me on LinkedIn

Have questions?

Send me an email or find me on LinkedIn