FAQs

Last Updated: 10 Jun 2024

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 tool, product, or page or substantial change to the user experience of an existing tool/product or page should go through the Collaboration Cycle. This means anything that significantly modifies the page’s content, structure, or interactivity.

If you are unsure whether your product needs a Collaboration Cycle review, sign up for some time at the Collaboration Cycle 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 or representative from your team 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?

Yes - but if you choose to skip a recommended touchpoint, there's a higher chance we will find launch-blocking issues at Staging Review. If you choose to skip a recommended touchpoint, please inform the Governance team via the Collaboration Cycle Request ticket. You can also sign up for our weekly Collaboration Cycle Office Hours to 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 new designs 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.

What is the difference between Governance and CAIA?

As the owners of the Collaboration Cycle, the Platform Governance team checks the VFS team's product adherence to VA.gov site standards during 3 separate touchpoint meetings: Design Intent, Midpoint review, and Staging review. During these checkpoints, Platform Governance ensures that VFS teams are on course and following VA.gov standards regarding specific practice areas: Design, Information Architecture (IA), Content, Accessibility, and Quality Assurance (QA). Platform Governance makes recommendations that align with those standards.

Sitewide CAIA partners with the VFS team throughout the product lifecycle process to provide them with the information, guidance, and resources needed to build exceptional veteran-facing products. There are no strict touchpoints. Rather, CAIA will collaborate through a mix of working formats, such as office hours, regular product- or topic-specific meetings, and asynchronous collaboration, depending on project needs and team capacity.

Platform Governance vs. Sitewide CAIA

How can I find a list of all my feedback from Design Intent and Midpoint Review as well as issues found at the Staging Review?

All feedback and Staging Review issues can be found in the milestone associated with your Collaboration Cycle ticket. Open your Collaboration Cycle ticket and look for “Milestone” in the right column. Click on the name under Milestone and you will see a list of all feedback and Staging Review issues.

When should I schedule Midpoint Review?

You should complete your Midpoint Review before your first round of usability testing.

If your team is working with CAIA, we also recommend you leave time to receive their feedback and update your designs before scheduling a Midpoint Review. This ensures testing participants/Governance see the most recent iteration of your product.

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 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 invalidate your research findings.

How do I handle the closure of tickets that were created through the various Collaboration Cycle checkpoints?

• For Design Intent and Midpoint reviews, the Governance team practice area leads will create one ticket with all their feedback using the Must, Should, and Consider framework. You’re able to close these tickets whenever you feel that you’ve properly addressed the feedback. Please note that by not addressing the MUST feedback by the Staging Review, your team accepts the risk of potentially being blocked from launching to the VA.gov platform.

• At the Staging Review, the Governance team will present their findings. If any findings are critical, they will have the launch-blocking label and must be addressed before launch. Do not close out any of the launch-blocking or non-launch-blocking issue tickets until the findings have been resolved. Once resolved, VFS teams are advised to leave a comment in the ticket to confirm it’s fixed. The ticket can then be closed when your Product Owner has resolved or validated the issue.

  • The Governance team doesn't need to validate it.

  • The Governance team can validate it if it's outside your team's subject matter expertise (e.g., an accessibility issue that requires assistive tech or something else). In that case, the VFS team can tag Governance team members in the ticket (typically the issue creator), and the Collab Cycle reviewer will review the ticket.

What if my team doesn't have all the artifacts requested in the touchpoint template?

If you are missing a critical artifact that will prevent us from completing your review, we will need to reschedule it. The Governance team will contact you in this situation and ask you to reschedule the meeting once the critical artifact has been provided.

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 Collaboration Cycle Office Hours.

If you cannot find a time that works, comment and tag the Platform team on your Collaboration Cycle Request 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, schedule an appointment on Calendly and reach out to us on #vfs-platform-support to let us know you have requested a second review.

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.

After Staging Review, should I create new tickets for my team to work on each finding, or can I use the tickets that Governance Team created?

Whatever works better for your flow. You can use the Staging Review findings ticket as a ticket for your team to work with; all we ask is that you please not remove any of the labels or remove the ticket from the associated milestone. You can also create your own ticket and link it to the Staging Review issue ticket.

Either way, please close the Staging Review findings ticket when the work is complete.

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 Point of contact/reviewer. 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.

1. 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.

2. 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.

Help and feedback

• Suggest content changes to this page.

• Submit new Platform Website content.

• Get help from the Platform Support Team in Slack.

• Submit a feature idea to the Platform.