Slide 1: Hi there and welcome to the U.S. Web Design System Monthly Call for October 2021. And for October, the USWDS logo has spooky Halloween colors.

Slide 2: My name is Dan Williams, and I’m the USWDS product lead and this is my avatar, which probably looks a little like me. Thanks for being here!

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.

I’d also like to remind you that all attendees must abide by the TTS Code of Conduct, which is online at handbook.tts.gsa.gov/code-of-conduct. We’ve posted the link to the code of conduct 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, to kick things off, a quick poll: Which of these services are you able to access at your job?

Answer 1: Email Answer 2: GitHub Answer 3: Slack Answer 4: YouTube

If you’re interested in answering, give it a go. We’re just interested to hear more from folks on the call. If you can’t see the poll or can’t access it for any reason, either put your answer in the chat, or just feel comforted that it’s a pretty unserious poll with no stakes. We’ll share the results in just a minute.

Slide 4: So. what’s our agenda for today?

First we’ll show off a few nice new site launches.

And then we’re going to talk about community, connection, and contribution — how we’re all trying to solve problems together, and why this is particularly valuable to the design system community.

And I’ll try to keep all this down to about 30 minutes or so. We’re trying to deliver more snappy monthly calls. This should give us some more time to get questions and feedback from you — so ask questions in the chat as we go, or hold on to your Qs to the end. 

Slide 5: Let’s get into site launches.

Slide 6: First up, MadeInAmerica.gov — MadeInAmerica.gov supports policies that increase reliance on domestic supply chains and reduce the need to spend taxpayer dollars on foreign-made goods. Its homepage shows a big red white and blue hero image featuring auto workers and the president.

Slide 7: Also this month, Evaluation.gov — Evaluation.gov is the home for Federal program evaluation and the Evaluation Officer Council. Evaluation.gov brings together the plans and activities that drive evaluation efforts across the Federal government. Its homepage shows a large welcome hero with an image of line graphs in the background.

Slide 8: And finally, dsld.od.nih.gov, a new site update for NIH’s Dietary supplement database. Its homepage is oriented around search. This site was recently redesigned to incorporate much of the USWDS and improve the user experience of searching and browsing the database — and it shows. This is a great example not only of using and adapting USWDS, but building other features — like faceted search — that complement the design system styles and components. Nicely done.

Slide 9: Great work, everyone! Be sure to let us know when a new site launches, either with an email to uswds@support.digitalgov.gov or a note on the USWDS public Slack channel.

Slide 10: This month’s talk is all about community, connection, and contribution.

Slide 11: So pretty much the main reason to have a design system is to help scale the things that work. Our job is to help identify solutions and best practices and build the tools that help teams use them in their projects. From the start, this was something we thought of as “Making the easiest thing the best thing.”

We try to help teams focus on high value problems and spend less time on the problems that teams have already solved effectively, like how to build a button or what makes an accessible form.

Slide 12: Because it’s hard to build websites and digital services. There are thousands of decisions that go into even the simplest site. And these aren’t decisions that are best made alone.

The most effective teams are cross-functional teams, working together and collaborating to solve complex problems by approaching them from different angles.

Slide 13: Just the nature of the problems, means that design system projects are collaborative projects. Typically, in some way, creating a website or service is going to bring together

• Developers and engineers
• Designers, researchers, and writers
• Strategists, and program managers
• And even lawyers and executives

When you’re talking about building websites and digital services, you’re already talking about the necessity of collaboration and working together.

Slide 14: Now, this kind of collaborative work is complicated, but it’s also really cool! It means that the design system community naturally has a lot of different perspectives. And this is something of the flip side to the heterogeneity and fragmentation of the landscape of federal websites and services. It may be fragmented, but it’s incredibly diverse, with all kinds of people solving all kinds of problems with all kinds of tools. There is incredible potential here!

Of course, we understand the problems of fragmentation as well:

• Lack of resources
• Lack of knowledge
• Lack of coordination
• Duplication of effort

Fragmentation and work silos can mean that even teams at the same agency might not have much insight into what their colleagues are doing, much less their colleagues in other agencies. Feds and contractors are spread far and wide working on a bewildering number of problems from every conceivable angle. So if one of the goals of the design system is to help teams spend less time on problems others have already solved effectively, the challenge is not always about the fragmentation and diversity of effort. This can be an asset — seeing problems from lots of angles — but that asset can’t be fully realized unless we’re able to share the solutions we’ve discovered.

The problems of this model are communication problems.

Slide 15: Now I probably think about this perhaps apocryphal quote attributed to William Gibson much more than is reasonable, but it’s as true in government as anywhere: “The future is already here. It’s just not evenly distributed yet.”

