Slide 1: Hi there and welcome to the U.S. Web Design System monthly call for August 2023. August, the month with no national holidays, but home to the Perseid meteor shower, the earth’s yearly transit through space debris — which my family and I got up at 3am to watch the other night. It’s shown here with a black USWDS logo, and if you just keep looking at it long enough, there’ll be one little flash for a fraction of a second.

Oh, there’s one.

And welcome back after our July break. Thanks for being back with us today!

Slide 2: My name is Dan Williams, he/him, and I’m the USWDS product lead — and here on-screen is my avatar: dark hair, blue sweater, collared shirt. Today my physical self is wearing a light blue collared shirt. What you can’t see is that it’s hot here in the pacific northwest and my offscreen wardrobe features shorts. And I feel it’s important to note that while my current heat at home is unpleasant, my heart goes out to those who are truly suffering in Hawaii. I’d also like to note that when we introduce ourselves in these calls, you’ll hear things like self-descriptions and pronouns — these help everyone share the same context and know a bit more about who we are, whether or not you know us or can see us.

First, I’d like to mention that we’re recording this monthly call, so please refrain from turning on your camera. We will manually turn off any cameras to ensure the recording doesn’t show us on camera. Unfortunately, while we are recording this call, we currently aren’t able to always share the video publicly. That said, we are making progress on being able to share videos and we’re building the capacity to slowly release more and more of these monthly calls publicly. So stay tuned for more updates. When we do post videos publicly, they’ll be available via the Digital.gov event page.

I’d also like to remind you that by voluntarily attending this Digital [dot] gov event, you agree to abide by Digital.gov’s community guidelines at digital.gov/communities/community-guidelines/ —you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat.

If you are in the Zoom app, you can use integrated live captioning by selecting the “CC” button on the bottom of the screen. If you prefer live captioning in a separate window, we’ve posted a link to the live captioning in the chat.

We’ll be posting other links and references into the chat as we go along, and I encourage you to ask questions in the chat at any time. If any member of our team can answer your question in the chat, we’ll do so, otherwise there’ll be some time for questions and answers at the end of the hour. Also, be sure to introduce yourself in the chat as well — it’s nice to know who’s here. It’s good to have you here today.

For those of you who find the chat distracting, you’re welcome to close or hide the chat window during the main presentation. You can reopen it later during the Q&A session at the end of this call.

So thanks! And, with that, let’s get started!

Slide 3: So what’s our agenda for today?

First we’ll look at a new site launch

Then I’ll highlight some product updates

And then we’ll spend the rest of the time checking out our roadmap for the rest of 2023 and into 2024.

We’ll be leaving time for Q&A at the end so stick around!

Slide 4: So let’s jump into it with a nice site launch.

Slide 5: This month we’re looking at a new site launch from NASA, gcn.nasa.gov, a new site for NASA’s General Coordinates Network. Once known as the Gamma-Ray Coordinates Network, GCN distributes alerts between space- and ground-based observatories, physics experiments, and thousands of astronomers around the world — sharing real-time observations, discoveries, and follow-up of gamma-ray bursts, gravitational-wave compact binary mergers, and high-energy neutrinos. If a star goes supernova, you’ll hear about it on GCN.

The GCN homepage features a simple black header with the NASA logo, a hero section with a diagram of relationships between observatories, experiments, and astronomers, and the words GCN: NASA’s Time-Domain and Multimessenger Alert System.

Slide 6: Congratulations to this team! Be sure to let our team know when a new site launches, either with an email or a note on the USWDS public Slack channel!

Slide 7: On the product update side, we have a new release we’re prepping right now: USWDS 3.6.0. This one has a few important bug fixes and builds on the work we introduced in 3.5.0 to normalize the display of disabled states.

Slide 8: A few key improvements in 3.6.0:

• Improving in-page navigation. Users will be able to customize the element that in-page navigation pulls content from, and hidden headers will no longer appear in navigation.
• Expanding icon list’s support for setting all font size tokens.
• Addressing color and styling bugs related to disabled styles.
• Fixing a bug preventing font-[family]-[size] utility classes from generating.
• And making accessibility improvements for memorable date, pagination, and form input components.

It’s a good release, and some important followup to 3.5.0.

Slide 9: That’s USWDS 3.6.0 and we should have that out for you this Friday… tomorrow!

