UX TLC - Empty states

[melissa-lefevre]

Description

• We are handling empty states a few different ways across the app (including one that looks a lot like our data loading error screen. What are the rules for showing one approach vs another? Differentiate empty state treatment from data loading error treatment; use the same treatment for empty state where it makes sense
• Empty states should be used consistency throughout the app. Hiding a feature from users may lead them to think that we do not support that feature

Acceptance Criteria

- [ ] Audit usage of empty state pattern - [ ] Establish a rule & be consistent about implementation - [ ] Include an empty state for when a user does not have direct desposit information that follows the established empty state pattern - [ ] In Appointments - Determine the use of the couldn't mach info page and if it could be consolidated with the empty state page **Accessibility Requirements** - [ ] Some of the empty state do not have CTA, for example, using change preferences on web instead of app is that theres no action to that state. empty state should not be blank with no action. Best practice: Ensure CTA for visual and screen reader alike on what to do next. ## Notes & Open Questions - Dependencies/Roadblocks: - Any internal/external dependencies? - Test accounts needed? - Does this require QA? - Dev Notes: ## Ticket Checklist - [ ] Acceptance criteria defined - [ ] Labels added (front-end, back-end, feature) - [ ] Linked to an Epic

[bischoffa]

@drjecker is this ticket still valid? Older than a year. If so comment indicating to keep it and update the epic to UX Initiative for UX to track.