Design a self-service system for pantries to verify/update their own info

[fancyham]

LOOKING FOR NEW VOLUNTEERS TO TAKE OVER THIS PROJECT

Overview

As a Pantry and/or Hot Meal location, I want to be able to update my own listing so that I don't have to field calls from Food Oasis.

Details

Some organizations that we have called to validate listings have indicated that if we had a web interface they would update the listing themselves and that they have to answer a lot of calls, so it would be preferable.

Dependent Issues #376 Implement Organization Audit UI #379 Improve Client-Side Validation of Hours #683 Implement Client-Side Validation of Phone Number and Email

Action Items

• [x] Research plan to investigate how best to work with orgs and implement this feature in a way that works for them
  • [x] Consent forms
• [x] Competitive analysis: Google and Yelp, in the Figma file
• [x] Sketch a pilot process flow for sending emails, handling verifications, and corrections.
  • [x] We have a prototype in Figma. Another possibility would be Keynote (free on Apple devices), which is actually an amazing augmented slideshow tool, with hotspots and hypercards.
• [x] Review with existing data validator admins to see if the process makes sense.
  • [x] Jelena reviewed it with @itserindean (Jan 3 2023) and incorporated her comments.
  • [ ] Review of the self-service status flag flow.
• [ ] Do a limited pilot version to validate the idea and find bugs: a low-effort ‘mechanical turk’ of an automated system where it’s actually humans behind the scenes sending emails, doing validations, etc.
  • [ ] Edit mock-up with changes.
  • [ ] Review flow on prototype Mockup email reminder, in the Figma file
• [ ] Design: UI design a full version
• [ ] Engineering: build and test pilot version
• [ ] User test with Admin Volunteer
• [ ] Build full version
• [ ] Create a new issue for the prototype for Data Entry Volunteer (Allows the volunteer to send personalized emails to organizations. Review "P1: Email reminder")

Feasibility

We have email addresses on file for many pantries and meal programs.

How it might work

Rather than having volunteers poll for listing updates, we could send a periodic reminder to those email addresses with a link to their listing, asking them to validate and correct their info, potentially saving many person-hours on our end, as well as raising visibility of the listing on their end.

The email could contain a special link that lets the recipient view and, if necessary, submit corrections for a listing, and perhaps prioritize/mark these specific changes for the Food Oasis admins to review before publishing. If the system works so well that we can validate certain email addresses as claiming a listing, perhaps changes may even be automatic.

If necessary, this link could be time-bounded (expires after a couple of weeks) to prevent abuse.

If we can build this as a module, this type of data validation flow might be useful for other open-source projects as well.

Consider preemptively contacting emails associated with each location and point recipients to a listing for them to confirm it. If they confirm via a link, or with the correct email address, then corrections are given priority.

Benefits to FOLA

Having the food pantries and hot meal locations update their own listings might improve data quality and depth while reducing the need for validation volunteers.

Artifacts created for this issue

• P1: Email reminder 12/02/21
• P2: Email reminder 12/29/21
• Figma (UX designs)
• Miro: Self-service status flag (logic flowchart)

[fancyham]

• See issue #679

[gigicobos]

Attaching PDF with the mock-up discussed during the team meeting. Notes and comments added in the pdf.

FOLA Issue #996 Mockup.pdf

[gigicobos]

I've completed the changes suggested during our meeting on 12/02/2021. Prototype moved to Figma and links to documents added on issue description. To review: I would like to discuss the message modal on page 2: For V1, should we create a feature to allow the admin to edit the message or should we just show a preview?

[ExperimentsInHonesty]

@gigicobos I rewrote the issue to be clearer about what the purpose of the issue is and the title. I also added a link to the figma

[staceyrebekahscott]

Issue #1131 must be completed before work can continue on this issue.

[staceyrebekahscott]

Moved to Icebox as per my chat with Bryan. This fits into a medium to long term milestone.

[staceyrebekahscott]

@sei1122 Assigned to you as per the conversation in the fola Slack channel, and the reprioritization as as per @rylantalerico

[staceyrebekahscott]

@sei1122 What is your time estimate on this issue, given what has already been checked off in the Overview? Do you think you can get this done within the next 2 weeks?

I am adding the heuristics issues to the Prioritized Backlog as it is a priority for the Impact Sprints 2022, so I want to get an idea of when you might be able to pick up your next issue.

And keep in mind we are looking to add more UI-UX people to the project so don't get too overwhelmed at the number of issues that are being moved to the Backlog column, or by all of my questions about the UI-UX issues :).

[sei1122]

This issue takes more than 2 weeks. I need to talk about how far it is done, validate the design, and may need user testing too.

I can take Heuristic issues first if it is the priority. Let me know which issue I should work on

[staceyrebekahscott]

