Improving State Unemployment Insurance Technology: A Guide for Advocates

Introduction

Technological advancements in unemployment insurance (UI) systems are typically viewed as inherently good, but often they are hindered in their ability to improve program access and benefit delivery because they are designed and implemented without consideration for those who use and depend on the system most: claimants. And so while historically, legal aid and policy unemployment advocates have focused their efforts on unemployment eligibility issues, as more and more states implement new technology projects, it’s becoming clear that these technology upgrades can actually create new barriers to benefits that are even more impactful than barriers of eligibility. Therefore, now more than ever, claimant advocates need to be in the room when conversations about technology happen, to ensure that upgrades actually improve equitable access to benefits.

Claimant advocates do not need to be technology experts to engage with their state agency on these UI technology projects. Advocates already have the most important information at their fingertips: the needs of their clients. And so this guide is intended to provide everything else, with a focus on the basics of UI technology projects, guidance on standards for equitable uses of technology, and strategies for how to have a positive impact on these projects.

Background

States have struggled to upgrade their archaic infrastructure to pay unemployment insurance benefits for decades. An earlier collaboration between The Century Foundation, The National Employment Law Project, and Philadelphia Legal Assistance produced a report outlining how states might consider best practices for modernizing the ecosystem that existed pre-pandemic. However, since the rise of the COVID-19 pandemic, massive issues with systems emerged, ranging from antiquated COBOL mainframes from the 1970s to recently completed costly modernization processes that didn’t meet states’ and claimants’ needs. States are now looking to improve their technology in new ways.

Beginning in 2021, the U.S. Department of Labor began providing funding to states for program improvements to promote equity, increase claim timeliness, and fight fraud through a $2 billion allocation from the American Rescue Plan Act (ARPA) of 2021—most of which was set aside for long-term IT modernization. The original guidance on technology modernization would have provided $653 million to states for upgrades. The guidance discussed thoughtful process improvements, moving away from monolithic legacy systems and toward upgrading systems in an agile, modular approach. However, $1 billion of the ARPA allocated funding was eliminated in the debt ceiling deal that Congress negotiated in June 2023. Now, funding for those activities is significantly reduced. The new guidance allowed states to apply for up to $11.25 million each for modernization efforts, but only until the remaining unspoken-for funding is available, which amounts to $204 million. The states who will be able to receive that funding were announced September 23, 2023.

Over the past two years, many states have received equity grants as well as technical assistance from Tiger Teams to improve processes, and seven states have even gotten funding to work with community groups to help underserved communities navigate the UI system. States have been improving their processes and their understanding of equity quickly in the past two years, and advocates have been playing an increasingly important role in helping to inform states about where workers still either have trouble applying for and receiving benefits, or trouble even attempting to apply in the first place. While state agencies had gotten an influx of funding through ARPA funds and increases in base administrative funding the past two years, more is needed to make up for the many setbacks systems experienced during the pandemic, from the loss of experienced staff to overtaxing of physical resources. States have been working hard to cobble together solutions, whether they are still using a monolithic legacy system or have more modernized technology.

States have options moving forward, and there are pros and cons to various methods of improving technology. This guide will help advocates to understand state structures, their options, and requirements to understand where they can best help states improve access for claimants. Now more than ever, improving the systems that run UI will require an all-hands-on-deck approach, and advocates must be ready to heed the call.

Chapter 1: How unemployment insurance systems get made

Government unemployment insurance systems are complex; let’s go shopping

For several reasons, mainly to do with outsourcing and a misguided understanding of what governments should have as core competencies, most governments buy (procure) their technology from vendors.

In your state, you’ll be in one of three stages: planning, design, or implementation.

Planning

Planning is the stage where your state will be busy gathering requirements: what the new, modern system is supposed to do. It will probably be described as making everything magically better, faster, and cheaper.

What are the typical requirements? Requirements are everything from “must interface with this database” to “must print letters,” from “notify claimants about correspondence” to “prevent fraud.”

Setting and checking requirements is very tricky.

Your state will also let vendors know their rules about how the new system must be made.

The planning stage also includes the state figuring out how it’s going to buy the new system, letting vendors know they’re going shopping (issuing a solicitation or a request for information, known as an RFI) and choosing a lucky partner (evaluating bids).

Later on, we’ll discuss how to influence the planning stage to increase your chances of getting a modern, user-friendly, and equitable unemployment system.

Design

Design is part of the development stage. This is usually the stage where there’s the most opportunity to improve a system. During this stage, a tip for talking to intransigent vendor representatives or state employees might be this Steve Jobs quote:

“Design is how it works.”

And also part of this stage is the opportunity for you to then explain why what you’ve been shown doesn’t work.

Implementation

Implementation is when the new system is installed and ready to start working, at which point it begins to be used in place of your old system. At this point, most states have already turned off the old system and turned on the new system. However, in the ideal practice of agile development, the new and old systems would work side-by-side. Unsurprisingly, implementation is when you’re likely to find lots of bugs.

How do government technology systems get made?

There are two main ways that technology¹ gets made, whether in government or the private sector. The two main ways to develop technology are known as waterfall and iterative.

Waterfall development

Waterfall development is when what the software needs to do is very clear up-front, and isn’t expected to change. This is, broadly, the kind of process that organizations that can afford it, like NASA, use to develop giant space telescopes. Done well; it’s very expensive, takes a long amount of time, and the software works great.

Waterfall development looks like this:

• You don’t see much progress for a long time.
• You see a large launch or release with a lot of functionality; an example of a lot of functionality might be “a whole module.”
• Updates to the software are infrequent (no more than four times a year).
• Because of this, there are few opportunities to provide feedback and change the plan.
• Updates to the software take a long time.

Up to this point, the vast majority of UI agencies have engaged vendors that use waterfall development.

Iterative development

Iterative development is sometimes also agile development. Iterative development is where you make usable pieces of software as you go and get feedback from real people who use it day-to-day.

Iterative development looks like this:

• You see regular progress, in the best cases, every month.
• The progress you do see is probably small; an example of a smaller piece of functionality might be “improving document upload.”
• Even smaller changes like labels and help text happen quickly (maybe within a week!).
• There are frequent chances to provide feedback, and it’s easier to change the plan because the chunks of work are smaller.

Iterative development seems great, so why don’t we use it for everything?

The main reason why governments and large organizations choose a waterfall method is that they’re wary of taking on a high level of project management, and they don’t have any other alternatives. This also might be the only way their state structure allows them to work.