Slide 10: So let’s talk about the USWDS roadmap. For the last year or so we’ve been doing incremental roadmap planning a couple times a year. Our last planning increment started in February and just ended recently. Now it’s time for us to plan for the next 4 months, as well as look forward to the next 8 and 12 months as well. There’s a lot we’d like to do, and I expect that the work we’re planning now will be some of the most important we’ve done as a design system. More than likely setting us up for a new major version in 2024.

But before we talk about what we’re planning, I’d like to take a moment and look at where we’ve been as a project and a product.

Slide 11: Today, USWDS is about 8 years old. We’ll talk a bit more about this next month since next month will mark eight years since the first release of the design system as a public alpha release.

Slide 12: Since then, the design system has been through three key phases that correspond with our major versions.

Slide 13: USWDS 1.0 provided the common starting point for many new websites, particularly those built alongside 18F and USDS. In many ways it was built to prove its value, built to prove the value of common design solutions, helping teams to build faster and better, to spin up more sites in less time. And in that way it was certainly a success, and gained a fair amount of adoption across agencies.

Slide 14: By USWDS 2.0 — about four and a half years ago now — we were ready to learn from that experience. We’d heard from designers and developers that while they got a lot of use out of the design system as a starting point, most projects were customized to a point where it was difficult to see a connection between the final product and the components and styles that shipped with USWDS. USWDS took that real-world customization as a starting point and developed a common design language of of tokens — things like color, spacing, and font size — that allowed more flexibility inside of constraints of the design system. USWDS was built to adapt, and to allow teams to build custom experiences while still sharing common building blocks.

Slide 15: We released USWDS 3.0 last April. The design system was growing, both in its user base, but also in the components it supports. By USWDS 3.0, we’d more than doubled our supported components since USWDS 2.0. The codebase was growing and the stylesheet was growing as well. USWDS 3.0 brought common component packages, a modular approach to our components and codebase that was built to choose — allowing teams to choose only those components their project actually uses.

Slide 16: But all the time growing, growing, growing. Since USWDS 2.0 — around the time we started keeping reliable usage metrics — design system usage has about tripled.

Slide 17: In the last four years, sites using USWDS from 103 to 461.

Slide 18: The pageviews per month on USWDS-powered sites, as measured with the Digital Analytics Program (or DAP) has grown from 390 million to 1.1 billion.

Slide 19: And as a percentage of the total pageviews across the federal government, as measured with DAP, what we think of a pageview coverage — we’ve grown from 9% to 28%.

Slide 20: We’ve done this because of a strong community of practitioners sharing solutions. That’s this group here today!

Slide 21: Dozens of teams doing good work across agencies and silos.

Slide 22: Iteratively improving the digital experience of government. And it shows. Not only do we see this in the site launches and redesigns we feature from month to month, but in the undeniable progress and presence of human-centered design at the forefront of decision-making across agencies and teams.

Slide 23: This is principles-centered progress that we should feel good about.

Slide 24: Nevertheless, we’ve certainly felt — and are feeling — growing pains in the design system as a product. As we try to make good decisions about what we can build, we are listening to your comments and criticisms.

Slide 25: “You don’t have what we need.”

Slide 26: “Our standards conflict with yours.”

Slide 27: “You need to prove your solutions are better.”

Slide 28: “It’s just too hard to use.”

Slide 29: And “It’s a burden to stay up to date.”

Slide 30: To be clear, these are reasonable concerns and serious concerns. And we take them seriously.

Slide 31: Without question, USWDS always needs to improve.

Slide 32: USWDS always needs to evolve.

Slide 33: USWDS always needs to change. There’s no endpoint.

Slide 34: From sprint to sprint, we triage and address lots of issues and feature requests.

Slide 35: There’s a lot that we need and want to do. And of course, it’s not just what we need and want to do. You expect a tool that delivers on its promise of making it easier to build accessible, mobile-friendly government websites. The 21st Century Integrated Digital Experience Act — for instance — expects just that: an integrated digital experience. Whatever the expectations, and however we mature, improve, and change, we expect to change.

Slide 36: But change isn’t just hard, it’s costly. And what it costs to change the design system itself — our own design and development costs — is one of the least of these costs. Realistically, the cost of change is a cost that’s borne by the teams that need to change along with us.

Slide 37: And — currently — the more teams use the design system, the more costly the change. There’s a multiplier in play here that works, perversely, against our promise to facilitate scaling design and development solutions.

