Implement changes to Experience Standards based on Pilot findings

[shiragoodman]

User Story

As a Governance Team member, I want to make changes to our Experience Standards and Staging Review to streamline processes for VFS teams going through the collab cycle.

As a VFS team member, I want to better understand and be able to act on findings from Staging Reviews.

Assignee: @erinrwhite @rferguson13 Peer Reviewer: @briandeconinck

Description

• New Experience Standards research: Governance Team findings
• New Experience Standards research: VFS Teams findings

Recommended changes based on pilot findings

• [x] Continue our plan to do research in the near future (6 months) to ensure we’re applying standards consistently across staging reviews, develop ideas for what to do when a finding violates multiple standards, identify any standards that might be overused, whether teams are still uncertain about reassigning tickets to other teams, and find any other areas for process improvement.
  • This will take place via ticket #63510 and will be addressed post-launch.
• [x] Before that research begins, develop a lightweight mechanism to document when findings could fall into multiple standards, or when a finding is "maybe an issue, maybe not", and when teams are concerned about reassigning ticket ownership.
• [x] Clarify our operational documentation:
  • [x] What to do when a finding is “maybe an issue, maybe not”
  • [x] When to apply a component label and when to apply a pattern or template label instead. (Also, explore conditional logic in the drafting template.)
  • [x] Update instructions for uploading videos for staging review tickets.
• [x] Encourage teams to share limitations/scope constraints of their projects at staging review.
  • This will take place via ticket #79166 .
• [x] Update Staging Review ticket titles: Update staging review findings GitHub ticket titles to be more descriptive rather than just the name of the standard violation.
• [x] Prioritize posting new Experience Standards to Platform website and sharing with VFS teams.
  • This will take place via ticket #63508 and is part of the planned launch.
• [x] Update the design of the staging review findings tickets to increase the visibility of accessibility defect information, especially in regards to the recommended timing for fixes, so that teams can more easily plan their work.
• [x] For future surveys, take a more proactive approach to sharing the survey link so that we can ensure as much feedback as possible. This might look like sharing any survey links in the teams' primary channel rather than in the thread with the staging review request; sending reminders to the teams to complete the survey; and continuing to keep surveys short to save respondents' time.
  • This work will take place via ticket #79479 and will b addressed as tech-debt.
• [x] Explore ways to continually share links to Slack scheduling workflows so that teams can access them reliably.
  • This will take place via ticket #79478 and will be addressed as tech-debt.

Impacted Artifacts

• Drafting Template (specifically, Github Upload markdown template)
• Platform website - Experience Standards web page
• Governance team operational documents
  • Documenting Staging review findings
• Slack workflows
• Anatomy of a staging review issue ticket

Tasks

• [x] Before that research begins, develop a lightweight mechanism to document when findings could fall into multiple standards, or when a finding is "maybe an issue, maybe not", and when teams are concerned about reassigning ticket ownership.
• [x] Clarify our operational documentation:
  • [x] What to do when a finding is “maybe an issue, maybe not”
  • [x] When to apply a component label and when to apply a pattern or template label instead. (Also, explore conditional logic in the drafting template.) Please include @humancompanion-usds in this discussion.
  • [x] Update instructions for uploading videos for staging review tickets.
