Explore improving the notification status screen if user research shows a need

[yaelberger-commits]

Explore improving the notification status screen if user research shows a need

The notification status page is a big step in the user journey. Users will benefit from tackling this more in depth. This page serves several purposes not limited to:

• See the status of notifications sent by your service in general
• See the status of notifications sent in a CSV bulk send
• See the status of notifications sent in a bulk API send
• See the problem email addresses sent by your service in general
• See the problem email addresses sent in a CSV bulk send
• See the problem email addresses sent in a bulk API send

Questions to answer Research

• [ ] What type of users (personas) are likely looking at this page? API vs spreadsheet
• [ ] For a11y, the report was a better format for flowing through the data. HMW adapt the page itself to be more easily scannable?
• [ ] If reports are more useful to Senders, can we make the call to action to download the report more visible/prominent?

Interaction

• [ ] HMW improve the affordability of the clickable buttons/tabs on top? (using affordances)
• [ ] HMW use colour better in the status bar, not just navy/white

Content

• [ ] Could we revise "Review Address" as it may be confusing and "Address" should be small caps? (maybe out of scope)
• [ ] Could we consider a different word for "status"? (may be out of scope)
• [ ] Is it clear what "report" applies to? What info will be downloaded in the report?
• [ ] What kind of content can we add or remove to make the page clearer?
• [ ] Could we create an internal template for entries on this page (similar to our plan for the System status page)? Would we need a template if this page is auto-generated by our app?
• [ ] Could we label what each name on the page applies to? Labelling file names, user that sent the job, API send title, template name...
• [ ] Could we use non-text cues, i.e. visual/icon/colour/etc to differentiate or to set a hierarchy for the user to follow?

Content + API

• [ ] HMW create a better job name for API sends? What could be a default title-name for jobs?
• [ ] Should we require a job description for bulk sends via the API so that the history makes more sense in the UI?

Documentation and Artifacts

Good docs, figma mockups, ADRs, screenshots etc. User research deck where findings related to this page were presented https://docs.google.com/presentation/d/1Rm8MSOnjLB08WW1spb5pitx56WO9eyEcNtl5Cat_akU/edit#slide=id.g245d729d97d_0_67

Acceptance Criteria

Given some context, when (X) action occurs, then (Y) outcome is achieved

• [ ] Generate appropriate log messages so that executions of this feature can be tracked

• [ ] Can misuse of this feature cause harm? If yes, create an alert

• A11y

• Bilingualism

• Privacy considerations

• Security controls in place

• Measuring success and metrics

[adriannelee]

I can try to incorporate some of these questions to the bounce rate research plan