[CST] Content Modeling to create more consistent presentation of information in requests to Veterans

[skylerschain]

Value Statement

As a Veteran I want to be presented with a more consistent display of information related to requests of various types So that I can better navigate the requests and more easily figure out which actions, if any, I need to take for my claim

---

Background Context

@jstrothman Has initiated an effort to create "content modeling" documentation for requests (1P and 3P) for both alerts that show up on the details page and the content that displays on the document request page.

Some work in progress related to this:

• Mural
• Figma
• Technical annotations for existing 1P requests and 3P requests
• Evidence requests descriptions drafting doc

Design

Work in progress content modeling

Enablement team (if needed)

@jstrothman

Engineering

• Current und

Out of scope

• Add here

Open questions

• Overall, what does a template look like that will work the most broadly for various tracked items?
• How do we think of something that’s consumable by mobile for the content modeling work?
• How can we associate letters to tracked items?
• Our current understanding is that all 1P tracked items will have a development letter associated with them, but not all development letters will have a 1P tracked item associated with them. How do we handle getting Veterans to the development letter if there is no 1P alert "bridge" to get them there?
• How do we handle different content types (e.g. unordered lists) that might show up in tracked item descriptions?

Tasks

• [ ] Create a a new Figma spec that shows the content model for 1P alerts, document request page, and claim letters, and provides examples from request types that are either in production or to be released in the near future
• [ ] Incorporate guidance from Andrew that is documented in evidence request drafting doc
• [ ] Share this new spec with the team

Definition of Done

• [ ] Meets acceptance criteria
• [ ] Passed E2E testing (90% coverage)
• [ ] Passed unit testing (90% coverage)
• [ ] Passed integration testing (if applicable)
• [ ] Code reviewed (internal)
• [ ] Submitted to staging
• [ ] Team approved production verification process
• [ ] Design performs design QA and verifies the implementation matches the design spec
• [ ] Accessibility specialist performs accessibility review (in code or design)
• [ ] Engineering identifies staging users required to test and shares account and credentials with design and product
• [ ] Product performs functional QA and verifies acceptance criteria was met

Acceptance Criteria

• [ ] The Figma spec contains a scalable content model, documenting existing requests that are in production and leaving room for requests that have not yet been added
• [ ] AC
• [ ] AC

[jacobworrell]

@skylerschain what are the tasks for us related to this effort? I can't pull this into Backlog refinement for sizing without a clear sense of what we're proposing to do.

[skylerschain]

@jacobworrell – I added some tasks above. @jstrothman will pick this up.