Slide 16: What does that quote mean to you? I’ll tell you what it means to me, and it isn’t necessarily a bad thing. As I interpret it, uneven distribution is normal, healthy, and pretty much the state of any complex system: evolution does not — and perhaps cannot — happen evenly across the entirety of the system. Adaptations tend to happen locally at first, then spread. And the degree of the spread is a factor of the fitness of the message (usually the effectiveness of the solution), and the connectedness and sensitivity of the system.

Slide 17: If you don’t get a message, it’s hard to learn from it. If you don’t know what others are doing, it’s hard to know what they’ve learned.

The design system provides a rare opportunity for increased connectedness between the many individuals, organizations, and teams working on pieces of this enormous problem, the problem of an effective digital government.

I can’t count the number of times I’ve met with my colleagues across government and thought to myself: “Wow, I can’t believe you’re doing that. I’d never heard of that project! I wish I knew about this last year!” If we were better able to share even a tenth of the work we’re all doing, and actually be able to learn from it or build with it and from it, it would be a transformative resource and opportunity.

Slide 18: How can the design system and the community that surrounds it help make this happen?

And this, I suppose, is the time to acknowledge that, like many teams, we are a small one — stretched even to do the necessary core product work. And this is part of the problem, when there’s little time to look up from your work, it affects how much you’re able to see.

Yet, we know that it is part of the mission of the design system to help scale solutions across government, that this is a critical aspect of our core responsibility, just as much as fixing bugs, usability research, and ARIA labels.

Here, perhaps, the problem is another way of restating the solution: We’re a small team, and we can’t do it alone. We need each other. And we hope that if we can be strategic, and we can be as smart as we can be, the energy we put into contributing to the strength of our community is energy we may see again, transformed.

Slide 19: Now, real talk: this monthly call, it takes a lot of time and energy. Thinking, writing, coding, production, behind-the-scenes, it can be exhausting. But still, there must be something to getting up month after month and putting yourself out there. Sharing what you’re doing and what you’re thinking. Trying to work through — sometimes knots and all — the complex task of doing this kind of work in public. This is definitely not just a PR or comms exercise, and I hope it never comes off like it.

Now, just a small question for everyone here on the call. I was wondering if, in the chat, you might briefly let us know: Why do you attend monthly calls? What, if anything, makes it worthwhile to you? It doesn’t have to be very thoughtful; I know I’m just springing this on you!

So, if you’re comfortable answering, please do.

Slide 20: While the monthly call can be something of a one-to-many communication — the equivalent of standing on a soapbox with a megaphone — we think that much of the practical work of the design system community happens in a more interactive forum like Slack or GitHub.

The reality of the landscape of design system implementations means that for many questions, you — not us — are the best source of information. Your teams are the teams that know best how to integrate USWDS into Drupal, how to use USWDS in a React project, or an Angular project. You may know better than we do just what kind of team it takes to use USWDS. You may know better than we do just how to create parent and child templates.

So in a very real way, when it comes to implementing the design system and the nuts and bolts of day-to-day usage — you’re the experts.

Slide 21: It’s our challenge to help the right teams connect, and build the knowledge that you create into our canonical body of guidance.

We have many of these discussions in Slack, but we also know that there have been some grumblings about the recent security and sign-in policies that make Slack harder to access. We also know that not everyone can access Slack or wants to. To that end, we’re going to be doing some more experimenting with another place to have similar conversations, in public, in a common message-board format: GitHub Discussions.

Slide 22: To talk a bit more about what we’re doing with GitHub Discussion, here’s James Mejia, a developer on the USWDS Core team. Take it away, James.

Slide 23: JAMES MEJIA:

Thanks Dan, and thanks to everyone for being here.

As Dan mentioned, we want to use GitHub Discussions as an additional way to publicly discuss USWDS. We hope to take advantage of Discussions to be more engaged with the community. Similar to other open source projects like Gatsby, Tailwind, or Laravel.

Slide 24: On the screen, we see what the Discussions landing page would look like for an anonymous user. There are a handful of discussions by contributors with a side navigation of categories to the left.

You can view discussions at GitHub.com/uswds/uswds/discussions.

Discussions are an open forum. They read like posts similar to Reddit, which means you can upvote or react to any messages you find helpful.

If you have a GitHub account you can create posts under the default categories. We have General, Ideas, Q&A, and Show and Tell.

Anyone can view discussions. No GitHub account required. So you can still follow along and stay up-to-date. But if you want to interact with fellow members of the community, you will need an account. So we encourage you to sign up and join the discussions.

