Using the USWDS as a UX Designer

USWDS blog post - design.png

At Truss, the USWDS is the core design system we use in our government projects. In order for a design system to be properly implemented, there needs to be folks from all roles on a project that understand and advocate for its use. As it’s in the name, designers are at the core of ensuring a design system is used effectively. In this edition of our USWDS blog series, I’ll go over some basics of getting started with the tools for designers provided by the USWDS and show how we use it in practice on the MilMove Design team.

Getting started

The USWDS has a couple of resources for designers. It has a design library built and maintained by the GSA Technology Transformation Services for both Sketch and Adobe XD

Recently, fellow Trussel Josh Franklin took some time to convert the design system for use in Figma (using Maya Benari’s version as the starting point).

All of these platforms have their pros and cons, and you can choose the one that works best for you and still enjoy the library on any of them.

A preview of the demo project in the Sketch version of the library. https://github.com/uswds/uswds-for-designers

A preview of the demo project in the Sketch version of the library. https://github.com/uswds/uswds-for-designers

If you have never worked with a design library before, it uses the Library functionality in your UI design software to provide you with a set of pre-built symbols for all the elements and components you might need. That way you can focus more on your user experience, instead of fretting over aligning every pixel correctly each time you want to use an element. 

If you decide to change something, you update the symbol in one spot and it will change everywhere — much like how, if you update a component in production, it will change all instances in which it's called in the code. 

Working in a design system helps designers think more like the engineers who are implementing their work, and better simulates the implications of your decisions. Anything that can facilitate more empathetic collaboration across disciplines will result in stronger outcomes!

spacer-3.png

Customizing the system for your project

Once you are up and running in your preferred UI design software, you can choose to work with the USWDS in all its defaults and start building out mockups. In other cases, you might find that your particular use case requires that the system be customized to align to your organization’s branding, or you might need to make your own components to account for ones not currently included in the USWDS. The library files enable designers to make adjustments to base units and colors as needed, so if you want to get fancy, go right ahead. As an open source project, you can propose components to be contributed to the project too.

In the case of the MilMove project, we customized the USWDS to meet the needs of our project and call the outcome the MilMove Design System.

Design principles to guide your decisions

Another important aspect of the USWDS, which sets it apart from other UI libraries and design systems is its Design Principles:

These design principles are intended to help teams across government align on important common goals and better use the design system — to be an evaluative lens for design and implementation decisions. Regardless of how you build, any USWDS project should support these principles.

Those principles: 

  • Start with real user needs

  • Earn trust

  • Embrace accessibility

  • Promote continuity

  • Listen 

Together, they add something really important that most design systems lack. They promote the ideal that as designers we should do our work with empathy and awareness for our users. 

While this is important in all the work UX designers do, it’s of particular importance when it comes to government services. Our users don’t have the option to not use them, and they usually can’t find an alternative.

Working with a design system and a set of principles better sets us up to work as the bridge between user needs and the solutions we are going to provide to address them.

Bringing your designs to life in the browser

At Truss, we are always looking for opportunities to facilitate stronger cross-discipline collaboration. I currently work on the MilMove Design & Research team, and right now, my main focus is the implementation of our design system in the browser.

I work alongside the engineers on the project to build out all of our components in Storybook, a development environment for UI components. It allows you to browse a component library, view the different states of each component, and interactively develop and test them. As a part of that effort, the other designers on the MilMove team have created spec sheets and sticker sheets of all the components in our version of the design system.

My role on the project at the moment is working within the Design and Research practice to interpret and build out these specs in production. I stand up static versions of our react components and style them for our engineering teams working on the project to pick up and use as the building blocks for building out the application.

Since we are using Abstract for our project, we can make use of their developer tools to obtain helpful values for our SASS/CSS code, such as hex color values and font sizes. The designers on my team take this a bit further by providing any applicable USWDS token values, which developers need in order to make use of the USWDS utility mixins and classes. This also ensures we have design parity across our design files and production implementation on our components.

Our project Storybook - http://storybook.move.mil

Our project Storybook - http://storybook.move.mil

When working with this system as a designer, it’s really important to be prepared to work shoulder to shoulder with the engineers on your team. Our team includes the project’s designers as reviewers on any PR that affects the the system’s interface to see that the design system is used as intended. This collaboration is the key to the success of our design system and the implementation of the USWDS tools that are behind it.

User testing and research

While using a design system can empower you to design more inclusively and efficiently, you should still keep USWDS Design Principles in mind. They are as much a part of this design system as its UI elements.

In particular, starting with real user’s needs is a critical step in any design process. Using a design system can help you to be more flexible and agile to accomplish this, but know that it covers a single aspect of the process. A design system like the USWDS can help you create more adaptable solutions, but you will still need to user test in order to understand what needs to adapt.

To build truly useful and revolutionary software, user testing and research are essential.

Learn More About the USWDS