@rylantalerico FYI, as per Seiko's comment above and Heuristics being an Impact Sprints 2022 priority, I am moving this to the Prioritized Backlog. I'd like to get as many of the Heuristics issues handled by the end of August as possible, and then we can revisit this one as a priority in early September.

[staceyrebekahscott]

@jelenaUX @cheesarah I assigned this issue to you as per UX Research Map of Content/ Index

@GigiUxR I'd like to be looped into this as the issue progresses. And if the issue needs more hands, John H might be interested in contributing.

[jelenaUX]

Hi @GigiUxR @staceyrebekahscott @cheesarah as per @fancyham request I am adding a link to some competitive research on a similar self-updating feature from Google -- now all stored in a dedicated file in the Org Research Folder: https://docs.google.com/document/u/0/d/152kjzbXma59_85G9hseZ5AHETb-M7nt4yZAAgyldd7M/edit

[cheesarah]

Reviewed flow with @jelenaUX on prototype Mockup email reminder, in the Figma file

[itserindean]

@yiminng and I were discussing that it might be helpful if this were broken into 2 separate issues, one about the email reminder and one about the organization self-update interface. Upon further investigation i see that this is an Epic issue to track all the parts of this experience so we probably just need a dependent issue about the email reminder.

@fancyham @sei1122 @GigiUxR @staceyrebekahscott - any objections or am i missing something in my understanding?

[staceyrebekahscott]

I would defer to the UX Research team to see if a separate issue is necessary, or if they can track progress within this one.

[fancyham]

It's definitely two parts so I think a split makes sense.

The email self-service flow could certainly work with the current free-form text 'suggestion/correction' interface with minor changes, and that would work as an MVP (minimum viable product).

Making a better 'edit my listing' screen is optional though very nice to have, but it shouldn't be a blocker, and so could be a separate issue.

Even that updated 'suggest edits' form could be done as an MVP as well. (for example, they can view their current listing, and if they want to submit a change, they press a button to reveal a text field that they enter their changes. Upon submitting, the freeform text field(s) could be aggregated into a single text-only suggestion, which is entered into our current 'suggest a correction' flow)

[jelenaUX]

Next steps (from UX meeting notes 12-06-2022): ask Seiko from the design team for a review. And/or talk it through in a design meeting or in a future research team meeting. Make a prototype, either a clickable one or slides, for a test with real users — internal volunteers? Or heuristic analysis w/someone from FO team, or Stacey who can role-play a volunteer from a food pantry, or find a friend who works at a similar type of non-profit, to do “user acceptance testing.” For example, see if all our email messages go to spam, set a flag to say we need to do a phone call if no replies after 5 rounds of emails. After that, review with John Darragh (@entrotech), from the dev team, to see what would be doable and how long it may take.

[jelenaUX]

@fancyham Shall we then make a MVP with the email part of self-service flow? That way we can test whether emails end up in the organization's (i.e.tester's) inbox or spam folder, and set the flag for a phone call if no replies after 5 rounds of email. I think we have a pretty well-documented flow for the second part (listing editing options) but that will probably take much longer to code. I added Screen 20 to set the status flag, but I wasn't sure how to represent that visually. I guess it would be another column in the database? For example, it could be named "Self-update email" and be set to 0, then increased by 1 every time when an email is sent to that organization. If the organization updates the listing, then this status flag is reset to 0. If the status flag goes to 5 (or whatever number we want as a limit), then mark it somehow so we know this organization needs a phone call. And when the FO admin receives some updates, the email self-update status flag should be reset to 0 (Screen 21 but again it's just a placeholder, it does not show anything visually yet). And I guess after a successful phone call, the status flag can be reset to 0 as well. Does that make sense?

[itserindean]

@fancyham I have a question about something you wrote in the body of this issue and was hoping you could give me some clarity on it:

"Some organizations that we have called to validate listings have indicated that if we had a web interface they would update the listing themselves and that they have to answer a lot of calls, so it would be preferable."

When and how did we get this feedback from organizations? It doesn't surprise me that they'd be on board with this feature I'm just not familiar with the feedback and was hoping you could point me to it.

Also to be clear I support this feature but if there's a record of feedback from organizations I'd like to mine it for other insights!

Thanks!

[jelenaUX]

Jelena's notes from a review of the self-update status flag with Erin, January 25, 2023:

• The status flag needs to capture how long it has been since the last update. So the field should somehow show both the date of last email reach and how many times we've reached out via email.
• If the status flag gets reset to 0, then we should wait 6 months before attempting to email this organization again.
• When we get a corrected email address, the status flag should not be reset to 0. Instead, we want to immediately re-send an email to the corrected address.
• There should be no call to action on the last screen.
• The emails for self-service should be sent off by database admins like Erin.

Next steps: Jelena will work on integrating these comments into Figma page.

[fancyham]

@jelenaUX Re: Adding email status flag:

MVP-wise, the # of emails sent can probably be optional, if it’s too complicated.