Slide 38: We want to scale improvements! But each improvement — each change — risks multiplying cost across the growing number of teams that use the design system.

Slide 39: What are these costs of change?

Slide 40: There are two general types of cost associated with a design system change.

Slide 41: The first is perhaps the simplest to understand: implementation cost. Which you can think of as the design and development time it takes to actually update to a new version and modify your project templates to reflect changes to the USWDS codebase. And because of the way we distribute our codebase, any change to the markup of a component necessitates a downstream change to a project implementation.

Slide 42: The second type of cost is what we might call justification cost, which we can understand as the cost of understanding and agreeing with the change — justifying the change to your team and project. In a way, this includes traditional opportunity cost — or the cost of not pursuing your own solution in favor of ours.

Slide 43: What can we do to lessen these costs?

Slide 44: In general, back-end consistency enables front-end change. The impact of change and the cost of change can be lessened with consistent, thoughtful structure.

Slide 45: Just as implementation costs can be helped by abstracting or automating aspects of implementation, like through a consistent and thoughtful API that constrains change to outputs while maintaining consistent inputs, justification costs can be helped by abstracting or automating aspects of justification, like through consistent and thoughtful processes that pass decisions through consistent collaborative standards of evaluation and decision-making.

Slide 46: So as we build to change, we’ll be focusing on these two elements as our foundation: API and process.

Slide 47: And this is the biggest change from USWDS 1.0. A fundamental change we’ve been slowly — very slowly — moving toward from release to release: that we really need to support staying up-to-date over time. Improving the ongoing update process so we can all grow and improve together.

Slide 48: We see USWDS as a dependency not a fork. That USWDS isn’t just a starting point but an ongoing relationship over time.

Slide 49: To be effective in this goal, we need to mature our technology

Slide 50: and mature our process.

Slide 51: We see the design system not as just a commonality machine but a change machine.

Slide 52: Old heads will remember we talked about this idea way back in February 2022. We’re putting a link to that presentation in the chat.

Slide 53: And now we’re going to get it done.

Slide 54: I recently read this quote in a book by Jane Jacobs. She was a critical thinker about development, notably about effective and ineffective urban structure. How cities live and die. How interventions can be constructive or destructive. She writes that “development isn’t a collection of things, it’s a process that yields things.”

Slide 55: Evolution isn’t simply an ape, a cave dweller, and a modern human standing in a row on a timeline.

Slide 56: It’s the process that drives ongoing differentiation.

Slide 57: I would hope that our process — however it evolves — is an outgrowth of our design principles. These principles are meant to apply just as much to USWDS as a product as anything you build with your teams.

Slide 58: Start with real user needs.

Slide 59: Earn trust.

Slide 60: Embrace accessibility.

Slide 61: Promote continuity.

Slide 62: And Listen.

Slide 63: So, I’m really happy to announce that the USWDS team is actually growing and changing! I’d like to introduce my new teammate and colleague Anne Petersen — our new Experience Design Lead — to talk about our roadmap and our roadmap process. Anne, take it away!

Anne: Hi! I’m Anne, my pronouns are they/them, and I’m the U.S. Web Design System’s newest full-time federal employee, our Experience Design Lead. In the interest of inclusion and accessibility, I’m a white person with short brown hair and small brown glasses. I’m aiming for a fairly androgynous look, but that’s up to your interpretation. Very glad to be part of the team, and excited I can help expand the full-time federal team from one staff member to two.

Slide 64: Being the new person anywhere means a lot of information absorption. Thankfully I’ve been part of Technology Transformation Services (we sometimes say TTS) here within the General Services Administration for about five years to this point. That was as part of 18F, which is also within TTS, so I’m familiar with the design system from implementation and organizational perspectives.

Slide 65: And from everything I’ve absorbed and understood so far, my top take-away is: this is a big job! The scale is immense. We support, at core, all the different use cases of interacting with government online and therefore all the different people that depend on government in its many forms. Supporting all kinds of teams, all across government. Huge breadth, huge needs, and incredibly important to get it right. For everyone.

Slide 66: You may know the quote from Carl Sagan, who said “to make an apple pie from scratch, you must first invent the universe.” which appears on this slide along with an astronomy photo of a nebula.

