Frequently asked questions about the Collaboration Cycle.
How can I find out if my team’s initiative needs to go through Collaboration Cycle?
Any new site, page or substantial change to the user experience of an existing site or page should go through the Collaboration Cycle. This means anything that causes a significant modification to the page’s content, structure or interactivity.
If you are unsure whether your product needs Collaboration Cycle review, feel free to book some time at the Governance team’s weekly office hours to discuss the proposed changes.
I’ve determined that our product needs a Collaboration Cycle review. How do I get the process started?
A VFS Product Manager should submit a ticket for an asynchronous Collaboration Cycle Kickoff. We will add any recommendations for touchpoints to the Collaboration Cycle Request ticket you submitted.
Can I skip a Collaboration Cycle touchpoint that was recommended during Kickoff?
We wouldn’t recommend it. If you choose to skip a recommended touchpoint, please inform the Governance team via the CC Request ticket. You can also come to our weekly Collaboration Cycle Office Hours listed in the Collaboration Cycle Calendar and discuss your reasons for wanting to skip a touchpoint with the Governance team.
Do discovery efforts need to go through Collaboration Cycle?
Only if your team is testing artifacts with veterans. Discovery research should undergo a research review, but the first formal touch point with the full Governance team will be the Design Intent, which will take place after you have an idea of how to solve your problem statement and have drafted a lo-fi prototype and/or wireframe.
Do I need to have a Midpoint Review before user testing?
It is highly recommended that you complete your Midpoint Review before you do any user testing. We may identify some issues during the Midpoint Review that could impact your testing. If you have your review after the usability testing there is a risk that it may make your testing invalid.
My team is doing more than one round of usability testing. When should I schedule Midpoint Review?
You should complete your Midpoint Review before your first round of usability testing.
What if my team doesn't have all the artifacts requested in the touchpoint template?
If you are missing an artifact that will prevent us from completing your review, we will need to reschedule your review. Comment in the GitHub ticket with alternative dates and tag the Platform team member who scheduled the review.
Can I schedule a Collaboration Cycle meeting outside of the available time slots?
Unfortunately, because we have to accommodate a lot of different schedules and timelines, formal meetings can only take place during designated time slots on the Collaboration Cycle calendar.
However, we welcome VFS team members checking in on topics of concern during our office hours, which take place every Wednesday from 9:30 to 10:00 AM EST.
If you cannot find a time that works, comment and tag the Platform team on your GitHub ticket.
Can I schedule multiple instances of the same Collaboration Cycle touchpoint?
We prefer to have only one instance of a touchpoint, however, if your product requires a second review go to Calendly and create an appointment and reach out to us on #vfs-platform-support to let us know you have re
Does my team have to fix the issues identified at Staging Review?
Yes, but while the issues marked as launch-blocking need to be fixed immediately, others can be handled later. All issues labeled launch-blocking must be fixed before launch. All other issues must be fixed, but it is up to your Product Owner how to prioritize these fixes.
The Governance Team identified a launch-blocking issue at Staging Review, but my team doesn't agree. Can I challenge this?
Yes, comment on the GitHub ticket and tag the Platform team member who entered the ticket. Typically we will review any concerns you have with OCTO and decide how to proceed.
The Governance team flagged accessibility issues that aren’t in my team’s control, because they are part of the design system or a third-party app.
If you find a design system issue, please follow up with the Platform design system team. You may be asked to open an issue ticket or provide a fix if your product team has available bandwidth.
If you find a dependency issue that didn’t happen because of your team’s content or design decisions but resulted from the behavior of a third-party app, we recommend filing a ticket with the third-party vendor. Depending on the vendor, you might be able to do this on GitHub, or by using the vendor’s own ticketing system.
Why do we have to do foundational accessibility testing?
As an agency of the federal government, VA is required to create products that comply with Section 508 of the Rehabilitation Act of 1973, which mandates that all its electronic communications and information technology information and communication technology be accessible and usable by individuals with disabilities. Foundational Accessibility Testing refers to the basic level of accessibility compliance that product teams without a dedicated accessibility specialist must pass to ensure they’re creating a compliant product.
Product teams are responsible for the quality of their code and this includes making it accessible to the widest possible audience. Foundational testing can help ensure this level of quality.
Accessibility specialists cannot conduct a thorough audit in a short time frame if they have to run foundational and advanced tests.
How should I prioritize fixing accessibility issues?
All accessibility issues should be labeled according to the Accessibility Defect Severity Rubric. Defect 0 and Defect 1 are launch-blocking and must be addressed prior to launch. Defect 2, Defect 3 and Defect 4 can be fixed post-launch with Defect 2 being the highest priority and Defect 4 being the lowest priority.