I think it’d be good/necessary to track if/when the org validated or corrected their own listing. With that, we can tell if our org’s email is working or not. That could possibly be reflected in the status, if Erin (as a validation coordinator) finds that useful. Seeing that an email has been sent months ago but the org hasn’t responded can help us infer that our email address is wrong.

Adding some notes from a Jan 22 slack convo (over a week ago) between Jelena and I:

re: how to document status

You or John could mock it up — if you’re comfortable doing it, I’d say go for it — It doesn’t have to be perfect-looking if you’re not final yet — a schematic is enough to discuss it (like should it be a new column? Should it be a new ‘status’? Where should that column live?) and is often enough for our developers to work off.

I think this one might actually have a small flowchart that you’d use to show what happens and what displays?

Another way is to show examples of what that field might contain and under what conditions…. doesn’t have to be mocked up but could be next to the screen mockup

re: how the status flag might work

Good idea — I think ask Erin since she’s most familiar with that data-validation process. It does feel like after a few attempts, we should contact the org via another method and I like how you’re thinking about what happens if an org is not responding and how we respond… we might have the wrong email address? What happens when we get corrected email address? Does email count get reset?

Also, thinking of simple/MVP might be best for this initial version as this part seems easy to get overly complex. Perhaps a message “3 emails sent, last message sent 13 days ago” might be useful to the person sending these messages off.

(And think about who should be sending these off! Is it someone like Erin — a volunteer admin who currently assigns orgs to validate to volunteers (I’m not sure what her role’s title is) — so definitely talk to her about that, too)

[fancyham]

@jelenaUX Re: MVP

So MVP would be a minimal-viable product i.e. one that does the minimum necessary to get this function working… (i.e. omitting anything that is nice-to-have or particularly difficult).

So does the MVP include sending emails? I’d say yes, because we want to be able to track who responds and who doesn’t, including having unique web forms for orgs to update their listing.

While one could do a lot of this manually (write an email to org with screenshot of listing, then ask them to reply in email with corrections, then FOLA volunteer updates listing), the goal of this issue is to minimize the human touch and with a self-service system.

That said, we could totally test our system before actually building it by pretending to be a robot!.

This is actually pretty common with building software — it’s kind of an ‘alpha test’… testing the core of the idea before building it to make sure you’re on the right track.

This would also be akin to a paper-prototype (a printout of screens that the computer would show, then you sit with a person and they pretend they are using your program… based on what the user does, you flip to the correct page to show the results of their action)

So:

We could manually send emails to a handful of test orgs (say 5), ask them to send us updates (or provide a web form — you can use google sheets to make a usable prototype! One option might be “everything is correct”), and we use that response to update the listing and manually send the org a confirmation email similar to what our new system would do. Doing this would help us get a sense of our response rate, too.

That’s what we’d do to test a flow — it’s relatively low-effort (especially compared to programming the wrong thing) and allows us to discover situations that we were unaware of so that we can adjust our designs.

[fancyham]

Quick update:

prioritization

This issue and org priorities were evaluated along with

• #1131

Now that Erin (Product Manager) has brought managing volunteer updates in-house (previously it was managed and run by LA Works), we now have the benefit of direct experience with updates and suggestions.

• Suggestions seem to be a doable manually without building much, so is lower priority
• What’s most useful right now is to prioritize this self-service feature, so putting #1131 off for now and focusing efforts here.

alpha testing

The flow we’re building here is a prime candidate for alpha testing (i.e. a low-risk, low-commitment testing of a concept or tech) to see if the flows we’ve designed work before committing resources to build a beta — especially as creating an email system is a big dev step).

We can manually send emails to a few orgs (pretending that those emails were generated automatically), then process org responses manually. Erin had the great suggestion that to collect corrections, rather than building a web form from scratch, we can just use a Google Form. Brilliant.

By sending emails to orgs, we can test out the flows we’re proposing, and tweak them as we go, as well as find edge cases we haven’t considered.

I’d suggest perhaps doing small batches — v1 goes out to 5 orgs, wait a week for responses, make changes for v2 and send to another 5 orgs… this could allow for quick iterations.

product pod

This issue is one that we’d like to put a ‘product pod’ on (PM, designer(s), and dev(s)), but that would also require additional coordination and perhaps syncing of time, but that would allow for quick iterations and MVP development.

[fancyham]

Just an update: about 8 months ago, decided to deprioritize this @itserindean set up a great new volunteer system of college student volunteers and they have been cranking through validations manually, so our immediate need for re-validations has been taken care of HOWEVER, those volunteers may not be as thorough as this self-service system.

• [ ] Perhaps still do an alpha test (with a human pretending to be a robot) to send validation emails and see what the response is like.
• [ ] This would be a great exploratory project for a new product manager or product team. Could send 25-50 and see what results we get. A Google Form could be the way people submit corrections.