Public Benefit Calculation
Public Benefit Calculation
Public Benefit Calculation
Conducting user research to evaluate an antiquated system for a regional government and establish the validity of updating that system.
We explored the world of ancient mainframe computing and the brave individuals who still work with it. A full-scale project to update the system was eventually initiated, based largely on our research findings, recommendations, and prospective designs.
Most of the details of this project are protected information including specific research details, design prototypes, client and user identities.
Role
User Experience Designer
User Researcher
Team
Project Lead (User Research)
Project Manager
Duration
2 months
volunteer
Designing for government often involves solving for very outdated tools and processes.
Designing for government often involves solving for very outdated tools and processes.
Designing for government often involves solving for very outdated tools and processes.
None more so than in this project where we encountered a Linux mainframe system from the 1980s. The green characters and blinking cursors paired with separate spreadsheets require staff to manually enter data. Staff had taken it upon themselves to expand and update their process using the tools that were available.
Adaptability and inventiveness from staff within government.
Staff inherits a system, requirements have changed, and with no budget to update their tools they press forward however they can. These dedicated public servants press on using computers installed at any given time in the past 50 years. Filing cabinets with actual paper documents are a part of the workflow more often than you might think.
The problem was that an outdated and unreliable system was still being used to calculate public benefit payments. Our strategy was to conduct research with internal users and stakeholders to further define the problem and ideate based on that research. The goal was to build a foundation on which a full-scale update could be pursued by creating prospective solutions.
The problem was that an outdated and unreliable system was still being used to calculate public benefit payments. Our strategy was to conduct research with internal users and stakeholders to further define the the problem and ideate based on that research. The goal was to build a foundation for a full-scale update by creating prospective solutions based upon our user research.
USER RESEARCH
USER RESEARCH
User Interview Goals:
User Interview Goals:
Identify all of the actors involved in the calculation process.
- Identify the tools used.
- Describe how the data is manipulated within a process.
We conducted several interviews with the most senior staff member processing claims. With screen sharing and video, we could witness and record the process while conducting the user interview.
We conducted several interviews with the most senior staff member processing claims. These included screen recordings and a live connection allowing us to witness the process while interviewing.
We conducted several interviews with the most senior staff member processing claims. These included screen recordings and a live connection allowing us to witness the process while interviewing.
We conducted several interviews with the most senior staff member processing claims. These included screen recordings and a live connection allowing us to witness the process while interviewing.
Q&A
Q&A
Q&A
How long does it usually take you to process the overpayment?
How long does it usually take you to process the overpayment?
How long does it usually take you to process the overpayment?
How long does it usually take you to process the overpayment?
"I can do ----- in a couple of minutes. A new person maybe 10-15 minutes. If it's a complicated case maybe days or weeks it's in the system."
Can you think of a time when something went wrong in using the excel sheet? What did you do to fix it?
Can you think of a time when something went wrong in using the excel sheet? What did you do to fix it?
"We have to make sure the ---- entries match our entries. That's the one thing we need to manually check. If ----- makes a mistake in the entries there are a lot of emails back and forth. When we ask for amends that's where it can get long. You're just adding more decisions to the claim."
What happens to the claims after you are done making the
------ calculation?
What happens to the claims after you are done making the ------ calculation?
What happens to the claims after you are done making the ------ calculation?
What happens to the claims after you are done making the ------ calculation?
"It will show the ----- We're done with it, We're just done with it. We're the last line of defense."
Workflow Analysis
Workflow Analysis
Workflow Analysis
Documenting and visualizing the data points and the calculation process between the legacy system and the external spreadsheets.
Documenting and visualizing the data points and the calculation process between the legacy system and the external spreadsheets.
Documenting and visualizing the data points and the calculation process between the legacy system and the external spreadsheets.
Documenting and visualizing the data points and the calculation process between the legacy system and the external spreadsheets.
DESIGN
DESIGN
Iterative Phases
Iterative Phases
Iterative Phases
Progression
Iterative Phases
Progression
USER TESTING
USER TESTING
USER TESTING
USER TESTING
USER TESTING
User Testing Goals:
- Test prototypes to see if we're headed in the right direction.
Identify gaps in our understanding of the overpayment process and workflow.
- Compare the experience of using the prototype to the current process.
We conducted two rounds of user testing in a remote setting using screen recording to review the sessions later.
We conducted two rounds of user testing in a remote setting using screen recording to review the sessions later.
We conducted two rounds of user testing in a remote setting using screen recording to review the sessions later.
We conducted two rounds of user testing in a remote setting using screen recording to review the sessions later.
"It seems like it's well laid out."
"It seems like it's well laid out."
"It seems like it's well laid out."
"It seems like it's well laid out."
"What threw me right away is the payment history, and how you differentiate with the discrepancy, but the more I look at it, the more it make sense"
"What threw me right away is the payment history, and how you differentiate with the discrepancy, but the more I look at it, the more it make sense"
"What threw me right away is the payment history, and how you differentiate with the discrepancy, but the more I look at it, the more it make sense"
"What threw me right away is the payment history, and how you differentiate with the discrepancy, but the more I look at it, the more it make sense"
"Theoretically it makes sense."
"Theoretically it makes sense."
"Theoretically it makes sense."
"Theoretically it makes sense."
CONCLUSION
CONCLUSION
Results
Designing for government often involves solving for very outdated tools and processes.
Designing for government often involves solving for very outdated tools and processes.
We gathered rich research data and created a few concepts of varied reach. Upon close examination building a worthwhile application would rely on a far reaching update to the State’s entire back end, encompassing processes within numerous departments.
Screen scraping data was the only realistic way to compartmentalize the project. That is prone to errors, maintenance, and is not a good long-term investment. Eventually a full-scale project to update the the entire system was initiated, based largely on our research findings, recommendations, and prospective designs.
My Experience
This project was fascinating especially from a user research standpoint. This individual example defines our need to update civic technologies, the level of investment needed to update them, and challenges that administrators face working with outdated systems.