Projects such as modernizing unemployment insurance systems cost tens or hundreds of millions of dollars. Nobody wants to make a mistake, such as making something that doesn’t work, doesn’t do everything someone wants (whether they’re a claimant, a government worker, or more), or doesn’t even do the basics of what someone needs.

So the alternative is to double down: this time, procurers will try even harder to understand all the requirements first. This time they will work harder to vet the vendors and make sure they get the most experienced vendor.

But anyone who has done technology procurement over the years has learned two important things about making software. First, things change. Second, it’s impossible to predict the future in order to avoid making mistakes.

Iterative development is a way of discovering mistakes quickly and frequently. By doing smaller chunks of work that can be tested often, developers can catch mistakes when they’re smaller. Smaller mistakes are usually easier to fix!

The other reason why governments keep making software in a waterfall way, trying extra hard and making longer and longer lists of requirements up front, is that they don’t practically have any alternatives. Experience has been hollowed out. Governments can reasonably be risk-averse regarding trying to do something in a new way.

Ultimately, governments that have made technology using an iterative approach have been ones with solid political support. Using a new method of doing something means you’ll make mistakes, so new methods are most often tried and most often successful when support is visible and persistent.

One way technology can be made is by using an approach called user-centered design or human-centered design. There’s a lot written about it, but it’s quite simple.

User-centered design is a way of making sure a system does what the people who use it need.

It’s the difference between imagining what someone needs and what will work against finding out from them what they need and what will work for them.

Here are some signs that a project is practicing user-centered design:

• The team regularly does research with the people who would use the system to find out what they need and are trying to achieve.
• The team researches how people accomplish tasks, where they get stuck and suggests improvements.
• Those improvements are made and the team researches whether the improvements worked.

For example, a project that says it’s using user-centered design wouldn’t produce notices that are hard for claimants to understand. It would test its notices with real claimants and adjust them—frequently—based on feedback. In addition to testing the project with real claimants, project teams should also seek feedback from claimant advocates, who interact with a broad group of claimants and who themselves also have to navigate the system.

It goes without saying that much government technology isn’t user-centered. Part of the problem is because a great unemployment insurance system isn’t really about user-centered technology but about user-centered government.

Who makes government software?

Vendors you might be used to

There are some common vendors that make government software who you might be used to or have heard of. In the field of vendors who work on unemployment insurance systems, there’s a small number working with states:

• Deloitte in Colorado, Florida, Minnesota, Massachusetts, and New Mexico;
• Fast Solutions’ Fast UI in Alaska, Hawaii, Illinois, Montana, and more;
• GSI’s Geographic Solutions Unemployment System (GUS) in Louisiana, Nebraska, Pennsylvania, Tennessee, and more;
• Sagitec, in Kentucky, Maryland, and Ohio; and
• TCS (Tata Consultancy Services) in Connecticut, Maine, Mississippi, Missouri, New York, and more

These are what you might call traditional government technology vendors, most of whom have worked with the government for decades. Some of them are large multinational corporations. They commonly work with multiple states.

New vendors you might not have heard of

After 2013, a new set of vendors emerged after problems with healthcare.gov, the website for the newly launched Affordable Care Act.

These new vendors are often staffed and founded by people from the technology industry whom the federal government drafted in to fix the healthcare.gov website. Some of these vendors include:

• Ad Hoc,
• Bloom Works,
• Civic Actions,
• Civilla,
• Exygy,
• Nava,
• Pluribus Digital, and
• Truss.

With the fallout of healthcare.gov and the lesson that new approaches, such as user-centered, iterative development, and DevOps,² were needed, federal (and then state) governments became more open to nontraditional vendors who didn’t have a history of working with government. These vendors are now doing more and more federal and state work.

What do these vendors do?

Making government technology is complex and multifaceted. Some vendors are full-service. These might be described as full-system integrators who handle everything, from helpdesk to figuring out how to work with older systems. They might do all of this work in-house with their own staff or contract out some of the work. States have rules about how much work can be done by staff or by contractors.

Now, there are also much more specialized roles that didn’t exist a decade ago. Some of the new work that now goes into developing and running great government technology includes:

• user researchers: people with the skills of understanding and translating what it is that people need, and evaluating;
• content designers and content strategists: people who have the specialist skills of communicating clearly for understanding and action;
• DevOps engineers: people who have the skills needed to support a team making and releasing technology safely, quickly, easily, and frequently; and
• service designers: a kind of designer who concentrates on workflows and processes, advocating to change policy so systems can be simpler, clearer, and faster.

These are just a few of the types of work that are now involved.

So why are so few systems “good,” and why does everything feel so terrible?

Unemployment systems are both complicated and complex, just like most federal programs administered and delivered at the state level. But while something being complicated and complex is a reason why a system like unemployment insurance is hard to deliver well, it’s not—and must never be—an excuse.

This guide has covered a few reasons why governments find it hard to produce great technology: alternative methods are seen as inherently risky, and at the same time, they don’t have guidance, patterns, or the skills to use those alternative methods.

But there are other important reasons, too.

It’s a lot of work to own and manage technology projects well. Government’s usual approach is to implement a system as specified, a sort of checkbox approach. But often, these checkboxes aren’t a substitute for a usable system.

Example: A requirement might be the system must notify claimants about correspondence.

This requirement might be technically fulfilled by the claimant logging in to a website only available during certain hours (and with perhaps a different username/password) and then downloading a PDF that’s only readable on a desktop computer. And so, the requirement is met, but very poorly.

Another challenge for governments is that it’s tough work to specify or describe precisely what a good system looks like, and even more difficult if you don’t have experience in managing great technology projects. If you don’t know what you’re looking for and can’t explain it, you’re unlikely to get the system you truly need, and so it will be tough to manage it!

Furthermore, what’s good in one situation isn’t in another. In other words, asking for “good” isn’t helpful: it’s too abstract. Part of this guide is to help you be more precise when and where needed, so you can guide system modernizations.

User-centered design as an approach helps make sure that requirements—“good” requirements—are contextual and that they relate to a particular outcome. Those outcomes need to be rooted in what people need.

Sometimes, things aren’t what people say they are

Generally, everyone in government is trying to do the best job they can. Over the past few decades, government has mostly outsourced the technical knowledge to understand and manage complex technology projects, and UI agency funding dwindled to a fifty-year low just before the pandemic, so consider that state staff might not have the experience, time, or knowledge to hold a vendor to account. They may also, bluntly, lack the political cover to hold a vendor to account.

