Design System Team Charter

Why we're here

North Star:

Any team charged with building a Veteran Facing Service (VFS) has the tools to quickly design, test and build an application that meets or improves VA’s standards of quality for the Veteran experience.

Team Mission Statement:

Provide tools, processes, and guidelines that enable teams to rapidly build and improve a consistent Veteran-facing digital application ecosystem without duplicating efforts.

Product Portfolio:

The Design System consists of:

  • Component Library

    • React components

    • Web components

    • Storybook

  • Sketch Library


    • All sections except for Content and Experimental Design

    • Technical aspects (build, deploy, dependency upgrades, etc.)

  • Forms Libraries

    • Schema-based

    • Formulate

  • Documentation

    • Guidelines on all the products in our portfolio

  • Experimental design process


Design System Backlog Problem Statement

  • We believe that VFS teams need continuous improvements to the design system documentation, tools, and shared code.

  • We know this is true because use of the design system is not always consistent and we have seen teams forking design system components into custom code.

  • We believe that establishing and shipping updates of components prioritized by the Design System Council will improve the speed with which VFS teams can design and develop an application without customizing and forking common code and shared tools.

Forms Library Problem Statement

  • We believe the existing forms library makes it difficult for VFS teams to design and build forms that meet VA use cases.

  • We believe the existing forms library makes it difficult for VFS teams to create maintainable forms.

  • We know this is true because we have feedback from VFS teams that the current Forms Library is rigid and requires a complex mental model to use.

  • We believe that improving form-related component and pattern documentation will improve the time from launch to production for form applications.

  • We believe that building a new forms library which focuses on the developer experience will reduce pain points and increase the efficiency of building forms for VFS engineers.

Component Library Problem Statement


Web Component Problem Statement


Source of Truth Problem Statement

  • We believe that VFS designers and engineers are confused by inconsistencies across design system documentation, tools, and production applications.

  • We know this is true because design critiques are more focused on proper usage of existing components as opposed to improvements or new components that will benefit all teams.

  • We know this is true because there is confusion in communication between designers and engineers because there is a disconnect between how things are documented.

  • We believe that improving consistency by identifying and communicating a “source of truth” version for components and patterns will increase the number of new or variant components launched and help us track the actual usage of components and patterns across our production applications.


DST 2020 Q4 Roadmap

DST 2021 Q1 Roadmap

DST 2021 Q2 Roadmap

DST 2021 Q3 Roadmap

DST 2022 Q1 Roadmap

DST 2022 Q2 Roadmap

DST 2022 Q3 Roadmap

Who we are

Team Members:

  • OCTODE Product Owner: Matt Dingee

  • VA Head of Design : Kevin Hoffman

  • Product Manager: Carol Wong

  • UX Designer: Natalie Hill

  • Engineering Lead: Katy Bowman

  • Engineer: Brooks Johnson

  • Engineer: Andres Rivera

  • Accessibility Specialist: Sarah Koomson

  • UX Designer (part-time): Sean Sewell

How we work

Workflow + Cadence


Check in on people and product progress

  • Daily @ 11:45AM ET

  • 15 min

  • 3 Question Format: What I did yesterday? What will I do today? Any impediments?

Retro + Sprint Planning

Review accomplishments from prior sprint, what went well, what can be improved, what questions people have, and any action items. Outline work to be done this sprint in order to accomplish the team's goals

  • 1st Thursday of every sprint at noon ET

  • 90 mins

  • Any other issues you have to discuss with the team


Assess and update workload for remainder of sprint

  • 2nd Thursday of every sprint at noon ET

  • 1 hour

  • Any other issues you have to discuss with the team

Issue Etiquette

For an issue to go into the Current Sprint column, it must have the following (created using the “Standard Issue Template”):

  • Estimate (when possible)

  • Title that explains task

  • Description with Background and Acceptance Criteria (optional)

  • Labels: vsp-design-system-team

  • User Story (if applicable), Goal, and Acceptance Criteria

  • Nested in an Epic

All work should be validated either in staging or production, as defined by the acceptance criteria. Each ticket's last comment before closing should reflect whether validation has occurred, and by whom. By default, assign your PM to validate any tasks you are unable to validate yourself.

If there is a new RED LIGHT URGENT work request, contact the Product Manager and ask for help to work it into the sprint

Team Norms

Update as you see fit! These are some starter norms for you to consider

  • Be respectful, both online and off

  • Show your face (Webcam) at meetings / calls

  • Speak up! - everyone’s voice matters

  • We are flexible, but intentional in the way we work

  • Let’s have fun and do great work!


This is our main means of communication with each other. Keep as much conversation in public channels as possible, to minimize duplicative and extraneous communication.

Private Team Slack channel: #vsp-design-system-team

Public Design System Slack channel: #vsp-design-system


GitHub is the single source of truth. Every body of work should be documented for tracking and capacity planning.

General things

  • Update tickets regularly. If conversations happen in Slack that are pertinent to a product or initiative, copy the useful info into GitHub/ZenHub.

  • Extra time? Explore the "Backlog (prioritized)" column in Design System Team ZenHub board.