GovScan
Streamlining the search for information within government program reports
Context
The United States Digital Service approached us with a broad problem space - ‘Improving the usability of government program reports’. Government program reports are usually large, 300-400 pager PDF reports. The State sends them to the Federal agencies to inform how these federally-funded programs are being implemented in their own state. Examples of such programs include - CCDF, SNAP, Medicaid. These reports contain a wealth of information which can be instrumental in improving public policies, but often remain underutilized.
Problem
The lack of consistent structure
and information overload in State program reports compels policy analysts to spend valuable time in ‘information hunting’, resulting in reduced time available for analysis.
Solution
Enable policy analysts to quickly extract specific information within program reports through an LLM based platform.
Impact
Reduced the average time taken by policy analysts in searching for information within PDF reports by 95%
The Team
1 Project Manager
1 Engineer
2 UX Designers
Duration
5 weeks
My Role
User Researcher, UX Designer
I was closely involved in the entire development of GovScan, particularly taking lead during the problem discovery, definition and ideation phases. I also added my magic ‘visual design’ touch to the high-fidelity output.
High-Level Process
The beauty of the design process is in it's flexibility. There is no single formula!
This was the overarching process that lead us to our Minimum Viable Product.
Discover
+ Empathize
Week 1 & 2
Deep dive into the domain
-
Secondary research
-
User Interviews
-
Concept Mapping
Focus
+ Define
Week 3
Define the right problem
-
Affinity Mapping
-
Journey Mapping
-
Personas
-
Value Analysis
-
Job To Be Done
Ideate
+ Build
Week 4
Develop the best idea
-
Brainstorming
-
Storyboarding
-
User flows
-
Lo-fi Wireframing
Test
+ Iterate
Week 5
Improve the solution
-
User Testing
-
UI Iterations
-
High-fi protoyping
//Discover + Empathize
Understanding the domain - the People, Processes and Objects
Key Pointers for Discovery
Understand the big Ws of program reports
What are they? How are they made? Who makes them? Why are they made? What purpose do they serve?
Identify key stakeholders and map the flow of information between them
Understand the human experience of interacting with PDF program reports
Uncover direct and latent pain points
Insert GIF of scrolling through 100 unknowns document
We started off by listing as many 'unknowns' as possible
Secondary research to understand problem breadth.
Interviews to understand problem intensity and depth.
50 hours
Secondary Research
12
User
Interviews
We collectively went through over 50 hours of secondary desk research, and 12 interviews with policy analysts, accountability officers and researchers working at the State, Federal and NGO levels. This gave us an understanding of how program reporting sits within the workflow of the State and Federal governments and the enormous scale of it.
And what did we find?...
2000+
Programs
50
States
~300
Pages per report
<insert concept map of fed govt giving money to state , states executing program, state reporting back, fed govt analyzing the report >
Federal policy analysts had the widest scope in terms of exposure and interaction with these reports. There was a clear mental division of tasks that the policy analysts performed in their job. Laborious tasks such as sifting through these long, dense reports for information and data points, and intellectual tasks such as actually analyzing that information and making recommendations. In our interviews, we saw an overarching sentiment of laborious tasks taking away the time from the intellectual tasks.
Mental Division of tasks
“Looking for a data point in a report, is like looking for a needle in a haystack.”
“How do I determine if this report is worth reading?”
“There is a learning curve to analyzing these reports that comes with time.”
//Focus + Define
Picking the right problem to solve - Analysis, Synthesis and Connecting Dots
It was crucial to deconstruct the data collected during desk research and interviews, to start connecting the dots and map emerging patterns. Our affinity mapping exercise shed light on recurring themes and pain points.
// Key Pain Points
Lack of consistency
Learnability/Steep learning curve
Need for human guidance
// Uncovering Goals, Frustrations and Jobs to be Done
As we dug deeper beyond the surface level pain points, we discovered the typical journey a policy analyst takes in interacting with a program report document. This also gave us a peek into their goals and frustrations beyond the 'visible' pain points.
Persona
Journey Map
The layers of 'tasks' such as report generation, collecting data, sifting through the noise within the data, analyzing reports, were masking the core job that the policy analyst was trying to do -
"Craft strategic recommendations to positively enhance public policy"
JTBD Diagram
// Insights and Aha! Moments
It was crucial to deconstruct the data collected during desk research and interviews, to start connecting the dots and map emerging patterns. Our affinity mapping exercise shed light on recurring themes and pain points.