A vendor may say that they are doing user research, but they aren’t.

A state and vendor may claim that they are working in an iterative way, but they aren’t.

(Also: If you held a vendor to account, what then? If you didn’t have a viable alternative, then you have no choices anyway).

The U.S. Department of Defense’s Guide to Detecting Agile BS (really) is a plain spoken, detailed document aiming to help people spot when a project isn’t agile or iterative, even when the government or vendor protests that it is.

Chapter 2: Mapping the ecosystem

Key roles in IT development

The advocate’s role is not to be a technical expert

A key hurdle for many advocates in engaging with states on technology issues is that they may feel like their lack of technical expertise is too limiting to bother engaging. While it is critical to acknowledge information gaps and that the state and any experts they hire may know technology better than advocates, there are things advocates experience on a daily basis that can improve both the process and outcomes.

Find out who makes the big decisions and who does the work afterward

The first step to figuring out how to influence a state’s technology modernization efforts is to figure out where decisions are actually made. In some states, UI administration falls within a workforce agency, some are at the state Department of Labor, or it could be in a completely different agency such as the Department of Education. Similarly, the technology powering UI appeals might be siloed within the UI system or part of a larger state structure. Decisions about UI technology may rest with the Office of Unemployment Insurance, the larger state agency it is housed in, or somewhere else in state government such as a procurement office or central management division. Even in cases where the state procurement agency does not make the final decision, there may be statewide procurement policies that impact decision making. Finance or budget agencies are also likely to play a role in technology modernization. If the project is relying in part on state funding, the legislature may also lay out certain processes and requirements.

Developing relationships with key decision makers is critical, but often those people are not the ones who will be managing the project day to day. Even after key decisions are made about the shape and scope of a technology project, ensuring advocate perspectives are included in day-to-day decision making can have a profound effect on claimant experience. Ideally, product and project managers are routinely working with agency legal teams, subject matter experts, finance teams, and other internal stakeholders. The more that advocates understand how decisions are made and work gets done, the better they can help influence the ultimate product. Ideally, advocates should have direct communication with project managers and project core team members so that they can give immediate feedback on the system during the design phase, and vitally, they can inform the project team of system issues they see once the system goes live.

Who is responsible for IT?

Government-wide IT responsibilities vary. Consulting with advocates in other public benefit programs could help to build an understanding about innovations or challenges that could have cross-system implications. Even in the case that the state has little or no collaboration across IT departments, sharing information locally can have advantages. Also, anything that can foster collaboration is key to the long-term goal of interoperability. That is to say that ideally, at some point, states should have an eye toward systems sharing information to ease application across programs. For example, once a person applies for UI, eventually it would be helpful if claimants could then be notified about other programs they could be eligible for, and have some basic information from their UI application migrate to start applications for other applicable assistance, if the claimant is interested. Increasingly, states and federal agencies are considering making this a requirement, so it is also to the agency’s benefit to consider this issue sooner rather than later.

Once government-wide IT is mapped to the greatest extent possible, advocates should figure out what is within the power of the UI agency as far as IT is concerned. UI agencies generally do have technology leads, but often that team is tasked with both the day-to-day operations of their internal IT, as well as public-facing technology and coordinating technology procurement. If a state is operating on a legacy mainframe system, they are likely to have programmers on staff. That is less likely if they have purchased a Commercial Off-the-Shelf (COTS) technology solution, which is the kind of product that most states with modernized systems have purchased. They are large systems developed by a vendor and deployed generally all at once, loosely based on a standard operating system that they customize to account for differences in state laws.

Know your legislature

After understanding the agency and the state, it is also important to map out other spheres of power where advocates may be able to influence the process. One obvious area is by determining which legislative committees in the state would have influence over the process. While most UI administration is funded by the federal government, state funding for UI technology may be allocated by any number of legislative committees depending on the state—it could be a committee on Appropriations, Budget, Finance, Ways and Means, or Labor. There will also be a policy committee of jurisdiction that will have interest and influence with the UI agency. It is important to keep track of where in the budget and legislative cycle input is most useful, but generally getting issues on legislators’ radar is critical in the very early days of a legislative session and then following progress throughout the session.

To the extent that advocates are permitted to interact with policymakers, it is important for them to understand that IT modernization is an extensive undertaking. Since 2020, policymakers are generally acutely aware of what happens when technology fails, as they were likely around during the height of the pandemic to guide their constituents through the major challenges of filing a claim with the UI system. The most critical thing for lawmakers to understand is that resourcing a project adequately goes beyond funding—the state UI agency has to have the human capital and talent acquisition authority to manage the work and everyone in the chain of command referenced above need the time and resources to engage as deeply as necessary to keep the project running. It’s also important for funding to be flexible over a span of several years, to help the agency hold vendors accountable by slowing payments if deliverables are not met. These projects should ideally be undertaken in a timeframe that is likely to span changes in political leadership at the top of the executive branch, so to the extent that the legislature can empower the state agency to continue the work, the better it is for the underlying system.

Talk to the media, even if only on background

Local news media is also a major lever to manage technology implementation. One of the issues that gets press even when unemployment is low is either exceptional or poor management of major IT projects. Technology failures similarly garner press attention year round. At the same time, reporters are often looking for claimants to talk with when they write stories about why UI and UI technology matter. For these reasons, working to develop and maintain a good relationship with reporters covering this issue can also help advocates expand their influence. During economic downturns, reporters are looking for compelling, real people to talk with, so maintaining a list of stories can help in that regard. If policymakers and the state agency know that a particular advocate has relationships with the press, it can help with influencing the direction of decision-making in the state. If you have been tracking issues with your current UI technology system, developing a white paper with key points and client vignettes is a good way to get information out to the media to help establish yourself as an expert in the area.

Make friends!

Another key set of players are other advocates in this space. Legal aid or legal services have direct hands-on knowledge of issues that low wage claimants in particular face. Community affinity groups that work with particular racial or ethnic populations will be invaluable at providing access to a diversity of potential users. Unions are particularly key allies in their expertise in UI, access to workers, and familiarity with the legislative and regulatory process.