The U.S. Web Design System right now is giving me “first, invent the universe” vibes here. We need the underlying structure and commonalities of the design system to support the government’s digital universe. But it needs to be both flexible and consistent enough to support everyone’s needs, from agencies and products to end users and what they need to get done.

Slide 67: So how do we start — or really, continue — doing this big job?

Our roadmap is part of that: showing how we get from where we are to where we want to be. We know our challenges are big ones, as Dan covered. Those challenges are also opportunities, especially if we can use one to support the other.

We’ll need to make fundamental shifts — foundational architectural and process changes — to make the future we want possible, especially with the continuous work we need to do to support the system as a living product. This move lets us more fully satisfy what a design system is supposed to solve for its users. These are fundamental platform basics that are necessary before we can expand our view in the roadmap’s next iteration. Part of that is figuring out the mechanics of how we change so we can be ready for those shifts.

And what we have for you today is about the next year’s worth of what we’re calling a roadmap but may not quite count in the way most product managers would define it.

Slide 68: Our roadmap today is what we’d call a minimum viable product, or MVP. We wanted to communicate as much as we have as soon as we have it, to help you understand changes that are coming. So today’s roadmap is fairly near-term. Year-term, you might say. So how we got to this roadmap and the items on it leans a little bit on our old process: most recently, estimating the effort and impact of each future need and mapping those to what will both get us to the future we need to head toward, and also satisfy current needs. We’ll get into the detail of these in just a few minutes.

So that’s how we did this prioritization this time. But this isn’t the ideal more long-term thinking we’d like to do. We’re moving from a continuous MVP model to considering our broader mission and vision, and making sure our direction aligns with those. More to come on that too.

Slide 69: This demonstrates, live and in front of you, how we as a team are maturing too. We’re on the same path y’all are on too, moving from short-term what-needs-to-be-done reaction to envisioning and accomplishing long-term goals. We’ll be taking this step back to look at our principles. In this case, the design system’s vision, mission, possibly our polestar. That will help us get to a more cohesive and aligned plan, and ultimately, to better serve all of you.

Slide 70: And, for better or worse, our process is part of our product, which is why we’re being so transparent today. You may be in a similar position — working to mature and scale your efforts. We hope being clear about how this is working for us, how we’re managing our work responsibly with limited resources, may help others understand how they might approach something similar.

Slide 71: How and why are we introducing more process to the design system? Well, primarily to keep new things moving into the system as appropriate.

Slide 72: Which gets us to… the roadmap.

Slide 73: Here’s what we’re planning. Some of these are shorter term, some are longer term, as we look toward the end of this year and into next year. So, our top items right now are to:

• Conduct a content audit of our website
• Define our component acceptance framework & lifecycle
• Establish our ongoing accessibility-focused usability testing
• Publish updated guidance for using disabled styles
• Create critical checklists for components
• Develop USWDS web components, and
• Convert design tokens to JSON and CSS variables

Some of these are interdependent on each other, so we’ll get to more detail on each of these next.

Slide 74: First, conducting a content audit of our website. Conduct a content audit of our website.

Slide 75: This means cataloging and understanding our site’s current organization, information architecture, pathways, and content itself — the information we provide. Why are we doing this? We need to gain a holistic understanding of our current site and fix where there might be redundancies and information that could be out-of-date or obsolete. This is also in the interest of reducing clutter and getting better organized.

The milestones we’ve set out include first: identifying key metrics and collecting data on our current state. Next we’re doing a page-level audit, reviewing every page’s content types, style, and priority. After that we’ll create an action list, consolidate, and prepare for what we need to do on a continuous basis. We expect this to take six months, and the good news here is that we’ve already gotten started on this, and probably have about two months left here.

Slide 76: Our next roadmap item is to define our component acceptance framework and lifecycle. In more detail:

Slide 77: This item shows you, our community, as well as the public, the process of how our components move from being a proposal you or someone else makes, all the way to being published as part of the design system, as well as what happens after that, like ongoing testing, and also what happens when a component needs major changes.

So why this item? We want to make it clear to everyone what every design system component has to have to be included. This also brings consistency and transparency to our decision making, and builds a common understanding and predictable process to how components develop and change.

These items are part of what’s typically called governance — a funny term here maybe — which is really important for process consistency and continuity.

We’ve started on this one too, and as a preview, we anticipate in the proposal process we’ll be asking for things like a summary of your proposed component, why it would benefit end users and the system, details about its functionality and implementation, accessibility considerations, any documentation or evidence you might have, potential drawbacks or alternatives you considered, things like that.

