How to implement a WIC participant recertification portal

Learn methods to provide a human-centered experience for participants to recertify for their WIC benefits.

The Special Supplemental Nutrition Program for Women, Infants and Children (WIC) is a crucial program that helps pregnant and breastfeeding people, infants, and children under five access healthy food and education. However, the United States Department of Agriculture’s Food and Nutrition Service (FNS) estimates that roughly half of people eligible for WIC are actually using the service. The portion of eligible people enrolled in WIC has decreased in recent years, according to FNS, suggesting that WIC may lose participants when they need to recertify their eligibility.  

Simply put, recertifying for WIC can be difficult, especially for young families that are strapped on time and resources. During a recertification appointment, a WIC participant must show proof of income and residence, get measured on-site or have anthropometric data sent from a physician’s office, and complete a nutrition risk assessment with a dietitian. All of this can take an hour or more and sometimes requires an additional appointment if they forget their documents. 

In an effort to better understand WIC’s enrollment and retention gap and identify solutions to address it, we partnered with Montana WIC to pilot a participant recertification portal (PRP). The 2021 Montana WIC Needs Assessment reported that 6-month and annual recertifications are a time when participation often drops. Therefore, our shared goal was to reduce the burden of the recertification process for WIC participants and staff. 

In partnership with Montana WIC, we researched, designed, built, and tested an open-source portal for WIC participants. The portal enables participants to submit information and documents ahead of their recertification appointment—a necessary step in renewing WIC benefits. We also built a portal for WIC staff to manage participant recertification information and prepare for recertification appointments. With the two portals, we sought to make the recertification process more accessible to WIC participants, promoting retention in WIC.  

We also wanted to establish a foundation for Montana and other WIC state and local agencies to create adaptable, human-centered PRPs. That’s why we developed this toolkit for WIC state and local agencies that would like to implement a PRP. This toolkit outlines technical details, capacity considerations, and production-readiness for WIC agencies that are interested in implementing a PRP.

It’s important to note that this is a technical toolkit, meaning it’s specifically designed for state and local WIC agency staff who have an understanding of their agency’s technology and recertification process. At the beginning of each section, we call out who can benefit most from that section (i.e. WIC state agency leadership, implementation team members, etc.).

This toolkit can help WIC agencies:

  • Understand what the WIC participant recertification portal (PRP) is and what it supports.
  • Assess your agency's readiness to implement a PRP and accompanying staff processes.
  • Understand what it would take to implement a PRP at your agency.
  • Identify the specific changes your agency will need to make when implementing the PRP.

The WIC Participant Recertification Portal

This toolkit offers guidance for adapting an open-source web application that allows WIC participants to submit the necessary information and documents to renew their WIC benefits. It is based on the PRP we built, which was validated with WIC participants and built using a modern Javascript/React framework. We designed our PRP for mobile phone, tablet, and desktop.

We also offer guidance for building an open-source portal for WIC staff that displays participant-submitted information and uploaded documents. We built our staff portal using a low-code tool and validated it with local WIC agency staff.  

A flow chart illustrating the MVP scope.

A flow chart illustrating the MVP scope.

What the PRP can and cannot support 

We designed the PRP to be used by WIC participants (or authorized representatives) who are recertifying for benefits. 

Montana retains documents in their Management Information System (MIS), so they only require WIC participants to provide documents during recertification if something has changed or if the participant doesn't have adjunctive eligibility. Because of this, we designed the PRP to only prompt participants to upload documents if their situation required it. We know that other states do not retain documents and thus require proof of ID, address, and income for each recertification. 

The PRP isn't currently designed to support:

  • Initial certification—we wrote all of the content for clients who currently receive WIC benefits.

  • Situations where someone must complete a self-declaration form, such as zero income, no permanent address, or no identification.

  • Foster parents who just need to provide proof of placement.

  • Languages other than English.

  • Replacing the nutrition assessment—based on research with local agency staff, we determined it didn't make sense to replicate questions CPAs ask during the recertification appointment.

In addition to the PRP, we include guidance for building features that help WIC staff shepherd the participant through recertification.

Determine if the PRP is right for your agency 

For state agency leadership.

Assess the PRP against agency needs, priorities, capacity, and policies

If you're interested in bringing the PRP to your agency, you should first confirm that this tool aligns with your agency’s priorities and that your agency has the team and resources required for a successful implementation.

Determine how the PRP aligns with your agency's priorities 

At this stage, we recommend you review the participant and staff portals at a high level to make sure tools like these align with your agency's priorities. You should then consider how much change, if any, your agency would need to make for this to work. If you expect that your agency would need to make a lot of changes, consider if there are competing priorities your agency would need to balance. We also recommend you tie implementing the PRP to a specific WIC program goal (e.g. increasing retention, improving staff experience). This can help when making the case to others and motivating staff.