Unions are also at the crossroads of claimant experience and worker rights when they represent the front line workers who work for the state UI agency. US Digital Response user experience expert Marcie Chin refers to front line workers as the “cheat code” for understanding where workers are having challenges. Generally, if a state agency workforce is unionized it will either be with the Service Employees International Union (SEIU) or the American Federation of State, County, and Municipal Employees (AFSCME). If you do not have a relationship yet with the front line staff union, it will be important to reach out to leadership to schedule a meeting. Front line staff will share most of your concerns and they have a front row seat to how current technology is working as well as how training and change management is underway on a new project. They also may be able to share information with you that you otherwise could not access.

Know the vendors

There are a handful of vendors that work in this space, and often state requests for proposals require that vendors must have deployed a UI technology product in the past, so that limits the pool of options. It is important to have some basic understanding of vendors in this space and their products. While preparing this guide, the authors completed walk-throughs of claimant experience with various vendors and their products. The more you know about the vendor and what they have done well, and poorly, in other states, the more helpful information you can provide to your agency.

In addition to standard technology vendors, there are entities that states can engage with that are more centered on user experience, such as Nava PBG and Truss. There may also be local vendors worth researching. It is very much worth mapping vendors to understand what kinds of products and user experience a new system can expect. Finally, if your state is already working with a specific vendor, it is worth getting to know that vendor. It may have someone devoted to stakeholder management or advocate outreach. Developing any relationship possible with the existing vendor is valuable.

Finally, paraphrasing the serenity prayer, it is important to change the things possible, accepting limitations due to being on the outside of the process, and knowing which are which. Claimant advocates are invaluable experts on claimant experience. As mentioned elsewhere in this document, front line agency workers probably have some of the greatest insight into the intersection of claimant challenges, changes possible, and how to get there. Keep in mind that they may lack the ability to share that information outside of their agency. Everyone involved in this process is important. Advocates are not expected to become overnight technology experts, but the technology experts should also know where their knowledge of UI subject matter expertise is thin. The key to influence in this process is knowing one’s strengths and not over-representing them.

Government employees have ethical and legal constraints

Speaking with government officials can be tricky. Individuals in government positions are not going to be able to express their personal opinion on matters. Whatever good ideas they may have need to be vetted by finance teams, legal teams, IT teams, and other subject-matter experts before they can be freely shared. It may feel like government officials are being coy when advocates ask questions, but it is likely genuinely the case that a consensus answer is not available yet. Communication that feels like a one-way street is not necessarily a bad thing.

One key thing to keep in mind when dealing with any government agency is that they are going to have constraints about what they can and cannot do and how they can engage with advocates. Often, formal regular meetings are subject to formal meeting rules, which could involve public notice and open participation.

At the federal level, formal meetings where groups come to consensus about issues are subject to the Federal Advisory Committee Act (FACA) rules. The creation of an official FACA group is a timely and arduous process and all meetings must be publicly posted in the Federal Register one month in advance. A group that can be deemed to be functioning as a FACA group but not following the full set of rules is a major ethics violation. Many states have some kind of similar limitations. Government officials must maintain objectivity and cannot share information on a preferential basis with certain groups and not others, so advocates should expect to only get publicly available information from government officials. Any communication with outside groups is generally available to the public upon request.

Finally, no state official will want to share information that could potentially open their state up to litigation. Advocates will need to be aware of all legal, ethical, and practical encumbrances that state agencies face. This is important to understand not just in order to foster appropriate communication, but to understand that a lack of communication or inability to meet may not be due to a lack of goodwill or good intentions.

Assume everyone is doing the best they can

It is understandable if advocates have a contentious relationship with state agencies. After spending forty or more hours a week seeing how systems do not work for claimants, it is easy to see only the system’s deficiencies. However, engaging with a state to improve systems will require good faith on both sides. It’s best to start with the assumption that if the state is engaging with you, it is acting in good faith—particularly given the limitations and constrictions outlined earlier in this guide. Also, there is a relatively good chance that issues you have noticed are also things that they have surfaced and are working on.

It is also important that once you are collaborating with a state agency that you keep the details you learn as part of that collaboration in an internal loop. One of the most counterproductive and alienating things that an advocate can do is find out what an agency is working on, make a public statement calling on the agency to undertake the initiative it has already started, and then try to take credit once the agency completes the initiative. It is important for advocates to make sure that their involvement is additive and not extractive. An honest partnership where one partner is not going to either the courts or the press with details of things that they are collaborating on is essential. Once a successful product is deployed, sharing credit may be appropriate. The exception to that is if agency leadership want to do something but don’t feel like they have the political cover to do it. In those situations you may be able to work with them to create the external pressure they need to get approval for the actions they want to take, but these types of coordination must be explicitly discussed and agreed upon first.

Internal government processes are always more complicated than those outside of government can imagine. Something that seems simple, like changing a number or a slight tweak to a question in a form often has legal, financial, and technical implications. Government bureaucracy may seem like a hurdle, but often it is your friend. It moves slowly to make sure that core laws are followed and all angles are considered when making decisions.

Chapter 3: Understanding technology allies and resources in government, nonprofit, and academic spaces

Technology allies and resources in federal government

U.S. Department of Labor

In May 2021, Congress allocated $2 billion to the U.S. Department of Labor to improve timeliness and equity and fight fraud in UI benefit delivery. With equal pressure to divide up the funds among states and distribute as block grants on the one hand, and keeping it to develop central modular technology solutions on the other, the department allocated about a third of the funding for immediate grants and technical assistance to immediately improve processes and held the rest for technology modernization. Unfortunately, in June 2023, just after the department issued guidance to states to use a significant portion of the funding for technology modernization, Congress passed a debt ceiling deal that eliminated $1 billion of that funding. As a result, the department has had to revise that funding, issued a new grant process, and awarded funding to nineteen states. However, the department established two new offices to help states struggling with technology modernization. Within the Office of Unemployment Insurance, a new Division of Innovation Support was added to help states implement new technology. The Office of Unemployment Insurance Modernization within the Office of the Secretary was established in August 2021 to manage all of the ARPA spending including the technology modernization aspects.

Throughout government two organizations are focussed on improving technology across the federal government. They are the U.S. Digital Service, and 18F.

The U.S. Digital Service

The U.S. Digital Service (USDS) is an arm of the administration. It typically works with federal departments or agencies on high-profile, sensitive projects.

You probably won’t encounter USDS much, if at all, during your work. What USDS will probably be most useful for, especially in an environment respectful of hierarchy, is as an appeal to (well-earned and valid) authority.

USDS has written a Digital Services Playbook for government technology. Its thirteen “plays” are principles for building modern government services, drawn from successful private sector and government practices.