Getting this in place has been holding up some current proposals, so we want to note it’s taken certainly longer than we’d like to get back to people there. We apologize for that, but we’re happy to share that they are still moving.

The milestones here are first defining the proposal process, as well as documenting the complete component lifecycle, from that proposal phase all the way to maybe being retired in the future. Next we’ll share that information and ask for feedback from you, along with trying out this process with a prototype. After that, we’ll publish both the proposal process and the lifecycle publicly.

Slide 78: Our next item is establishing ongoing accessibility-focused usability testing of components.

Slide 79: This one operationalizes our usability testing with people who use assistive technology and those with disabilities as a sustainable, repeatable process that we do in an ongoing way, and which could serve as a model that other teams could adopt.

Our reasoning here should hopefully be pretty evident due to how it aligns with our design principles, which Dan mentioned earlier. This supports at least two of them very directly, arguably more — helping us better understand how our components work for real people, including those with disabilities, and help us be more proactive in finding and fixing any usability issues. We’d also like to be able to share this, again, so other teams can use it.

First off here is creating our process for recruiting, managing information, compensating participants, and for doing testing itself. Nextly, we’ll try this process out, in the process developing relationships to make this more sustainable. After that is putting this plan into place: so performing that ongoing testing and sharing how we do it. Again here, we’ve gotten a good start, with about two months left on this one.

Slide 80: This next item is publishing updated guidance around using disabled styles.

Slide 81: Which, as a spoiler, after some research will include discouraging using disabled styles in most cases, and also helps us create another new process that we should point out too — this process focuses on documenting and publishing our research. The research in question here happens to be what we did to support our decisions in this guidance, but how we did this could apply to other research we do.

Why here — again supporting our design principles — well, this improves the usability and accessibility of our forms, and establishes a repeatable process for publishing our guidance, along with the research and reasoning we used to get to those decisions.

We’re about halfway through these milestones: we’ve completed the research on this, and we’re in the midst of figuring out the scope of this updated guidance to publish on our site. Lastly, we’ll work on the repeatable process for publishing research generally. We have about three months left here. For the rest of the items, I’ll pass back over to Dan.

Slide 82: Dan: Thanks Anne. This is Dan again.

Our next roadmap item is one we’ve talked about quite a bit here on these calls and shouldn’t come as a surprise: Creating critical checklists for components. Let’s dig into this one.

Slide 83: So when we’re creating critical checklists for components we mean that we intend to publish plain-language checklists for validating or revalidating the accessibility of our components with lightweight manual testing. These checklists will be component-based, easy-to-read that capture accessibility checks related to our components, and the current status of those checks.

Why are we doing this?

To provide an accessibility baseline for our components that teams can use to validate our work and their own…

To democratize accessibility checking across teams and skillsets…

And to improve the accessibility of sites and services

Here are some milestones for how we’ll get there:

First we’ll establish component types and voice and tone

Next we’ll document heuristics for each of our components and prototype this content and format with our community

After that, we’ll publish checklists to our website alongside a mechanism for updating

All-in-all we expect this to take about 6 months to finish.

Slide 84: The next one is the biggie. This is kinda one we’ve been thinking about and prepping for quite some time, one that I believe is a key milestone in the development of the design system: Developing USWDS web components.

Slide 85: What does it mean to develop USWDS web components? Well, we want to deliver templated, platform agnostic, web standards–based components with a simple, consistent, documented API

Why are we doing this?

To simplify integrations and provide out-of-the box components…

To reduce time and cost of updating to minor and patch versions…

and to establish a documented API that teams can use with confidence.

Here are some milestones for how we’ll get there:

First, we’re starting to evaluate frameworks and collect examples from other design systems.

Next we’ll work toward an alpha release of our core components (banner and identifier) as well as identifying partners for a beta program.

After, we’ll conduct a thorough beta program for development, feedback, and testing. We’ll also be thoroughly documenting these components and their API on our website. This is very likely in support of a new major version of the design system.

When? In all, we expect that this process will take about a year.

Slide 86: And finally, we want to convert design tokens to JSON and to CSS variables (or custom properties)

Slide 87: What does it mean to Convert design tokens to JSON and CSS variables? It means that we want to create a portable, canonical data format for USWDS design tokens, based on standard schemas.