• [x] ~Encourage teams to share limitations/scope constraints of their projects at staging review.~ (To be addressed in #79166)
• [x] Update Staging Review ticket titles: Update staging review findings GitHub ticket titles to be more descriptive rather than just the name of the standard violation.
• [x] Update the design of the staging review findings tickets to increase the visibility of accessibility defect information, especially in regards to the recommended timing for fixes, so that teams can more easily plan their work.
• [x] Update Anatomy of a Staging Review ticket page on Platform website

Peer Review

To be completed by peer reviewer

• [x] User story and acceptance criteria are met

Acceptance Criteria

• [x] We have addressed the issues identified during the research pilot that were prioritized to be fixed prior to launch
• [x] We have created tickets for addressing the identified issues from the research pilot that were not a pre-launch priority

Team Notification

• [ ] Slack post on #platform-governance-team
• [ ] Presentation at Weekly Initiative Meeting
• [ ] No notification needed

How to prepare this issue

Refinement

• [x] Ticket has user story, description, tasks, and acceptance criteria
• [x] Ticket has been sized
• [x] Once all above items are checked, add the 'Ready' label.

  Planning

  If this ticket is picked up from the Backlog mid-sprint, connect with Shira to ensure the below items are completed correctly

• [x] Ticket has been discussed as a team at Planning
• [x] Ticket has been assigned to appropriate initiative or quarterly epic
• [x] Ticket has been assigned to a Sprint
• [ ] Ticket has been moved to the Planned pipeline in the Governance team board
• [ ] Ticket as an assignee and peer reviewer

[erinrwhite]

Updated tasks list based on synthesis in #78211 and #78212

[shiragoodman]

Thank you for this @erinrwhite ! Would you mind if I scheduled a 1:1 sync with you to discuss the tasks in this ticket? I want to make sure I fully understand your recommendations before pulling this work into our next sprint.

[erinrwhite]

@shiragoodman yes that sounds like a good idea! There is a lot here 😂

[shiragoodman]

@erinrwhite I have updated this ticket, and checked off the few items where tickets have already been created and/or the work will be handled outside of the initiative (aka post-launch as tech-debt). Let me know if you have any questions or concerns.

PS I used the convert tasks to issues option for #79479 and then changed the name of the ticket, however your original comments can be found in the ticket history.

[erinrwhite]

Quick divvy up of tasks with @rferguson13

• Lightweight mechanism for feedback - Erin
• Clarifying operational docs - Rebecca
• Encouraging teams to clarify scope - we'll noodle on it and regroup next week
• Drafting template updates - Erin and Rebecca - meeting Monday to work synchronously

[erinrwhite]

@rferguson13 Started our "lightweight mechanism" aka page in confluence - I feel like the headers can be clearer. Can you take a look when you have a minute?

[erinrwhite]

Updates to Drafting Templates ready for review when you have some moments, @briandeconinck - these are copies of the drafting templates, not the live versions:

• DST Drafting Template
• Drafting Template

Changes

Findings tab

• Added Ticket title column
• Moved accessibility defect columns further left, to be next to WCAG column
• Moved SR ticket metadata columns (Rows 1-5) to stay in proper position after adding new title column

GitHub upload tab

• moved up Accessibility Defect Severity to the top of the list of references
• Added custom ticket titles

[erinrwhite]

Per conversation with @shiragoodman we are going to absorb the below task in this epic to improve Midpoint and Staging, rather than as part of this ticket. 🎉 @rferguson13

Encourage teams to share limitations/scope constraints of their projects at staging review.

[shiragoodman]

Just noting that I think this page will also need to be updated based on some of our post-pilot changes. FYI @erinrwhite @rferguson13

[erinrwhite]

@shiragoodman @rferguson13 Anatomy of a staging review ticket draft page updated!

[briandeconinck]

@erinrwhite All of those Drafting Template changes look good to me!

[erinrwhite]

@rferguson13 @briandeconinck Updated our How to Add Images or Videos to Staging Review findings tickets and also updated the page name; ready for review. I am also making sure our internal links to this page are still working with the URL change.

[erinrwhite]

Thank you for the review, @briandeconinck - I went ahead and moved the Drafting Template changes into production (replaced the existing files), and updated the "backups" folder with this new version as well. @rferguson13

[erinrwhite]

Status update Friday 4/5 - after sync with @rferguson13! @briandeconinck @shiragoodman

In progress:

• Clarify our operational documentation
  • What to do when a finding is “maybe an issue, maybe not”
  • When to apply a component label and when to apply a pattern or template label instead
  • When a finding could have multiple Experience Standards

Ready for review

• "lightweight mechanism" to document when findings could fall into multiple standards, or when a finding is "maybe an issue, maybe not", and when teams are concerned about reassigning ticket ownership
• Updated Anatomy of a Staging Review ticket page in draft for publishing when standards go-live
• Updated instructions for uploading videos for staging review tickets

Done - published

• Update Staging Review ticket titles
• Update the design of the staging review findings tickets to increase the visibility of accessibility defect information

[rferguson13]

Ok @briandeconinck ! As well as Erin's review above, I've got a couple of things ready for you:

• Anatomy of a Staging Review ticket
• How to document findings for a Staging Review
  • The only changes are in the section "Things to keep in mind as a reviewer." @humancompanion-usds, you may want to look at this as well to make sure the component versus pattern/template label section.

[briandeconinck]

@rferguson13 Besides Matt's comment on component/pattern labels, I only have one minor piece of feedback.

In the Anatomy of a Staging Review ticket example screenshots, the Product Information section is:

Team: Testing team Product: Testing product Feature: Testing feature

The first time I read it, I was confused about what "Testing team" meant here --- will a real ticket say Team: Governance team since we're the team doing the staging review testing? Or will it say Team: Veteran Facing Forms or whatever the team is coming through the Collab Cycle?

Once you get actual live findings tickets, that will become clear immediately. But for a new VFS team / PM who's on this page trying to understand the process, I think using the word "Testing" here is a potential point of confusion. I'm guessing you were trying to keep it generic to avoid the appearance of calling out a VFS team, but I wonder if there's a better way to phrase it.

Otherwise I think all of this looks great!

[rferguson13]

@briandeconinck - That's a good point. Do you think it can be solved by adding more detail to that section? E.g. "This section contains information like the team’s name, the product name, and the feature." Or should I redo the screen shots?

[briandeconinck]

I feel like redoing the screenshots would be worth it, but I know I'm a monster for saying that! 😀

[rferguson13]

@briandeconinck Thanks to your wizardry, this page is now done. Can you take another look?

[rferguson13]

@erinrwhite - For visibility. We're just wrapping up the peer review. Once @briandeconinck gives the thumbs up, I think we're good to go. Correct me if I'm wrong, but we're not publishing these yet, right? Not until we officially publish the new standards next sprint.

[briandeconinck]

Ooh, right, that's my cue to give you my thumbs up: 👍

[shiragoodman]

@rferguson13 correct - we're not publishing yet. That happens soon tho! 🎉