The United States Copyright Office
Electronic deposit uploader for copyright registration
Aligning stakeholders, defining UX vision, and navigating technical requirements to build and test a key enterprise application
Role
Team
Timeframe
Led end-to-end product design, research, and handoff as the sole Product Designer on the Electronic Deposit (eDeposit) Team.
Served as the central point of contact between executive stakeholders and cross-functional team members.
A cross-functional agile team of developers, QA, business analysts, and product specialists, with direct exposure to senior leadership within the Copyright Office.
February 2024 - April 2025 (14 months)
Overview
Like many other government agencies, the United States Copyright Office (USCO) is undertaking reform and modernization efforts to ensure that their services meet the needs of their users. At the heart of these modernization efforts is the creation of the new Enterprise Copyright System (ECS), an integrated system that unites the registration, licensing, public records, and recordation USCO platforms.
As the design lead on the eDeposit team, I was responsible for defining and directing all aspects of the interface, behavior, and navigation related to uploading a work(s) for copyright registration in ECS. This work was guided by a specific and important deadline — a congressional promise to initiate pilot testing on aspects of the new registration platform by December of 2025.
At the conclusion of this project, we built a robust and highly-usable multi-filetype uploader that was successfully tested by stakeholders associated with the Copyright Modernization Committee.
Challenge
Copyright law is dense, specialized, and difficult to navigate without legal expertise. When that complexity is compounded by brittle information architecture, unforgiving processes, and text-heavy screens, the barriers to successful registration become significant, even for motivated applicants. Users of the legacy copyright registration system (eCO) struggled to complete registrations successfully and efficiently, and the challenges they encountered were affected by factors such as experience level and application type.
Lack of system feedback and high cognitive burden- users must navigate complex decisions without guardrails or in-context guidance. Lack of essential system feedback, such as filetype validation, caused preventable errors and drove back-and-forth between copyright examiners and applicants.
Significant technical limitations- Files take a substantial amount of time to upload in the current system. Even worse, users lose all upload progress if their connection is interrupted or if they navigate away from the page before upload completion. Users also cannot upload files larger than 500 MB, requiring them to split larger files — such as motion pictures — into multiple uploads. The system provides no thumbnail previews, making it difficult to distinguish which files have been successfully uploaded
Fragmented systems and processes- copyright registration is siloed and disjointed. Users pay before they can upload their files, time-critical examiner communications are easy to overlook, and the registration process have no larger integration with related copyright processes like licensing, recordation, and public records.
A screenshot of the current process to upload files in eCO
Users
The Copyright registration system serves a wide pool of users. First time creators, legal professionals filing on behalf of their clients, and production companies registering unreleased films are just some of the many who rely on it to complete this vital service.
The type of work being registered directly shapes a user's experience, and the Copyright Office's many application types reflect just how varied those needs can be. From the streamlined Single Application for solo creators to group registrations for photographers, musicians, and periodical publishers, each path through the system carries its own complexity and its own opportunities for confusion.
415,780
total copyright registrations in 2025
Stakeholders
Copyright Public Modernization Committee
LIBRARY OF CONGRESS
COPYRIGHT
PUBLIC
MODERNIZATION
COMMITTEE
The Copyright Public Modernization Committee (CPMC) "represents a broad cross-section of the copyright community." CPMC nominated all 50 participants in the Copyright Registration Limited Pilot, selecting individuals they felt would best represent their industries and areas of interest.
Copyright Examiners
Copyright examiners review applications and determine whether claims meet legal requirements, a process directly shaped by applicant submission quality. Improving the registration experience reduces submission errors and minimizes correspondence applicants, making examiners' work more efficient.
United States Congress
Congress approved a $7.220 million budget allocation to support the continued development and modernization of the Enterprise Copyright System (ECS) for fiscal year 2024. During June of 2024, the Register of Copyrights testified before the Committee on House Administration that a limited pilot of aspects of copyright registration would be initiated before the end of 2024.
General public
Goal
Design an intuitive, efficient, and secure upload process that:
1. Supports the diverse registration needs of applicants across different submission volumes, workflows, and work types.
2. Streamlines the upload process and successfully integrates with the rest of the registration process, as well as the Enterprise Copyright System.
3. Dynamically incorporates logic and structure based on copyright regulations, thereby reducing the burden on applicants to interpret legal or procedural requirements.
DESIGN PROCESS
Creating alignment and shared understanding
When I joined, the team had strong technical momentum but no shared framework for how users would actually move through the product. The team had already committed to Uppy, an open-source file upload library, but there was no clear picture of how users would interact with it or how Uppy would need to be configured to handle the many different copyright registration scenarios we needed to support.
Given the complex and ambiguous nature of the project, I first conducted a design audit of any existing materials to create a comprehensive picture of the decisions, assumptions, and requirements that had driven development thus far.
Within four weeks of starting my role, I leveraged my design audit to begin leading a weekly UX grooming meeting with 10-15 cross-functional team members to create a shared understanding of user workflows, business requirements, and technical constraints. These meetings continued for the duration of the project and were critical for clarifying business requirements and working through foundational issues essential to the development of our product, and by extension, the entire Enterprise Copyright System.
Two images from the design audit
Defining constraints and business requirements
Defining requirements on this project was not a linear process. Because the product was still very much in discovery, business requirements and technical constraints evolved in tandem. Sometimes a new requirement would surface a technical limitation, and sometimes a technical constraint would force us to rethink a requirement entirely.
My role was to thread the needle between Copyright and development stakeholders, synthesizing perspectives from both sides and facilitating the discussions that moved the group toward shared decisions. The UX grooming meetings became the primary forum where this work happened, serving as the space where ambiguity was named and gradually resolved.
The uploader must:
-
Be built using Uppy, an open-source library utilizing the TUS protocol, to support resumable uploads that can recover from unexpected interruptions, be manually paused and resumed by the user, and run continuously in the background while the user proceeds through the remainder of their application.
-
Abide by the Copyright Compendium and associated practices for registration of different works, including support of all accepted file types and large upload sizes such as motion pictures.
-
Support both standard and group registration and their respective data models.
-
Successfully plug-into the rest of the multi-step registration process that is currently being built by different project teams.
Users need to be able to:
-
Title files after they are uploaded, both manually and using an automatic process via file metadata.
-
Perform bulk actions for titling files.
-
Seamlessly move in between steps in the registration process.
Important technical constraints:
-
Users cannot view full-size images, play media, or access files once they have been uploaded due to legal precautions.
-
The copyright registration process does not employ session saving, so there must be a saving mechanism after the user manually enters data.
User flows and journey mapping
Given the number of registration scenarios we needed to support, mapping user flows and aligning them with system processes was essential for uniting technical requirements with user paths.
I created user flows and system diagrams to map the presumed mechanics of the upload process and help untangle a critical question our team hadn't yet resolved: how should a user navigate a multi-step application while an upload is processing in the background — especially when the outcome of that upload informs the rest of their journey through the application?
System diagram to map validation and upload alert issues
Documentation and product direction
It was critical to maintain a single source of truth for product direction because we were making consequential decisions in real time. I created and maintained a UX Decision Tracker in Confluence, a living document used across our immediate team, Copyright stakeholders, and the broader registration team. Because the uploader would ultimately plug into a larger enterprise system and not operate in isolation, it was especially important to ensure that each product decision aligned with upstream and downstream processes.
The tracker documented each decision alongside the question that prompted it, the reasoning behind it, alternatives that were considered, the meeting in which a decision was made, and direct links to any associated Jira tickets. This ensured that decisions were traceable and visible to everyone with a stake in the outcome.
In a project where requirements were still evolving and upstream and downstream dependencies were numerous, this document became essential infrastructure for keeping the team aligned as the product changed.
Internal testing
I strongly advocated for testing the uploader under realistic conditions before the Limited Pilot. To bring skeptical stakeholders on board, I reframed the effort as "testing the test" rather than testing the product itself. This assuaged concerns about prematurely unveiling such a high-profile project while still affording the team the critical feedback and insight we needed before launch.
2
Rounds of internal testing
18
total participants
679
survey responses
Testing was designed not only to evaluate the uploader, but to trial the full sequence of steps participants would need to complete during the Limited Pilot. These steps included accessing and downloading zip files, creating a test Login.gov account, and creating a test ECS account.
Working with a colleague from the Copyright team, I designed the survey to capture both technical context and user experience simultaneously. The survey asked participants to record technical information about their upload (such as upload speed, browser, total upload size and more), and report on the overall experience of uploading files. This allowed us to diagnose issues in context rather than in isolation.
A portion of the survey responses imported into excel
The first round of testing was significantly impacted by upload failures, which limited participants' ability to fully complete testing. By analyzing error reports alongside participants' technical profiles, we identified VPN usage and incorrect downloading of test files as contributing factors, which then findings that directly informed how we structured the second round.
After each round, I reviewed and categorized all participant responses and presented findings to the team and stakeholders during UX grooming sessions to prioritize improvements ahead of the Limited Pilot.
Iterating from internal testing
30%
faster uploads
50%
reduction in system errors
There were three major changes we implemented after conducting testing:
1. Virus scan takes too long
2. "Big gray box" is poor transition mechanisim
Fold in virus scanning with the upload and remove virus scanning animation
Create a skeleton loading state
3. Uploads fail or are non-responsive
Change the upload protocol
The biggest issue we discovered during testing was that the upload process was slow and unreliable. This was concerning because it indicated that our product was not performing at an acceptable level and would likely malfunction during the Limited Pilot.
Recognizing this risk, I advocated for adopting an alternative upload protocol that was discussed during previous development cycles – one that uploaded directly to the s3 bucket. Through various meetings I gathered that this alternative upload protocol would have the potential to address mostly all of the problems we encountered in testing, we just needed to rapidly evaluate trade-offs and secure stakeholder approval in order to implement it in time for the Limited Pilot.
I spearheaded an emergency effort to investigate this alternative upload protocol presented it to the Product owner and other stakeholders. After securing approval from the PO, rapid testing, and eventual implementation, the new upload protocol resulted in 30% faster uploads and a reduction of system errors by 50%.
Launching the Limited Pilot
The note template for Limited Pilot sessions
Midpoint review of uploader-related issues
In December 2024, I led the onboarding of participants for the Limited Pilot — conducting 18 screening interviews in which I assisted each participant in creating a test ECS account, a test Login.gov account, downloading the necessary test files, and scheduling their Limited Pilot session.
We launched the Limited Pilot in January 2025 with 50 participants, all nominated by members of the Copyright Modernization Committee. Sessions were 90 minutes, conducted over Microsoft Teams and Zoom, and asked participants to upload both single and multiple works using the new uploader, as well as trial portions of the registration process including titling works, assigning authors, and receiving a certificate preview.
Throughout the pilot, I provided ongoing technical support, developed the note-taking template, and took detailed notes during sessions. When participants encountered issues, I troubleshot in real time. This ranged from ensuring cookies were enabled on the participant's end to coordinating with the development team to confirm their test account had been properly provisioned.
Concurrently, I conducted a midpoint review by analyzing 25 session notes and isolating uploader-related issues. I prioritized these findings, identified the stakeholders needed for resolution, and presented them to the eDeposit team. This enabled us to hit the ground running and plan work for the upcoming program interval, as well as allocate the correct developer resources to needed to plug the uploader into the broader registration system.
Participant response was overwhelmingly positive. Many described the experience as 'night and day' compared to eCO, the current copyright registration system. The Limited Pilot served a dual purpose: it was both a critical feedback mechanism for the project teams and a demonstration of progress to the stakeholders and oversight bodies deeply invested in the modernization of copyright. That it succeeded on both fronts made it a meaningful milestone for the project.
Associate Register of Copyrights Robert Kasunic reporting on the success of the Limited Pilot. The video in its entirely can be viewed here.
Iterating from Limited Pilot and accessibility review
The new error pattern to replace Uppy informer messages
How the old informer messages displayed and malfunctioned
The new consolidated view with the uploaded items underneath the uploader, no "done" button, and multiple signifiers of success
Following the Limited Pilot, we implemented changes drawn from two sources: participant feedback from the sessions themselves, and a formal accessibility review of the product conducted by an accessibility specialist. The most significant finding from the accessibility review was Uppy's native informer messages. These auto-dismissing popups either disappeared before users could fully register them, or collided with each other when multiple errors occurred simultaneously. Addressing this required replacing them with persistent alert snack bars from the Copyright Design System and mapping every possible alert and error state across the uploader.
Many of the remaining changes centered on a theme that had surfaced consistently in participant feedback: users lacked a clear picture of system status and a result, were unsure of how and when to navigate to the next step. To address this, we consolidated the uploader with the list of uploaded items so that uploaded deposits appeared in a list underneath the uploader as they were being uploaded.
We also added a status column to make upload progress explicit, and introduced multiple success indicators to give users confidence that their uploads had completed successfully. This also eliminated the need for the "done" button, thereby removing the confusion as to whether users needed to click "next" or "done" to navigate to the next step.
Additional changes addressed layout, clarity, and accessibility more broadly. We decreased the upload frame size during its empty state so users could see the full page architecture all at once, refined language for the standard application to reflect its single-file requirement, and replaced Uppy's native styling with Copyright Design System components to maintain visual consistency and meet accessibility standards for button size and touch targets.
Preparing for handoff
To support the transition to the registration team, I produced a comprehensive handoff package documenting the logic and behavior of the uploader. The centerpiece was an alert and error handling matrix specifying every alert state, error condition, and edge case, including exact UI copy, component references, behavioral logic, collision considerations, and linked Jira tickets.
The handoff also identified two system-level requirements for the registration team to resolve: the need to notify users of upload status and errors when they are no longer on the upload page, and the need to support file reordering after upload, a capability not yet built into the broader registration ecosystem.
A portion of the error matrix included the handoff package
Final designs
