Platform Orientation - Refine Platform Orientation experience for VFS teams

[shiragoodman]

Problem Statement

In the Platform Orientation - Discovery research around VFS challenges initiative, Governance team completed research to uncover the top pain points and challenges VFS team members face while completing Platform Orientation. See research findings. The purpose of this initiative is to address the below finding and insights:

Research finding

1. The size of the platform orientation template is daunting for some. It is unclear what is required vs. optional or how long each item will take.

Research insights

1. Orientation feels overwhelming. In our research guide, we hypothesized that orientation is a daunting experience for new VFS team members. We believed that we may be sharing more information at a given time than most users can effectively absorb. While there was variation in feedback, this was mostly true. Several participants described orientation as “drinking from the firehose.”
2. Expectations of orientation are unclear. Contributing to the overwhelm is lack of clarity on what is required/optional or how long the tasks are expected to take, which isn’t communicated in the Github ticket. New team members mentioned their struggles with accessing some tools and not understanding how to problem solve effectively (they didn’t know where to go for help) after their orientation was complete.

How might we manage the size of the Platform Orientation template so it is not so intimidating for VFS teams? How might we define our expectations up front so that VFS teams are clear what is being asked of them? How might we refine the intent of the template so each purpose is clear and understood? How might we streamline orientation to only ask what is necessary of VFS teams?

Hypothesis or Bet

How will this initiative impact the quality of VFS or Platform teams' work? How will this initiative be easy for VFS or Platform teams? Or how will it be easier than what they did before?

We will know we're done when... ("Definition of Done")

• [ ] We have removed redundant, duplicative and outdated tasks within the gh template
• [ ] We streamlined the template to only include relevant and pertinent information
• [ ] We have added time estimates for each task

Known Blockers/Dependencies

List any blockers or dependencies for this work to be completed

Projected Launch Date

• When do you expect to be completed rolling out this initiative*

Launch Checklist

Guidance (delete before posting)

This checklist is intended to be used to help answer, "is my Platform initiative ready for launch?". All of the items in this checklist should be completed, with artifacts linked---or have a brief explanation of why they've been skipped---before launching a given Platform initiative. All links or explanations can be provided in Required Artifacts sections. The items that can be skipped are marked as such.

Keep in mind the distinction between Product and Initiative --- each Product needs specific supporting documentation, but Initiatives to improve existing Products should reuse existing documentation for that Product. VSP Product Terminology for details.

Is this service / tool / feature...

... tested?

• [ ] Usability test (TODO: link) has been performed, to validate that new changes enable users to do what was intended and that these changes don't worsen quality elsewhere. If usability test isn't relevant for this change, document the reason for skipping it.
  • [ ] ... and issues discovered in usability testing have been addressed.
  • Note on skipping: metrics that show the impact of before/after can be a substitute for usability testing.
• [ ] End-to-end manual QA or UAT is complete, to validate there are no high-severity issues before launching
• [ ] (if applicable) New functionality has thorough, automated tests running in CI/CD

... documented?

• [ ] New documentation is written pursuant to our documentation style guide
• [ ] Product is included in the List of VSP Products
  • List the existing product that this initiative fits within, or add a new product to this list.
• [ ] Internal-facing: there's a Product Outline
• [ ] External-facing: a User Guide on Platform Website exists for this product/feature tool
• [ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. customer-facing meetings)

... measurable

• [ ] (if applicable) This change has clearly-defined success metrics, with instrumentation of those analytics where possible, or a reason documented for skipping it.
  • For help, see: Analytics team
• [ ] This change has an accompanying Platform Release Plan.

When you're ready to launch...

• [ ] Configure your communication to teams about your work using the Change Communication Guide
• [ ] Conduct a go/no-go when you're almost ready to launch.

Required Artifacts

Documentation

• PRODUCT_NAME: directory name used for your product documentation
• Product Outline: link to Product Outline
• User Guide: link to User Guide

Testing

• Usability test: link to GitHub issue, or provide reason for skipping
• Manual QA: link to GitHub issue or documented results
• Automated tests: link to tests, or "N/A"

Measurement

• Success metrics: link to where success metrics are measured, or where they're defined (Product Outline is OK), or provide reason for skipping
• Release plan: link to Release Plan ticket

TODOs

• [ ] Convert this issue to an epic
• [ ] Add your team's label to this epic
• [ ] Add this initiative to the Digital Experience Product Board using these instructions

[shiragoodman]

Putting this initiative on hold until Service Design is able to provide support per their initiative #63342

[shiragoodman]

@humancompanion-usds I'd like to close this initiative and instead, prioritize #85562. That initiative still needs refinement, but we can include level-setting on VFS expectations with Orientation within that epic. Please let me know what you think. I will put this on our agenda for 6/14 so we can discuss.