There’s no good reason not to follow USDS advice.³

18F

18F is a consultancy and technology vendor inside the federal government. It’s part of the General Services Administration (GSA), as an office in their Technology Transformation Services (TTS), which means 18F is intended to support the basic functioning of federal agencies.

Unlike USDS, 18F is a service that federal departments—and states—can call upon to help with technology projects. They’re required to charge for their work, so your state can’t get much help from 18F for free.

18F offers a range of services. The main areas where 18F is likely to be of interest and use to you are:

• acquisition consulting, where they can work with a state to assist with a modern procurement process; they’ll help a state do user research (for user-centered design), help draft a solicitation, advise the evaluation panel, and provide support during kick-off; and
• making prototypes (which 18F calls ”experimenting and iterating” on their website), where they will introduce and use a user-centered approach to experiment and validate (test) with real users what’s needed for a modern unemployment insurance system.

Alongside consulting, 18F also publishes guidance.

For you, one of its most useful publications is the 18F De-risking Guide to delivering successful software projects, which includes a section on state software budgeting.

For those more interested in the details of government technology, 18F has produced a number of guides aimed at practitioners, covering topics such as accessibility and agile (iterative) development.

As a reminder, it’s not reasonable to expect you as advocates to be an expert at any of these technology topics.

If you want to effectively advocate for better systems, it is reasonable, though, for you to be aware of the broad principles of a modern unemployment insurance system, so that you can refer your state to organizations that can provide direct technology help and guidance.

The Technology Transformation Services hosts an excellent guide on how states can work with 18F.

Nonprofit volunteer organizations and academic resources

There are other resources you can call on directly or refer your state to for help or educational resources.

U.S. Digital Response

U.S. Digital Response is a nonprofit volunteer organization staffed by technologists. One of their areas of expertise is unemployment insurance systems. Among others, they’ve worked with the Kansas Department of Labor, Washington State’s Employment Security Department, and the New Jersey Department of Labor

U.S. Digital Response can provide help in:

• improving the claimant experience,
• providing plain language and translation support,
• reducing call center volume,
• automating fraud and risk management,
• evaluating vendor offerings,
• streamlining vendor onboarding at the start of projects, and
• language access for workers with limited English proficiency

They also publish guidance on:

• multilingual retroactive Pandemic Unemployment Assistance (PUA) eligibility resources for state workforce agencies;
• additional methods of customer support, such as online appointment scheduling and chatbots;
• identity proofing; and
• system modernization.

You can contact and request support from U.S. Digital Response directly.

The Beeck Center

The Beeck Center at Georgetown University is focussed on improving systems such as unemployment insurance that are the foundation for daily life.

Their Digital Benefits Network hosts communities of practice, including the Unemployment Insurance Technology Coordinating Coalition, the Best Practices Working Group, and the Benefits Eligibility Rules as Code.

Some of their most useful publications for you are probably:

• an introduction to digital identity (PDF);
• a report on Digital Identity in Public Benefits Applications (PDF);
• and perhaps most helpfully, a Digital Identity Glossary (PDF) for you to refer to.

Their Digital Benefits Hub is like a reference book and encyclopedia for a wealth of detailed and specific information on many useful topics. The information in the hub comes from a range of sources, from academic articles, to government guidance, to case studies.

Chapter 4: Plain language, translation, and equity

The process

As with the ideal state of overall IT modernization, the start of a plain language project should involve looking at the entire process. Similar to mapping technology and business processes to prioritize projects, states should also take a look at all of their communications and determine which forms may be combined. Reducing the number of notifications and forms that are sent out or requested can save states millions of dollars and reduce paperwork burden and confusion for claimants. Then, states have to prioritize which forms should be rewritten. States can choose to prioritize most commonly used forms, forms that are most critical to claimants getting access to benefits, forms that are currently reported to be the most confusing, or even claims and communications that claimants are likely to see earliest in the process. In New Jersey, for example, the first form the state simplified was the weekly certification. Because other technological limitations meant that claimants only had a thirty-minute window to certify every week, this became an early priority.

Be there from the beginning

Advocates can be particularly helpful at the outset of a plain language review, as they will have key insights into which forms are creating the greatest hurdles for their clients. It could be helpful for claimants to proactively identify claims, terms, questions, and notifications that have created the greatest challenges for their clients, as well as offering suggestions about combining communications. It is also helpful to flag places where states might want to offer some context about why a question is asked of them. States are increasingly adding pop-up text and even videos to their online forms to explain what questions mean and why they are being asked.

The rewrite

The next step in the process is actually rewriting forms and doing user testing. The U.S. Department of Labor has an excellent toolkit, a lexicon, and some sample forms available on their website. Ideally, in user-centered design, testing the user experience (often abbreviated as UX) is an iterative process. That means that states do not simply have users review a form and make suggestions and then make a set of edits in response to that and then deploy the new form. Instead, the state should make an attempt at rewriting the language in a more understandable way, have internal reviews with their legal teams, and then bring the language to a small number of users to see how they react to the forms and test whether they understood the communication. Then, the communications are tweaked and presented to additional users until the product is refined to the point that the agency can be relatively certain that materials can be understood by claimants from all backgrounds. The selection of users for this testing should be intentional to make sure that claimants from all underserved communities in their state are represented. Similarly, when states do language interpretation, they should make sure that language speakers from many dialects of that language are able to participate. Finally, it is critical that users who participate in testing are compensated. This is not just fair, but helps to ensure diversity in participation.

This is where advocates can play a critical role. First, advocates are usually themselves well aware of where claimants get confused by communications and the process to help focus initial UX preparation. Secondly, of course, advocates have access to their own clients and allied groups from which participants can be drawn, which helps the claimants and the UX team alike, because some groups and individuals who most need to provide input are wary of the government and are more likely to participate if they are approached by a trusted community group. Finding participants in this way will also help to raise awareness about UI in communities that are less likely to consider applying for UI in the first place.

This is also why it is critical that UI advocates develop relationships with community partners (see chapter 2). The most successful interventions to increase community engagement with UI has involved a coalition of unions, legal aid or legal services, racial and ethnic advocacy organizations, poverty reduction organizations, disability rights groups, and other organizations representing workers who are underpaid. Two-way communication here is critical so that UI experts better understand communities in their state and so that those communities learn about UI from knowledgeable allies.

