[EPIC] SE: Benefits content model hardening / VA Benefit taxonomy

[jilladams]

Product Briefs

• Benefit content model
• VA benefit taxonomy

Background

Benefit Detail Pages are currently mostly rich text, and this prevents the content from being usable by multiple channels (i.e., COPE; e.g., chatbot, Facilities). We want to architect a content model that will enable consumption across many channels, in partnership with the Sitewide Content team.

Simultaneously tracked on DMC board: https://github.com/department-of-veterans-affairs/digital-experience-products/issues/551

https://prod.cms.va.gov/admin/content?title=&type=page&moderation_state=All&owner=All

Sitewide Content ticket: https://github.com/department-of-veterans-affairs/va.gov-team/issues/44807

A6 notes doc: https://docs.google.com/document/d/1viOAMVIJBaA8SLUmPXX_ue4Zx6C1AS69zeX6M78tcY4/edit

High-level tasks / goals

• Content audit - SW Content owns
• CMS planning / content modeling - we will partner with the Sitewide CMS team as a stakeholder, who will review our content model in a collab cycle review. That process is in development, TBD.
• CMS design
• Front-end low touch design, leaning on the CMS design system
• CMS build
• Front-end build

Kicked off in Q3 2022.

User Story or Problem Statement

As an editor, I want benefit data to be structured in the CMS so I can create content once and have it published everywhere with consistent messaging. (COPE – create once publish everywhere)

As a Veteran, I want VA benefits to be discussed in any product using the same consistent language so that I feel reassured that the information is accurate and trustworthy.

(schema.org) As a Veteran, I want internet search results to present accurate search results on VA topics to help me get the answers I need as easily as possible.

Affected users and stakeholders

• CMS editors of Benefit and R&S pages on VA.gov
• Owners of other benefit-related products (eg Chatbot)
• Veteran consumers of benefit detail content

Hypothesis

We believe that rebuilding benefit content around a benefit content model will improve both the Editor experience and Veteran experience. We'll know that to be true when we get feedback from Editors and observe consistency among Veteran-facing products.

Engineering notes

• See notes in #12731 for schema.org discovery and initial analysis.

Acceptance Criteria

Content modeling phase

• [x] Content audit has been performed to inform a benefit content model (BCM)
• [x] Content model is designed
• [ ] CMS design is created using the CMS design system
• [ ] CMS Content model & Design are reviewed with Sitewide CMS in collab cycle review (process TBD), including:
  • [ ] Change management considerations
  • [ ] Knowledge base (KB) articles are considered / ticketed for any Sitewide CMS work required
• [ ] Sitewide CMS Collab cycle feedback is implemented / signed off
• [ ] CMS has been updated to implement content model / design, and reviewed / signed off by designer
• [ ] Change management is ticketed & factored into release plan

Hardening phase

• [ ] Content audited to identify pages to migrate based on the new BCM
• [ ] Designed migration plan
• [ ] Designed new CMS content type(s) for migration of targeted Veteran-facing pages
• [ ] Designed new Veteran-facing templates
  • [ ] Schema.org approach designed, taking input from examples of facility locator and event pages
• [ ] Developed new CMS content type interface(s) for target pages
• [ ] QA & Release plan are documented & reviewed, including
  • [ ] Repositories that will have PRs to merge
  • [ ] Test cycles and where those will take place in terms of environment(s)
  • [ ] Change management process & timing

Change management triage

The change represented by this user story will:

• [ ] Be a site-wide change to appearance or key functionality (such as log-in process)
• [ ] Be a specific change that requires more than 30 minutes of work by a user to meet a publishing requirement
• [ ] Remove a piece of functionality (such as restricting editing functions, or “hardening”)
• [ ] Require action by some or all users by a specific deadline
• [ ] Change the front end and be highly visible to the public
• [ ] Noticeable performance improvements (publishing speed, predictability)

If you selected an item above, open a new issue using the change management template.

If you did not select an item above, update issues/PRs in GitHub but don’t plan for change management.

Design principles

Veteran-centered

• [x] Single source of truth: Increase reliability and consistency of content on VA.gov by providing a single source of truth.
• [ ] Accessible, plain language: Provide guardrails and guidelines to ensure content quality.
• [x] Purposely structured content: Ensure Content API can deliver content whose meaning matches its structure.
• [x] Content lifecycle governance: Produce tools, processes and policies to maintain content quality throughout its lifecycle.

Editor-centered

• [ ] Purpose-driven: Create an opportunity to involve the editor community in VA’s mission and content strategy goals.
• [x] Efficient: Remove distractions and create clear, straightforward paths to get the job done.
• [ ] Approachable: Offer friendly guidance over authoritative instruction.
• [ ] Consistent: Reduce user’s mental load by allowing them to fall back on pattern recognition to complete tasks.
• [ ] Empowering: Provide clear information to help editors make decisions about their work.

CMS Team

Please check the team(s) that will do this work.

• [ ] Program
• [ ] Platform CMS Team
• [ ] Sitewide Crew
• [ ] ⭐️ Sitewide CMS
• [X] ⭐️ Public Websites
• [ ] ⭐️ Facilities
• [ ] ⭐️ User support

[jilladams]

Backlog refinement note: @kevwalsh to summarize takeaways re: staffing / this project.

[kevwalsh]

Next steps

• Ideate with Sitewide content team what are the attributes we are interested in for a content audit
• What are the right tools for performing that audit and making it actionable

[jilladams]

2 sprints: 4 BE tickets 3/w mini-sprint checkins with Wes, Christia, Jordan

Phase 1: (Sprint 81)

• CMS field & config working model in draft PR environment for team viewing
• Team checked that the config makes sense architecturally

requires 2 sign offs: Wes, Jordan on this ticket based on demo env (not the draft PR)

• Draft PR gets shared with Daniel / Tony?Nate? for preview?

Phase 2: (Sprint 81?) Design / polish CMS UI layer

• Design elements listed/linked and incorporated

  • editor experience / permissions
  • look and feel
  • help text
  • etc

• CMS and Design roadblocks, changes, or questions uncovered during stage 1 are considered:

  • discussed in mini-sprints and documented in the ticket
  • Scope mgmt: cut new tickets here per item, if they warrant more than a 30 minute conversation during the mini-sprint check-in or need to involved more parties (e.g. we can’t force Drupal to do the thing that’s nice)

• Field config and UI is ready for collab cycle review

• Bring LauraF in to mini-sprints if not during Sprint 82 PTO

• Draft PR gets shared with Daniel / Swirt for preview.

requires 2 sign-offs: Wes, Jordan, DaveP, LauraF for ticket based on demo env, not PR

** Make clear in sprint planning that these tickets will close without merged code

Phase 3: (Sprint 82?)

• CMS Flow / Collab cycle review
• 508 concerns
  • Bring LauraF in to mini-sprints if not during Sprint 82 PTO
• Updates/changes to fields and configs, UI, 508, all the things
• Architecture polishing based on collab review
• Updated PR for team review

Would need 3 sign offs: Wes, Jordan, LauraF, DaveP

Phase 4: (Sprint 82)

• Final CMS config
• PR review and testing
• concerns addressed
• Interface tested and collab sign-off
• Final PR gets sign off and merges
• needs sign off from: Wes, Dave P. , Daniel, Jordan, Laura, Tony?Nate?

Permissions: Content Admins + Admins - should match whoever can do Benefit Detail Pages and DavePs notes in spreadsheet.