If you don’t have an account, you can easily create one with GitHub’s interactive sign-up. You can find that at GitHub.com/signup. There are only a few discussions up right now. We hope to change that moving forward with your help. We want to hear what you have to say. You don’t have to be a developer to contribute.

Slide 25: There’s an open discussion from a community member asking for additional context behind a development decision.

I hope you’ll be encouraged to sign up and contribute to the conversation. So with that said, let’s talk about the types of discussions we’d like to see. We want these discussions to be productive for everyone. So we’re looking for discussions focused on the product of USWDS.

That means anything related to design or development decisions, research, or general discussions that help improve USWDS going forward are welcome.

On the other hand, if you’ve found an issue with USWDS code, guidance, or would like to request a specific feature then please create an issue in the USWDS repo. This will allow us to triage and prioritize it in our upcoming sprints. But please don’t be discouraged from creating a discussion. They can be a good way to get to an eventual issue or feature.

Slide 26: Don’t be afraid to contribute. Here we can see our host and product lead, Dan Williams, answering a user’s question by providing an update to our decision.

We want everyone to share their ideas and thoughts. So please, don’t be afraid to contribute.

Here are some GitHub recommendations for good conversations:

• Ask pointed questions and follow-up questions
• Distill long posts down to main points
• Be proactive and create issues based on conversations (where applicable)

Best practices for community conversations on GitHub - GitHub Docs

One good example of the types of discussions we’re looking to have are presentation follow-ups. Here, we have a follow-up discussion from last week’s Drupal GovCon presentation. It contains a summary with key points and feedback from members of the audience. This is the format we’ll try to follow for our upcoming Beta release.

Slide 27: Speaking of the Beta release, our second Beta release will be out later this month. It’ll include the latest code from this current stable release and our new component centered architecture, and we’ll be working toward organization scoped packages within the design system.

Like we mentioned at September’s monthly call, we want to make updating USWDS easier. So hopefully downstream users won’t notice too much of a change from stable to beta. But that’s why we’re going to be starting a GitHub Discussion.

If you’re interested at all in helping us test the beta, please join the discussion. You can find the link in chat. [GitHub.com/uswds/uswds/discussions/4365]. We’ll be covering features, how to update, and gathering a list of potential testers for future upcoming betas.

We want to hear what worked, what didn’t work, things you’d like to see. If you run into any issues, please post them there first and we can triage into a bug report.

A brief description of the issue, some steps to reproduce, and any information like OS, version of node or NPM, and how you’re using USWDS will be extremely helpful in squashing these bugs.

If you poke around current discussions, you’ll see me or Dan responding to development questions. Which is great! But our team is more than development, so we hope to engage with other practice areas that use USWDS. We look forward to seeing you on GitHub Discussions! Thank you!

DAN WILLIAMS: Thanks, James! I’m certainly curious to see how this works out. The fact that it’s pretty much completely public (and findable) might allow some others to participate that previously never even knew we had discussions like these.

Slide 28: We know that at least one specific reason that we do what we do is that teams need timely information to make good decisions. They need to know what’s changed in the design system. What’s coming and how it affects them.

So based on our poll at the beginning of the call, with Slack access at 55 percent, GitHub Discussion access at 75 percent, YouTube at 95 percent, we also have this Monthly Call (which 100 percent of you can access), as well as email, which also has 100-percent access rates. We’re trying to have a good mix of different ways to not only get the word out but to get the word back. And, in some instances, to encourage conversations that we’re not even a part of. But this month, we’re also starting to do something that — in retrospect — seems obvious. We’re also starting a monthly newsletter.

And to tell you more about what it is, where to find it, and how to get it, here’s the Core Team’s Kathryn Mullan!

Slide 29: KATHRYN MULLAN Hi everyone! I’m Kathryn, and I’ve been on the Core Team since January 2021 as a content strategist, and I also work on the team’s communications, outreach, and engagement initiatives. It’s a pleasure to be here presenting at this month’s call!

Slide 30: We want to be strategic and intentional.

This past summer, we held some team strategy sessions — looking at new approaches to the monthly call and other channels we wanted to better leverage to build our community and increase engagement. 

As our Core Team looks at the variety of channels and ways of communicating with one another, we are asking ourselves: “How can we best leverage each one to meet our community where it is?” How can we be strategic and intentional about this communication? 

Slide 31: Different channels (more centralized)

Related to the uneven distribution Dan noted earlier, we want to strengthen core channels where our community regularly meets, share solutions across agencies/organizations, and offer support for a variety of team-roles for ongoing collaboration and education.