Why are we doing this?

We’re doing this to allow more teams to be able to use our design tokens across frameworks and platforms

To reduce our dependency on specialized formats like Sass…

To deliver design tokens in a modern, familiar format that teams expect…

and, in support of our big initiative, USWDS web components.

Here are some milestones for how we’ll get there:

First we’ll audit token data, research JSON structures, and determine a conversion strategy. We’ve already talked with some of your teams about tokens and JSON, and we’ll continue to do so.

Next, we’ll convert our system tokens, define the JSON transformations to Sass variables, and create our token library.

Afterwards, we’ll convert the remaining tokens, define the JSON transformations to CSS variables, and integrate those into our web components, and, likely, or traditional CSS.

In all, we expect this process to take 8 months.

And that’s our product roadmap!

Anne, back to you!

Slide 88: Anne: This is Anne again. This slide includes a screenshot of how you can look at our roadmap directly, along with how far we’ve gotten. So this presents a list of the roadmap items by name, their timeline, their status, and links to the GitHub issues that are related to each. You can check it out yourself at https://github.com/orgs/uswds/projects/13/views/1

Slide 89: So, does what we shared just now in terms of features on our roadmap set us up for success? [pause]

Arguably it sets us up for the next year-ish, but we do intend to take a step back to figure out how we continue to do this better.

I mentioned that this roadmap isn’t ideal, nor done the way we might want. Product managers looking at this version may look at it with some skepticism or twitch a little involuntarily. Roadmaps, by and large, should not be just a list of features to build. We need to get to a more strategic-mindset version, one that brings our mission and vision into focus and makes clear how we’ll move forward to accomplishing them.

We’re also learning how an agile roadmap may work, so we should also note that what we’re sharing today may change as we learn more. We’ll work to validate what we did in the roadmap you see today, or learn that we need to shift one of these goals. We’re also learning how we might improve as we go, think more strategically, and react as we learn new things, or essential parts of our landscape change.

Slide 90: To help provide some grounding, I should note the typical cadence of change in systems like ours: a mission changes the least often. Your mission is your purpose, what you intend to accomplish, and why that’s important.

By frequency of change, that’s followed by a vision, which could adjust a little as you learn more. Your vision describes broadly what’s in the future and how you hope to get there, from the point of view of the person who needs it. Most are aspirational but not unrealistic: what does the design system solve, for who, how does this help, and what’s the outcome?

After vision, the next thing that may change a little more frequently may be your polestar — how you do what you do to reach your vision. This is what you measure your actions against, your guiding mechanism for decision-making. It describes how the team should do the thing, motivating us all and showing how we contribute to the mission and vision. A polestar can also help you figure out if you’re about to prioritize something that doesn’t contribute to the core point of the organization.

What changes more frequently is your roadmap, which you’ll update as you accomplish goals that move you toward accomplishing your mission and vision. Then much more frequently, maybe your API.

But you can depend on the underlying principles, your mission especially. This prevents everything from changing all at once.

Slide 91: So in the interest of supporting the universe of government digital products and sites, our goal here is to introduce structure, and refocus on our mission and vision to create a solid foundation and plan for the system itself, farther into the future, ultimately to serve your systems and products and sites, and thus your users.

So this is how we go from the wild Cosmos universe, all randomly placed stars and cosmic dust, so flexible as to maybe not feel as supportive as it could, to a more consistent system that functionally supports your efforts in a continuous way. A foundation, or a roof, or a net. Here we’re using a geodesic dome at the bottom of the slide to show how all the dots connect here. For what’s next to create this structure, I’ll pass it back to Dan.

Slide 92: Dan: Next, stepping back to mission and vision. We’ll take a look at the current USWDS mission and vision, talk more about what we deliver for teams, and discuss how we collaborate and move forward together to create and support a common vision.

Slide 93: Q&A

Slide 94: Thanks for joining today’s USWDS monthly call. We’ll be back in September to talk about the USWDS mission and vision. Please look out for an event feedback survey from Digital.gov. You’ll get this in your email, and there’s also a link in the chat. Your feedback makes a difference to us, so we’d appreciate the extra time it takes you to provide it.

And if you have a question we weren’t able to answer in the call, or thought of later, please head into our public Slack and ask it there. We’ll be around after the call to answer questions.

Have a great day, and a great August, try to beat the heat!