Navigating PRA

10x is a federal venture studio within the General Services Administration's Technology Transformation Services. I contributed to a product called the Forms Platform. 

“Forms Platform aims to solve a persistent challenge faced by federal agencies: delivery of compliant and user-friendly forms, delivered cost-effectively, seamlessly integrated with diverse agency workflows, and accessible to non-technical program office staff. Deployed broadly, Forms Platform would serve as a common interface to federal government services, tailored to public sector needs.”

I joined the team as design lead during a period of transition. We were at a crucial period of building out the MVP in anticipation of launch, and there had been a lot of turnover, including the product leadership being abruptly pulled away to another priority project. My tenure on the team was temporary, with an unknown end date.

Distilling complexity 

A key feature of our platform is compliance. Agencies needed to feel confident that the forms they were publishing were compliant with a number of laws and policies, including the Paperwork Reduction Act (PRA). The PRA is a complex law, and our research had indicated that form builders might not know about the PRA, much less understand how and if it applied to their specific form. 

My goal was to identify which features would be necessary to create PRA compliant forms, and distill that complexity into a user flow that would guide builders.

When starting to design the PRA compliance features, I thought it would be fairly straightforward. Builders needed to determine if PRA applied to their form, and if so, add a control number and expiration date. 

After talking with a number of subject matter experts, I realized “does PRA apply” was too simplistic a question. Because our platform is geared towards digitizing existing PDF forms, builders also had to consider what PRA status their form already had, and how the changes they would make during the digitization process would impact that status.

To clarify my understanding, I created this flow chart that details the different decisions and paths a builder might take.

The good news was that we determined that most of our use cases would fall under a provision that would let agencies publish their digitized form with its existing control number, and not require a new clearance process. The bad news was that despite the large amount of excellent PRA guidance available online, there was no single reference for this specific scenario that we could direct builders to.    

Translating policy into product

Next, it fell to me to transform this tangled flow chart into a clean, easy to understand user interface. It also had to be the lowest possible lift for the engineering team. I determined that an MVP version of compliance would require only two features: access to guidance, and ability to enter a control number. Two additional steps (keeping track of the form’s status and submitting a PRA package) were part of the overall process, but could be handled externally to the platform. 

I knew that agencies likely had a number of other internal approvals that they required before publishing documents. I wanted to chart a course for a future version of the platform that would incorporate these approvals, and let builders set statuses to enhance collaboration. Because of the temporary lack of product leadership and my own temporary status on the team, I was careful to clearly document my proposals in the Figma file.

The MVP

The final design was simple, embodying the maxim popularized by GDS, “Do the hard work to make it simple.” 

My solution is imperfect. The guidance is lengthy, and among other things it links to an archived PDF of an OMB memo, the only authoritative source I could find that clearly explained the important concept of “non-substantive changes”.  But these are the sacrifices inherent in a minimum viable solution. When I sketched out more robust solutions – working with an external team to publish guidance relevant to our users’ specific circumstance, embedding an interactive PRA navigator, using our platform’s PDF parsing abilities to scan uploads and recommend a course of action –I knew that these ideas were too complex for our tight deadline.

My “good enough” design is sufficient to test the central hypothesis of the Forms Platforms: that our tool would empower non-technical staff to quickly create usable, compliant digital forms.

Next steps

As it turned out, I did need to rotate off the team before continuing work on this feature. My next step would have been usability testing to determine if government employees with limited or no experience with PRA could use the guidance to accurately determine the next steps for their specific form. Inevitably this would entail additional copy iterations to maximize clarity and relevance. 

Shortly after I moved on, the project as a whole was also paused. I am optimistic that when it is picked up again, the next PM and designers to work on PRA compliance will be armed with a solid MVP and a clear pathway to supporting all aspects of pre-publishing approvals.