Part of that strategy is determining “what will we talk about where,” so we are clear about where we post certain topics and threads for engagement and where our community can find key updates. 

So at this point in time, where do we engage? Slack, GitHub, monthly calls. But we also see one another in the “penumbra” of the design system: list-servs, COPs, huddles (design/dev/content), meet-ups, and technical conferences like Drupal GovCon. So these are “different channels that are more centralized,” but then, there are also…

Slide 32: Different channels (less centralized)

“Different channels that are less centralized.” As we look to the next major release of the design system in early 2022, we are opening new channels to experiment with communication and engagement. 

• Each channel has a purpose, to help better connect and inform all users across the community.
• What key updates does everyone need to know? What’s new & notable? What are we thinking about that we also want to think about with you?
• Essentially, diving into key topics/themes that are the very life of the design system itself. Adding communication-connectors is like adding more ligaments to help the “bones of the DS” move more efficiently. 

Slide 33: Meet folks where they are.

We are taking a multi-pronged approach to meet you where you feel comfortable communicating. Not everyone is on Slack. Not everyone can access GitHub. So we will ping key messages across a few channels —given the diverse nature of our community— to reinforce themes and connect across a few platforms. The “important thing is that we’re able to meet folks where they are.”

• Our goal is for everyone across the community to stay up-to-date with the design system, as we pivot to the next major version.
• And speaking of our “multi-pronged approach,” we now bring you our newsletter!

Slide 34: We have a new monthly newsletter: Wave. (Waving hand)

We’re going back to the reliable email platform — tried and true!

This comms piece will collect timely information, key updates, helpful resources, tips, and more. The launch date is imminent; we’re just sorting out a few last details, so watch your inbox!

Slide 35: A monthly newsletter

So let’s dive in and take a look at what this newsletter will entail. This slide shows a clip of the design with our branded header and logo, an overall clear, minimalist text-based approach.

We introduced the concept of a newsletter at this past summer’s strategy session. The goal of this piece is to build more connections within our community, as one of those new “ligament additions” I just mentioned. 

We created this as a way to extend conversations well beyond our monthly call — essentially, as a means for the content to live on in a different format, one that may be more easily accessed and referenced by larger audiences. We plan to send this the first week of the month. 

Slide 36: Things you might not know about

So let’s jump into a quick tour of the newsletter and what to expect. The opening sections will cover the “things you may not know about,” such as content updates, guidance improvements, and other new features. 

This slide shows another cut of the various sections and types of topics we will cover in a simple text layout.

Slide 37: Product updates and items from the monthly call

There will also be different sections for key product updates, recent releases, and site launches. We will include top-line points from the most recent Monthly Call and include a sneak-peek at the next month’s event.

This slide just shows the last section with more of the same text layout and minimalist design.

And as this platform continues to build out, we will look at ways a newsletter can better serve our community, as a means for “asking questions and providing useful feedback” as the DS continues to grow. 

Adding these newsletter features over time:

• Some polling functions (gathering data/intel to share in either MC or next newsletter)
• Calls-to-action

We also plan to link out to these newsletters from our site.

Slide 38: Check your inbox.

So if you want to be on the list to receive this design system newsletter, we have a new signup link on our website, at the bottom of each page in the pre-footer…

And you’ll also find that link in the chat.

We look forward to engaging with you around this channel! Now back over to you, Dan.

DAN WILLIAMS: Thanks, Kathryn! And look out for USWDS Wave in your inboxes. 

Slide 39: If there’s maybe one takeaway from today, I’d say it’s “we can’t do it alone.” As the design system, we certainly can’t. Very few of us can. Even fewer of us should. We have an important opportunity here to build connections between projects and people. I don’t know if we could ever do enough, but we’ll keep trying. 

Sometimes the best thing you can hear, particularly when you’re struggling to do something hard, is that you’re not alone. Thanks for being out there. Keep it up; the connections we make and the way we share and solve problems together are perhaps as important as any bit of code, any color, any component we publish. Perhaps the product is this, and not that. 

And now, let’s answer some questions.

Slide 40: Q&A

Slide 41: Thanks for joining today’s USWDS monthly call. Next month, the monthly call will be on November 18, the third Thursday, and we’ll be discussing “what we’re thankful for.”

And, as always, I encourage you to join our community in the #uswds-public Slack channel so you can follow our progress, get answers, and contribute to the discussion.

Follow us on GitHub at GitHub.com/uswds, check out our website, and visit designsystem.digital.gov/about/community to join us and your colleagues across government who are using USWDS.

Thank you, and see you next month!