Copyright modernization

The process of managing copyrights is complex, both for the applicant and for the copyright examiners. It has also been hampered by out-of-date software.

The Copyright office began a process of modernizing these systems in 2018, seeking to create a single, Enterprise Copyright System to serve applicants, examiners, and all the interconnected systems they rely on.

The Copyright Office is transforming both external services and internal work processes. This includes building a new Enterprise Copyright System (ECS) to make all of the Office’s services digitized, interconnected, searchable, and easy to navigate. Additional work is underway to maximize the Office’s efficiency and productivity with improvements to the public information contact center, warehouse management, and certain financial systems.

From https://www.copyright.gov/continuous-development/

The problem

When I joined the UX team in 2021, I was focused on the internal system the examiners would use to review applications.

But it became clear that there were larger issues of alignment across teams — design, development, leadership, and many others — that were hampering progress.

There were many reasons for this misalignment, but a few we had to contend with in particular:

• Development teams for both applications were not coordinating on common practices and approaches, or adhering to the design system
• The organization had adopted SAFe agile practices, but were not fully comfortable or bought in to the value, so the planning and execution of program increments wasn’t aligning with departmental goals
• There was a lot of pressure from many sources, including library leadership, Congress, and industry interests, that often shifted priorities to meet outside demands

And most critically, there was a strong division between the internal and external sides of the application, and little coordination or consideration about how one system would affect the other.

As my counterpart UX designer on the external system team and I began to work more closely together, the issues with this bifurcated approach became clear.

Development teams were duplicating efforts, while also building features that weren’t needed because the input or the output had been removed. Meetings with the larger team would devolve into detailed explanations of code, without ever resolving the questions we were there to discuss.

It was a mess.

The first map

My colleague and I approached Copyright with an idea — doing of story map of the system, where we defined a typical journey of a user, and outlined the functionality that the system needed to support each step.

This would be an experiment — over a few weeks, we would do facilitated sessions with small groups from Copyright. Between each we would build out portions of the story and the functionality, and see if the result was useful to driving conversations.

The initial sessions created a user journey for the internal side of the application, from when an examiner gets a file to when they make a decision.

Once we had that, we started to build downwards, naming the different pieces of functionality that would support the step.

Iterating and expanding

The initial effort was successful, and we transitioned to spending most of our time over the next several months developing a larger story map to cover the internal and external systems.

• Evangelizing the need for a user-centered approach to skeptics across the organization
• Planning and managing facilitated sessions with stakeholders from the copyright and technical teams
• Iterating on the map itself to ensure clarity and accuracy
• Maintaining related documentation for sprint planning and PI planning to make sure the models were in alignment

Metaphors and models

This was an entirely new way of thinking about and approaching this work. There were a few concepts that helped keep the conversation moving.

“The narrative divide”

Conversations about the map inevitably got pulled towards the mechanics of how things would be done. We drew a line, calling it the narrative divide. Above the line were the parts of the story — who, why, and what happened. How things would happen, came below the line.

It was a shorthand to refocus the conversation and get back to the bigger picture.

Known unknowns and 55-Gallon Drums

The exercise was to map the system, but there were other benefits to making the full thing visible.

There was a deep fear that we would miss something critical, and that fear often overtook practical conversations about known functionality, stalling any forward progress.

The process gave us a chance to acknowledge the “known unknowns” and “the 55-gallon drums” (because a can of worms was too small to encompass the complexity of these issues).

Things like:

• Physical asset management (acceptance, warehousing returns)
• Digital asset management (file upload, security, size limitations)
• Integrations with other systems
• Content support for help

Especially for things like warehouse management — massive, complex, and not under the control of this team — acknowledging their existence and the risk they posed let us turn back to the more immediate issues.