Institutional workFile systemsICPSR

An upload you can follow, file by file, until it’s ready to use.

File Service is ICPSR’s reusable service for uploading, processing and describing research files. I defined its UX: upload progress, processing states, metadata display and the status view for staff.

Years
Apr 2022 – now
My role
UX designer, ICPSR
Team
ICPSR project team
Status
Live on every ICPSR site and hosted archive

What I covered

Overall role UX designer Steps 1–5

  1. 01FindRenewal kickoff
  2. 02ResearchUser interviews, Usability testing
  3. 03DirectionFile-state patterns, Status visibility
  4. 04BuildImplementation support
  5. 05OperateFixes and refinements
1Find the problemRenewal kickoff

Every ICPSR app handled files its own way, and users couldn’t see what happened next.

Files are the core of ICPSR’s archive: research data, documentation and supplementary materials from researchers around the world. Different applications handled upload, processing and metadata differently, which made the experience harder to maintain and harder to trust. I started the renewal in April 2022.

2Research itUser interviewsUsability testing

At 100%, the transfer was done. The file wasn’t ready yet.

I ran needs-discovery interviews twice: once at the start and once after the project was rescoped. Two in-depth interview sessions then filled in the detailed needs for the new scope. Once a design was confirmed, I tested it in small usability sessions and iterated.

Needs discovery2sessions

One at the start, one after the rescope.

In-depth interviews2sessions

On the detailed needs of the rescoped project.

Usability testingManysmall sessions

On each confirmed design, then iterated.

The old uploader reported one state for the whole batch and told people to refresh the workspace themselves. After the progress bar filled, validation, metadata processing and file preparation still ran out of sight, and the file’s actions stayed disabled with no explanation.

What the user sees
  1. Click upload
  2. Uploader popup
  3. Upload hits 100%popup can close
  4. File appears in list
  5. Actions disabledno reason given
  6. Ready
What the system is doing
  1. Upload starts
  2. Transfer completes
  3. Post-processing begins
  4. Validation checks
  5. Metadata processing
  6. File preparation
  7. File available
Legacy upload dialog with one overall progress bar for the whole batch, a manual refresh-log control, and a notice telling users to refresh the workspace to see results.
The legacy uploader: one progress bar for the batch, a refresh-log link, and a note asking users to refresh the workspace to see their files.
Who it had to work for

Users ranged from first-time depositors uploading a single file to principal investigators managing many files across multi-year studies. Staff needed provenance and processing history. Researchers needed to know their files were safe.

3Set directionFile-state patternsStatus visibility

Unfinished work stays in the uploader. The browser shows only files you can act on.

I split the experience into two surfaces with separate jobs. The MVP focused on three things: upload progress people could understand, visible processing states, and status updates as files moved through the service. The staff view was designed separately from the researcher view, and both got clear error states.

Two surfaces, two responsibilities
  1. 01File uploaderA temporary workbench. It holds work that is still uploading, processing or needs attention, and disappears once every upload has finished.
  2. 02File browserThe completed surface. It shows only files and folders that are finished, with metadata, access state and actions ready.

Screen size and importance don’t move together

Earlier designs treated the file list as a breakpoint problem and hid metadata as the screen got smaller. Discovery showed two separate axes. A PI on a phone reviewing an archived deposit and a first-time depositor on a desktop need different fields, whatever the screen size. Each metadata field got a tier from both axes together.

Two-axis display modelMetadata tier = screen size × importance for the task
Small screenLarge screen
High importanceTier 1 · Critical metadata onlyStatus, file name and the few cues needed to decide what happens next.Tier 2 · Expanded metadataMore fields stay visible because the task is important and space allows it.
Low importanceTier 4 · Hidden until requestedLow-priority fields stay out of the way on constrained screens.Tier 3 · Secondary metadataSupporting fields can appear without competing with primary actions.
4BuildImplementation support

I worked with the developers through implementation.

The MVP shipped with these patterns. Later updates added support for more complex file structures, batch workflows and larger deposits.

Try it: choose an Upload option or drop files on the zone. Uploads are simulated and nothing leaves your browser. One file fails during upload (retry it) and one fails in processing (remove it). This is the staff view, so files can be deleted.
5OperateFixes and refinements

Live on every ICPSR site and every archive ICPSR hosts.

I still pick up fixes as they come in.

ShippedMVP

Reusable file-service UX with clearer upload progress, processing visibility and status feedback.

Display model2-axis

File lists adapt to screen size and to how much a field matters for the task.

Error statesVisible

Error and processing states are easier to recognize, explain and recover from.

Next projectFixliAI turns a messy repair request into a clear, comparable job.