keeping file management simple
UX Designer
Feb 2026 -April 2026
1 PO, 3 Engineers, QE, Analyst
the problem
File attachments solved a real need for reviewers, but created extra work for editors downstream. My job was to make sure the feature didn't quietly shift the burden onto people who were already stretched too thin.
business need
To onboard new journals to our pilot review experience, we needed to offer file attachments as a feature.
approach
Built a file upload component that surfaced key controls upfront and automated the checks that would otherwise fall to editors.
outcome
Extended the pilot to thousands more journals and improved UMUX scores for both reviewers and editors by 5 points from 75 to 80.
1.
discovery
Legacy system
the legacy system was costing editors time they didn't have
Looking at how the older system handled file attachments, a clear pattern emerged: tasks that could have been handled by the system were quietly getting handed to editors instead.
Pain points:
Manually inspecting each file's metadata to check for personal identifying information (PII)
Managing access for authors and reviewers independently
No distinction between files from different sources
-Participant 3
💬 user interviews
Some editors were copying reviewer file contents directly into the correct fields just to keep things organised for later in the process. Effective workaround — but not something they should have to do.
One other finding that shaped scope: 95% of submitted reviews go through untouched. Editors are mostly gatekeeping and routing, not revising content. That told me this didn't need powerful editing tools. It needed the right lightweight controls, in the right place.
2.
approach
design approach
editors need fewer decisions not more tools
Editor needs are more extensive than other users, but that doesn't mean they need an overwhelming interface. They need to feel confident, clear on the process, and in control, all without having to dig for anything.
From the legacy system, editors were expected to handle:
Downloading and reviewing file contents
Editing file contents or adding them to text comments
Replacing, deleting, or hiding files
Accessing file details and metadata
Checking and stripping PII manually
Managing file visibility for authors and reviewers independently
Adding new files as part of editor comments
For the new system, I cut this down to:
Downloading and reviewing contents
Replacing or hiding files
Accessing file details at one click
The cuts weren't arbitrary. PII checking moves to the system so that editors shouldn't have to do this manually. Adding new files mid-thread was removed; editors can replace reviewer files but don't need to upload fresh ones as part of a comment. Separate access controls for authors and reviewers were simplified. Less to think about, fewer ways to make a mistake.
The guiding principle
3.
design
AI alert
exploring layouts in Figma Make
Using our in-house design system, I combined components and tested how interactive versions felt in Figma Make. I fed it static screens with tailored prompts to generate layout variations quickly. The most useful output was seeing which control placements felt natural versus which ones needed an extra click. It directly shaped the decision to keep controls visible by default rather than tucking them behind a menu.
🚀 shipped design
🎨 design decisions
1
PII checking belongs to the system, not the editor
"Elsevier doesn’t push problems onto me".
When we have the chance to take a burden off users and design a system that takes responsibility, we should take it. The solution checks whether a file has been properly anonymised and alerts the editor if it hasn't — rather than expecting them to catch it manually.
2
controls are open and ready for use
"I can do what I know needs to be done."
Editor time is valuable. No hidden menus, no extra clicks to reach common actions. File controls sit open by default, saving time on every interaction.
Attachments are beside comments, using proximity to indicate their relationship.
3
hide, don't delete
"I can come back to this later."
Rather than allowing full deletion, files are hidden from view but retained in the history. Editors keep a clean working view without losing a record they might need later.
4
recognition makes downloading and replacing files intuitive
"I know what to do next"
File cards and upload buttons follow our design system conventions and match patterns users already know from other tools. Function is immediately clear — no explanation needed.
4.
impact
+1000s journals added to the pilot experience
UMUX scores improved by 5 points
Editor support tickets dropped by 20%
5.
learnings
Getting PII anonymisation right took longer than expected
The logic behind automatically detecting and flagging unstripped metadata was more complex than it appeared at the start. Working through edge cases with engineering mid-sprint created pressure I hadn't fully anticipated. Earlier, deeper conversations with the team about what "clean" actually meant technically would have saved time and reduced back-and-forth in the final stretch.
Figma Make is fast, but prompting needs thought
Generating layout variations quickly was genuinely useful, but early on I wasn't specific enough with my prompts and got outputs that looked plausible but didn't hold up under the design system constraints. Once I fed it more targeted context like component names and interaction rules, the iterations got much more useful. It's a tool that rewards upfront precision.
A tighter timeline sharpened the scope but left some things unresolved
The rushed timeline forced useful prioritisation: it was easier to defend cutting interactions when time was the constraint. But it also meant some edge cases around file visibility and access didn't get the attention they deserved. Those are now sitting in the backlog, and I'd want to revisit them before the feature scales further.