Release 2.10 of the U.S. Web Design System (USWDS) included eight contributions to the design system from a separate product team in GSA’s Technology Transformation Services. We focused on providing tools and guidance to help support federal agencies’ emergency response efforts.
Our team is fortunate to include folks who’ve worked with the USWDS product team on several 10x projects, as well as designers and developers who’ve used the design system at other agencies. Lessons learned from two recent 10x projects — 10x Advanced Form Components and 10x Accessibility in Data Visualizations (summaries available via Trello) — really helped us get an understanding of how work flows into the design system so we could dive in and get early traction.
We identified three key things that contributed to our team success in working with the USWDS product team on projects over the past year.
1. Two, three, four (or more!) minds are better than one
Within the “guard rails” established in our team agreement at kickoff, our project team self-organized to great effect. We worked in concert with the core USWDS product team to establish a sprint cadence, daily retros, weekly check-ins with the Product Owner, and biweekly check-ins with the core team. Ultimately, we also came up with schedules and structures that fit the work—staying collaborative without compromising efficiency. Outside of established team ceremonies, team members synced up in daily user experience (UX) standups, twice-weekly engineering touch bases, cross-pollination meetings, and pairing and workshopping sessions as needed.
This approach allowed UX and engineering pairs to work on specific components in parallel to get more done, workshopping with additional team members when tackling thorny issues while preserving the heads-down time needed for high quality work.
2. Ask for feedback early and often
Understanding the impact our decisions have on end-users of the design system as well as public users of the websites built using USWDS was critical to keeping us on the right path.
We interviewed digital teams across the federal government, and got feedback from the product team, peers, and the USWDS community to ensure we benefited from a diverse set of opinions, backgrounds, and experiences and reflected that back into our work.
We took a many-pronged approach to soliciting feedback, sharing out work to the USWDS community, Digital.gov’s UX community, practitioners from a broad range of agencies who’ve participated in our research efforts, and TTS partners in specialized knowledge spaces like accessibility, structured data, and content strategy.
3. Evaluate in context
No matter how evidence-based, well-architected and cleanly executed a component is, the true test of its adaptability and robustness is evaluating it in the real-world — woven into websites, and used alongside other USWDS components. Building a demo site for the December 2020 monthly call revealed the need for several components to receive a little more love.
We partnered with the product owner to quickly identify inconsistencies and opportunities for improvement, knock those out, and get those improvements into Release 2.10 in time for the monthly call.
Of course, a release isn’t the end of the story. Once a component is “in the wild,” teams start getting creative and really pushing the code further. Without fail, these industrious teams find issues or propose opportunities for enhancement, and we love getting their feedback.
An example in this latest release is the Collection component. Within days of Release 2.10, we were excited to see a participant in the USWDS community post design evolutions to the Collection component.
The customer also identified a tricky “sub-pixel” display bug resulting in a tiny gap on the Collection component’s calendar date in specific display situations. After posting their designs and the bug in the community’s Slack channel, one of our developers followed up with them, and the two collaborated asynchronously in Slack to knock out the bug and create a pull request. The fix quickly worked its way into the design system!
Directly involving end-users in the development of features and fixes is exactly the kind of participation that makes the USWDS community so special. We have the chance to see folks take USWDS components and “make them their own,” and we can count on rapid identification of potential issues, enabling us to respond quickly.
If you’re using or thinking about using the design system, we’d love you to join the USWDS community, where you can share feedback on upcoming features, post your amazing work, ask for help from the community, and let us know about any gotchas like that sub-pixel bug.
We’d love to hear from you.