rferguson13
commented
2 months ago @shiragoodman Thoughts on the MPR:
As stated, the MPR is a little more "loosey-goosey" than the other touchpoints. To not overprescribe, I recommend these guidelines:
- If a team is doing research, they should have an MPR beforehand.
- If not doing research, the team should have an MPR when they are at some sort of critical junction in their work. For instance, if looking at a roadmap, the team should schedule an MPR while there's still enough time to make significant changes before launch, if necessary. Hopefully, they won't have to, but they should plan for that possibility. We should also remind teams that they can have multiple MPRs.
I don't know if we can have required artifacts. I like the idea of having high-fidelity wireframes in Figma as a requirement, but I don't know if that's quite right. However, compared to the DI, I think something high-fidelity but not in staging would be best.
humancompanion-usds
shiragoodman
Problem Statement
In epic #72355 Governance team made several changes to the Design Intent process based off of findings from research performed by the Service Design team. We assume that many of the changes we made for Design Intent would also be valuable changes to make to the Midpoint Review process as well. We are betting that by making comparable changes to the Midpoint Review process, VFS teams will have a more clear understanding of what is expected of them at Midpoint Review.
How might we streamline and simplify the Midpoint Review experience for VFS teams so that there are less hurdles and steps for them to complete? How might we improve Midpoint Review communication to VFS teams so that expectations are clear and easily understood by all? How might we reduce clutter so that VFS teams are able to complete the necessary steps with ease?
Hypothesis or Bet
If we shorten the Midpoint Review script, we'll have more time to collaborate and answer questions for VFS teams. If we screenshare the script at the Midpoint Review meeting, we'll allow VFS teams to intake information in a different way which may help them better understand their responsibilities. If we redesign the existing Midpoint Review guidance, we'll give VFS more clear expectations of the MPR process, including what to expect from Governance and what we expect from the VFS. If we ask VFS teams to clarify scope boundaries, we'll have better alignment on what pages/content would should be reviewing so we're not wasting time reviewing out of scope work. If we create a short video on the Midpoint Review, we'll allow VFS team members to learn about the MPR expectations in a different way which may help them better understand their responsibilities within the process.
Notes from team on 6/3
Key Insights from Design Intent research and if they impact Midpoint Review
We will know we're done when... ("Definition of Done")`
Known Blockers/Dependencies
List any blockers or dependencies for this work to be completed
Projected Launch Date
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 Platforminitiative. 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?
... documented?
... measurable
When you're ready to launch...
Required Artifacts
Documentation
PRODUCT_NAME: directory name used for your product documentationTesting
Measurement
TODOs