As states across the country modernize their unemployment insurance systems, stakeholders need to evaluate the accessibility of these systems, which have historically embraced one-size-fits-all technological solutions and leaving behind a claimant-centered approach. In particular, claimants with limited English proficiency or who have a disability face some of the greatest barriers in accessing benefits within systems. Advocates can influence development of these technologies to make them more equitable by engaging with state agencies throughout the modernization process. The good news is that the U.S. Department of Labor has been engaging with states in multiple ways and identified best practices to ensure access. Many of their findings and suggestions can be found at this website, which outlines not just artifacts to improve access, but structures that can ensure continuous improvement over time.

Translation

What are the requirements?

Federal legislation and regulations require that claimants with limited English proficiency (LEP) be provided “meaningful access” to state unemployment insurance benefits.⁴ This means that interpretation services should be provided “at the time and place that avoids the effective denial or the imposition of an undue burden on or delay in important rights, benefits, or services to the LEP person.”

The shift to web-based UI systems—where website text is displayed in English as a default—has posed challenges to LEP claimants. However, federal regulations require that reasonable steps be taken to ensure meaningful access for these claimants, for example: assessing claimants to determine language assistance needs and providing “written translation of both hard copy and electronic materials.” Vital information, which in the UI context includes “applications for benefits, notices of rights and responsibilities, and communications requiring a response”—must be translated, whether oral, written, or electronic. Additionally, language assistance services must be accurate, provided timely, and free of charge.

What should advocates ask for?

Advocates seeking robust translation support for claimants should push to ensure that:

• applications for benefits identify the claimant’s preferred language;
• website text, including the application, is translated into “common languages;”⁵
• vital information—including all notices affecting clients rights, such as notices of adjudication and other appealable forms—is translated into a claimant’s preferred language;
• a dedicated LEP phone line is established to provide translation services, have claim questions answered, and troubleshoot difficulties with the system; and
• RFPs and contracts with vendors explicitly spell out accommodations for LEP claimants.

Advocates should note that states should not rely on machine translation (the use of free online translation services) for translation services, as such usages are often insufficient to provide an understandable translation to claimants

How have advocates in other states achieved these goals?

Advocates have pursued multiple avenues to engage the state agency and vendor about providing access to LEP claimants. Some effective avenues include:

• Demand letters: One early option is to send a demand letter outlining the needed changes to improve access for LEP individuals to bring their state’s UI system into compliance with laws and regulations requiring access for LEP claimants.
• Leveraging U.S. Department of Labor Equity Grants: Advocates can connect with their state’s equity grant projects to provide feedback to the agency about LEP access.
• Leveraging U.S. Department of Labor Tiger Team recommendations: Many Tiger Team engagements have identified improved LEP and disability access accommodations and are still implementing recommendations.
• Collaboration: Establishing standing boards with underserved communities either formally through legislation or informally to regularly discuss technology, communications, and process improvements to help claimants.
• Litigation: Using protections in state and federal law, litigation can be an effective way to push for greater access to the UI system for LEP claimants. In New York, the National Center for Law and Economic Justice, the New York Legal Assistance Group, and Make the Road New York filed a federal civil rights complaint to the U.S. Department of Labor against the New York State Department of Labor detailing the department’s failure to provide LEP claimants with meaningful access to unemployment insurance. A copy of the complaint can be found at https://nclej.org/wp-content/uploads/2023/05/NYS-UI-LEP-Title-VI-Complaint.pdf.
• Engaging lawmakers: In Washington, the Unemployment Law Project received a grant from the Legal Foundation of Washington that allowed them to work with a lobbyist to promote several bills. Recently, they lobbied for a dedicated phone line for LEP claimants (as well as claimants with disabilities and those without access to computers) that became part of Washington Senate Bill 5193.

Claimants with disabilities

What are the requirements?

Federal law and regulations require states to ensure equal access to unemployment insurance benefits for individuals with disabilities. Where UI is provided via web-based systems, the technologies used must have accessibility features for claimants with disabilities and must “ensure that opportunities and benefits provided by the electronic and information technologies are provided to individuals with disabilities in an equally effective and equally integrated manner.” Additionally, states may have laws, regulations, or accessibility policies prohibiting discrimination on the basis of disability and mandating that state websites accommodate citizens with disabilities. Best practices for disability access can be found at the Web Accessibility Initiative’s Web Content Accessibility Guidelines (WCAG).

What should advocates ask for?

Advocates seeking to improve the claims process for people with disabilities should seek to ensure that:

• applications for benefits identify a claimant’s disability;
• UI websites are compatible with different forms of assistive technology;
• claimants are allowed non electronic means of accessing benefits;
• claimants with disabilities can access user-tested accommodations throughout the course of the online application and certification process;
• a separate phone line should be established for claimants with disabilities to request accommodations and receive other assistance, including a TTD line for people who are deaf or hard of hearing;
• claimants with intellectual disabilities are allowed the assistance of a guardian, power of attorney, or other advocate when discussing their claim with agency representatives;
• all user testing includes testing for claimants with disabilities; and
• all communications must comply with Section 508 of the Rehabilitation Act.

How have advocates in other states achieved these goals?

Advocates in various states have sought to improve the process for claimants with disabilities by several effective means, including:

• Establishing and maintaining a working relationship with the agency: One-way advocates have been able to craft relationships with their state agencies by organizing and communicating targeted complaints about legal issues in the UI system. When UI advocates in various states have demonstrated a knowledge of the law and issues facing genuine claimants, they’ve garnered the attention of government and agency officials and sometimes parlay that into regular agency–advocate meetings.
• Relying on local policies: Advocates in New York State leveraged a state policy regarding information technology to lobby for changes to the UI tech system being planned by the agency.
• Litigation: The New York Legal Assistance Group gained the attention of the agency—who agreed to specific fixes—by threatening litigation over policy violations mentioned above.

For more information on disability access to UI, please see this recent publication from The Century Foundation.

Chapter 5: Important considerations on identity verification

Increasingly, digital identity verification systems are utilized at the federal and state levels to screen individuals attempting to access public benefits and programs. UI agencies responding to fraud during the COVID-19 pandemic accelerated the use of these systems. Without an available government solution, most digital verification was done by outsourcing the process to for-profit IT vendors. While the PUA program was at a higher risk for fraud (as was necessary, to provide quick and widespread access to life-saving benefits during a public health emergency), the same risk level does not apply to ongoing benefit programs. Regular benefits are currently subject to more extensive verification standards than were applied to PUA in 2020. As state UI agencies navigate how to integrate identity verification into their systems, balancing that risk with the need for equity and access in the UI system is vital. Unfortunately, the increased focus on digital identity verification over the past few years has not only limited legitimate individuals’ access to critical government benefits but also often failed to address the access concerns of identity theft victims.