Consider the team and resources you'll need 

Once you've confirmed that the PRP fits within your agency's priorities, you should consider the resources required for implementation.

For a successful implementation of the PRP, we recommend identifying a Product Owner within your agency. Leveraging their holistic expertise on your agency’s programs and goals, this person will own the vision and strategy behind the PRP. It's also helpful to identify other people who will participate in decision-making. Remember to include IT staff—in our experience, we often needed involvement from both state and county-level IT staff. A DACI framework can help you document who will be responsible for each role and involved in decision-making. 

You'll also need to identify the team that will implement the portal. Your team may include a vendor, in-house staff, or a combination of both. Based on our experience, you should expect the following kinds of roles in addition to a Product Owner:

  • Program and/or policy subject matter experts, who can identify changes to make the PRP work for your agency.

  • Engineers who can implement the product.

  • Local agency staff who will support workflow changes that the PRP introduces. We recommend identifying one staff member from each participating local agency that can act as a point-person. 

  • Optional, but having expertise in user experience design and research can also be beneficial. In addition to testing our PRP with Montana WIC recipients, we partnered with a designer/user researcher to ensure that our portal met Montana WIC’s specific needs. 

Confirm your agency’s capacity for this project 

The final step to determine if your agency is ready to implement the PRP is to confirm you have the capacity for this project. Make sure you have the staff capacity, technology, and budget.

To keep this project manageable, we recommend starting small. Consider implementing the portal as a pilot in one or two local agencies, and then expand from there. This will reduce the number of people required for implementation and require less coordination overall. For example, Montana chose four local agencies of varying sizes to participate in our pilot. 

Plan your implementation

For state leadership and implementation team leads.

We recommend some initial planning to set your PRP up for success. Initial planning doesn't mean your project should operate in a waterfall manner; agile delivery requires planning too. In this phase, you should assess which aspects of the participant and staff portals fit with and/or need updates to work with your agency's processes and workflows. 

This section covers what to consider when planning your implementation. The instructions for how to make specific changes to the PRP are in the next section.

Define the participant experience

First, walk through the PRP and its possible paths. Page-by-page and use case-by-use case, determine which functionality and content make sense or don't make sense for your agency.

In this resource, we outline a high-level user flow through the PRP as well as detailed descriptions of each page, screenshots of each page, and changes states may want to make. We also recommend using this worksheet to define changes you’ll need to make for your PRP.

A chart illustrating a high level user flow of the PRP.

A chart illustrating a high level user flow of the PRP.

Define the staff experience and workflow

Understand staff portal functionality

The staff portal displays participant data submitted via the PRP. Data displays in a table view, which is built in a low-code tool called Lowdefy. We chose this low-code tool to be as efficient with our time as possible and to identify a tool that might save WIC state agencies time and money. 

It’s important to note that we used Lowdefy for the demo staff portal. We don't recommend using Lowdefy at this time for a staff portal in production because it is not mature enough for scale, the documentation is not fully developed, and it requires too many brittle dependencies. However, your agency can still choose to use it or reference it when building your staff portal. 

It's possible your state agency's MIS has the functionality to support the features of our pilot staff portal. If so, you may not have to build a separate way to access participant-submitted information. 

If leveraging the existing Lowdefy staff portal or building one from scratch, consider the changes you've made to the PRP flow and update table headings and cells accordingly.

In addition, the staff portal displays data by agency. Users from agency A cannot view data from agency B, and each agency has a unique staff portal URL. Consider whether these permissions and displays fit into your team’s organization and update accordingly. 

Through our pilot we learned that any staff-facing experience should be able to support:

  • Authentication, to protect WIC participant data.

  • Displaying the data submitted by each PRP user, organized in a user-friendly way (e.g. a table form with one row for each PRP submission). The table should include which local agency the submission is for.

  • Controls so each local agency only sees submissions for their agency.

  • A way for staff to indicate that a PRP submission has been reviewed.

  • A direct integration with the WIC program's MIS, in order to prevent manual data transfer and additional staff burden.

Address staff portal access

You'll also need to decide how WIC staff will access their staff portal. The current implementation requires staff to create accounts and authenticate before viewing participant data. Your agency may want to reuse this authentication, or leverage existing staff authentication for systems at your agency, like Active Directory. 

In addition, consider the potential impact of state network firewalls. You may need to ensure your agency—at both the state and county/local level—does not block access to the staff portal URL. 

Define staff workflow protocols

The PRP would not be useful without the staff portal and accompanying protocols that ensure participants complete their recertification process. With the introduction of these new tools, staff workflows need to be considered and adjusted. 

When implementing your own PRP, you will need to define how state and/or local agency staff will interact with the staff portal and ensure data and documents are transferred into WIC source systems, like your MIS. In the Montana pilot, local agency staff were the primary users and contributors to the staff portal, while state agency staff helped define holistic policies. 