Legal Requirements

Under the Social Security Act, an individual is not required to “verify” their identity to be eligible for benefits. The only pertinent requirement is under the Social Security Act:

Section 303(a)(1) of the SSA requires that a state have methods of administration to ensure the full payment of unemployment compensation when due reasonably. In addition, Section 1137(a)(1), SSA, requires states to require the individual to furnish their Social Security Number as a condition of eligibility for benefits. These Federal provisions mean, among other things, that a state must have a system to reasonably ensure that the name and Social Security Number used to establish eligibility for unemployment compensation belong to the individual filing the claim.

A nonexclusive list of acceptable documents for establishing the requirement under Section 303(a)(1) of the SSA is included in Unemployment Insurance Program Letter 16-21.

While states have always taken steps to verify someone’s identity at the beginning of the application process, they generally do not have a statutory provision in their UI law that requires identity proofing. Identity verification can take many forms, some of which are invisible to the claimant and might be in place for claimant protection, such as the process of Bank Account Validation (BAV) that verifies with a claimant’s financial institution that the account their claim is deposited into belongs to them. Identity proofing is one form of verification in which individuals must provide ID documents in person or digitally. This step may or may not be necessary to verify identity. And yet, in some states, identity proofing has been treated as a de facto eligibility requirement to receive UI benefits, often with little legal guidance on what it takes to “prove you are who you say you are.” Unemployment Insurance Program Letter 16-21 includes a non-exclusive list of acceptable documents for establishing the requirement under Section 303(a)(1) of the SSA.

Process for Identity Verification

How should identity verification be done?

• There must be several ways for an individual to verify their identity, including: (1) digital identity verification, (2) in-person identity verification, and (3) identity verification by UI staff through the review of claimant documents that can be mailed/faxed/uploaded
• State agencies need clear and public-facing policies for their standards in the above situations.
• After a claimant’s identity has been verified, the UI technology system needs to have a way to clear the issue from the claim entirely or hide the completed issue from any other staff who may work on the claim later. Otherwise, subconscious biases about identity verification may affect later determinations of the claim.
• For UI agencies that include appeals systems, setting standards for verification at telephone or in-person hearings is vital.

Who should be doing identity verification?

• Ideally, the government should be fully responsible for identity verification and avoid using private vendors. However, most states lack this capability. The three leading vendors in this space are ID.me, LexisNexis, and TransUnion
• Through the General Services Administration (GSA), the federal government offers Login.gov to states for sign-in and identity verification. Be aware that Login.gov also uses LexisNexis.
• Any in-person verification should be done by government UI merit staff.

When should identity proofing be done?

• Identity proofing should not be a blanket requirement for anyone who needs to interact with government systems or apply for benefits.
• The focus should be on preventing payment to fraudsters.
• The risk of fraud must be appropriately balanced with the need for accessibility, equity, and the timely payment of benefits.
• Identity verification cannot be used to “block the front door”—that is, the state cannot require a claimant to verify their identity before they can file an initial application. However, several states do just that.
• U.S. Department of Labor has provided vital guidance in Unemployment Insurance Program Letter 16-21 about when a state can require identity verification in the life cycle of a UI claim:
  1. After an application is received by the state, but before the application is entered into the state’s benefit system (e.g., the state presents ID verification questions and only allows the claim to be processed when the applicant is able to correctly answer the ID verification questions);
  2. After a claim is filed, but before payment is issued (e.g., the state identifies potential ID verification issues during the claim filing process, but accepts the claim and requests the claimant provide proof of ID before payments are made); and
  3. After a claim is filed and payments have been issued.
     1. The state became aware of the ID issue through its normal processes of issue identification (e.g., the state receives information that the individual who filed the claim is not the owner of the wages or the identity used on the claim or the claim is “hijacked” by an imposter after the owner of the wages/identity files a legitimate claim).
     2. A financial institution identifies suspicious activity and contacts the state to return funds.

• Later guidance, Unemployment Insurance Program Letter No. 22-21, Change 2, added breaks in claims series, such as when a claim is reopened during the benefit year
• The U.S.Department of Labor has also strongly encouraged states, in the issuance of $140 million in fraud grants, to use robust identity verification at NIST’s Identity Assurance Level (IAL) 2 and Authenticator Assurance Level (AAL) 2. This means a high level of security in verifying that the claimant is who they say they are and are accessing their own account.
• In April 2023, before Congress rescinded $1 billion of the $2 billion allocated to the Department of Labor through ARPA, the department announced $200 million in additional funding for states to fight fraud and clarified several helpful points in its guidance.
  • States may use a risk-based approach to determine which claimants should be subject to “evidence-based ID verification,” i.e., providing identity documents to the state agency digitally or in person.
  • Fraud prevention, including ID verification, “should undergo continuous review and data analysis for effectiveness and to ensure equitable access for legitimate claimants.”
  • This UIPL encourages states to be cautious about stopping payments based on a single flag and provide claimants with means to resolve issues promptly.

Chapter 6: Is it really a technology issue?

One secret to influencing change in a big technology project is that it’s often not about the technology at all, even when you’re told it’s about the technology.

Instead, like with most things in life, whether a problem is resolved or a change is made is ultimately about whether it’s important, and how it’s prioritized.

Getting to an honest conversation about whether something is important and how it’s prioritized is an important part to understanding what you can change, how you can influence it, and how long that change might realistically take.

An example

Here’s a common pattern of behavior you might have experienced:

1. Someone says something is important (say, Spanish-language translations of claimant communications).
2. From your point of view, it isn’t treated as important (many claimant communications might not be available in Spanish, or availability of translations may be inconsistent instead of complete).
3. What was identified as important shows no real progress over months or years.

This example about language access doesn’t include any reference to technology. Because it’s not explicitly about the technology in a system, you can imagine that the reasons you’re given about the lack of progress won’t be technical either: there’s not enough money, or there’s not enough time.

In this case, you would need to ask, what would it look like if what was important was treated as important?

Following the example above, what would it look like if language access was treated as important?

The answer might include granted budget requests for translators. It might include hiring translators. It might include working with community organizations to test the clarity of translations. It might include following through on a plan for translating a backlog of material. It might include budget and resources for ongoing translation, as a matter of course.