Additionally, consider your state agency's document and data retention policies. For example, if your agency does not retain participant documents in the MIS, you might be able to simplify the participant experience, the staff experience, and workflow. In this scenario, you would no longer need to download and save documents to the MIS. 

Establish protocols for staff outreach to participants

Raising awareness about this new tool increases the likelihood of participant adoption. Identify mechanisms local agencies already use to communicate with participants. Then, use those channels to share the link to the PRP with participants in advance of their recertification appointments. The Montana pilot included appointment reminders sent out via Teletask—which sends SMS text messages to participants—seven days and one day before recertification appointments. In order to allow participants access to the PRP, we included the link to it in this reminder text and asked participants to fill it out before their appointment.

A chart illustrating the protocols WIC staff adhered to during the pilot.

A chart illustrating the protocols WIC staff adhered to during the pilot.

Bringing the PRP to production  

For state technical staff and/or implementation teams. 

Make state-specific changes

Some content in our PRP is tailored to Montana and their state WIC policies (i.e. phrasing, logos, document retention logic, session timeouts). For information on how to alter any of this content, please see the Github repository.

How to host and deploy the portals

We built the PRP for easy deployment. The recommended deployment method for the PRP and staff portal applications is to use the docker containers that are included with our code. Our Github repository includes the Terraform files that we used to deploy and manage all the AWS infrastructure resources we used.

The minimum application requirements are a docker server, a postgresql database, an OpenID Connect provider, and S3. For our deployment, we used cloud hosting with Amazon Web Services (AWS), but any hosting provider that meets these minimum requirements will be sufficient. The exception is that the participant portal is currently engineered to store files in AWS S3; with some engineering effort, this could be replaced with another object store.

In addition to the minimum requirements, you will need to include added functionality for security, scalability, and monitoring for a production deployment. For instance, we also configured DNS, load balancers, web application firewalls, and logging. See the Github repository for more details.

Identify and address security, privacy, and compliance requirements

An important step for deploying any kind of software is identifying and addressing relevant security, privacy, and compliance requirements. This includes asking questions like:

  • What are my state and local agency's security and privacy policies?

  • What requirements do I need to fulfill in order to comply with my state's policies?

  • What best-practice protections are necessary to protect the safety and privacy of my participants?

Work with your state's IT and compliance departments to identify the necessary steps for complying with state policies. 

For our project, we leveraged FedRAMP-compliant and SOC 2-compliant services like many AWS services and Google Workspace. We also recommended and complied with the following security best practices:

  • Data encryption at rest and in transit.

  • Storing hashed and salted user passwords, not the originals.

  • Salting browser sessions using an encrypted variable.

  • Limiting production access to resources.

  • Logging access to participant data and production resources.

Finally, we recommend including a user-facing privacy statement in the PRP user flow. This statement should inform people how their data will be used and how your agency will adhere to data privacy standards. 

Finding a web analytics tool that meets state IT requirements

For web analytics during our pilot, we used a privacy-forward web analytics alternative to Google Analytics called Matomo. We wanted to trial a free, open source tool that respects user privacy and data ownership. In addition, Google Analytics did not meet Montana's state IT compliance requirements at the time of our pilot. It may or may not be the right tool for your project. We recommend taking special care to confirm whether your web analytics tool meets your state's IT policies.

Conclusion and additional resources

We hope that you leverage this toolkit to understand what the WIC Participant Recertification Portal is, assess your agency's readiness to implement a PRP and accompanying staff portal, and ultimately implement this in order to improve experiences for WIC participants and staff.

Please share your experiences and feedback when using this toolkit!

Additional resources

Written by

A headshot of Lauren Peterson

Lauren Peterson

Principal Product Manager

Lauren Peterson is a senior product manager at Nava. Before joining Nava, Lauren worked in multiple roles related to public health and healthcare, including as a product manager for a healthcare consulting company and as a medical scribe.

Daniella DeVera

Principal Designer and Researcher

Daniella DeVera is a Principal Designer/Researcher at Nava. Daniella has extensive experience in human-centered design, and she has held roles at General Assembly San Francisco, Code for America, and Apple, Inc.
Nava Logo

Rocket Lee

Principal Software Engineer

Rocket Lee is a Principal Software Engineer at Nava. Previously, Rocket worked at the Electronic Frontier Foundation, an organization defending digital privacy, free speech, and innovation, and spent years as a small business owner.

Makaela Stephens

Senior Designer/Researcher

Makaela Stephens is a Senior Designer/Researcher at Nava. Previously, Makaela worked with California, New York City, and civic non-profits to design and deliver critical services that benefit the public.

Partner with us

Let’s talk about what we can build together.