Following these questions to their logical conclusion, who decides what’s important, and who decides what’s prioritized?

People decide what’s important

This heading, “people decide what’s important,” contains a very useful truth.

What’s treated as important is a choice made by someone.

It’s a choice that will be made at employment department program manager, assistant director, director, and secretary levels.

It’s a choice that might be made by a finance committee chair, an IT program manager, an IT department director, or even a governor.

Each of these people has their own context and remit that governs how they make decisions. They’ll have their own considerations about what an effective or good decision is in their role.

For example, while finance committees might be known for not wanting to spend money at all, it’s also true that they want the money they do spend to be effective. Sometimes that might mean a project that looks cheap on paper is going to cost more in the long run because people discover that more is needed to ensure the project’s success. This logic might seem obvious, but there are lots of hidden costs that a finance committee might not be aware of that aren’t taken into account.

When we talk about exposing and understanding the real cost of an effective, modern unemployment insurance system, this is what we mean. People who make decisions with money like to make them with the most information possible. People who don’t have enough experience in managing successful projects may not even know what to look for: they may not know what they don’t know.

Technology is a tool for implementing decisions

It’s important to remember that computer software is a way to get things done. Ultimately, what those things are, are decided by humans.

We’ll get it out of the way like this: technology should not dictate policy, policy should dictate implementation.

In 2023, there should be a very, very good reason for technology dictating how a program works. We’re not in the 1950s, when the rollout and administration of large-scale government programs was designed around the limited technology that was available at the time; we now have myriad choices.

So while it’s easy to label a limit as a technology problem or shortcoming, it’s actually a policy choice.

Another way of putting it is this: the website is the system is the policy.

Chapter 7: Quality data and measuring equity

Quality data about whether unemployment insurance is serving enough people on time and replacing enough prior income is critical to understanding whether the program is performing as it should and if not, where there are bottlenecks that can be addressed. States are also required to maintain and report information about other performance measures, such as decision quality and appeals timeliness. It is difficult to break down most of that data by key demographics when seeking to ensure equity, so one proxy to use when there is insufficient quality data by metrics is to compare overall state performance with overall state demographics.

Even in areas that have data that can be broken down by demographics, it is not necessarily reliable. For example, while the Employment and Training Administration’s data presented in their report, ETA 203: Characteristics of the Insured and Unemployed, could give a picture of the recipiency rate (the percentage of unemployed workers able to access UI benefits), the data set is misleading because of the way that questions about race and ethnicity are asked during collection. First, claimants are usually given a choice between five racial categories and two ethnicities and often cannot select more than one. In addition, claimants are given the option to select an “other” option. Because a significant portion of unemployed workers select that option, it skews the data to the point of unreliability.

Claimant advocates can push for better data in a couple of ways. First, there should be an overall push for better data reporting, which U.S. Department of Labor officials have repeatedly voiced as a priority. The department is not only looking into better overall data reporting by demographic in the long term, but also engaging in data equity partnerships with selected states to improve data collection and reporting.

However, in engaging with states, particularly as they are modernizing their systems, or engaging with vendors on issues such as identity verification, there are two key things that advocates should be working on: data ownership and better public reporting.

Data Ownership

Sometimes when states engage with vendors, it becomes more difficult for states to access and use their own data. Even a willing state that wants to do an access and equity audit may have to pay their vendor to get their own system data, and that may come with a delay. This raises the bottom-line question of who owns public goods and information that is necessary for the delivery of a key insurance program. The first and most important issue for advocates is to press states to make clear their ownership of the data and their need for ease of access from the RFP process onward.

Public Reporting

Ideally, states would have public and easy to understand data dashboards. One good example of a public dashboard can be found in Washington State. However, moving forward, advocates should push for all such data to be further broken out by demographic and zip code. Given the situation with the reporting required by the U.S. Department of Labor, collection of some of these data can be challenging using traditional methods.

It is important for advocates to understand whether their state’s UI technology can measure additional data that impacts equitable access, such as who may be getting through to the application or getting stuck at various points. For example, the section of this paper on ID verification discusses potential equity issues with various products that impact who can even apply for benefits. The Blanket Purchase Agreement developed by the U.S. Department of Labor for identity verification services included requirements around equity reporting, so vendors should be capable of making that data available. In addition, technology services have the potential to measure how long claimants are spending per question on initial applications and weekly certifications, and where claimants may be timing out or giving up. If this is possible, it is something that claimant advocates should push their states to request from vendors or IT staff, and then regularly share out to claimant advocates.

Sign up for updates.

Sign Up

Follow us

Additional Reading

Overview resources

• NELP Recommendations
• Coalition Recommendations for Executive Order
• Oregon Study on Disparate Impact

Resources from the Beeck Center’s Digital Benefits Hub

• Digital Authentication and Identity Proofing in Public Benefits Applications
• Analysis: Digital Authentication and Identity Proofing Requirements in Unemployment Insurance Applications
• Logging In and Providing Proof: A Guide to U.S. Government Actions on Digital Identity

Biden administration fact sheets on plans to address identity theft

• March 2022
• March 2023

Panel presentations addressing digital identity verification

• Pandemic Unemployment Benefits—Where Franz Kafka Meets Fraud
• Creating an AI Bill of Rights for Automated Society

Other relevant U.S. Department of Labor guidance

• Unemployment Insurance Program Letter 22-21
• Unemployment Insurance Program Letter 22-21, Change 2

1. We’ll use “technology” to mean “software” here—the programs that run on computers.
2. “DevOps” stands for approaches that combine “software development” and “operations.”
3. Reasons not to follow its advice include: a lack of time, money, and experience, and a corresponding lack of political will to make time and money available, and a protective environment to develop experience.
4. See Title VI of the Civil Rights Act of 1964; Executive Order 13166; Pabon v. Levine, 70 F.R.D 674, 677 (S.D.N.Y. 1976) (citing Lau v. Nichols, 414 U.S. 563) (denying summary judgment for defendants in case alleging that State officials failed to provide unemployment insurance information in Spanish, in violation of Title VI)
5. A common language is one spoken by a significant number or portion of a state’s population. “Unemployment Insurance Program Letter No. 02-16, Change 1,” U.S. Department of Labor, May 11, 2020, https://www.dol.gov/agencies/eta/advisories/unemployment-insurance-program-letter-no-02-16-change-1.

Tags: unemployment benefits, unemployment insurance, ui technology