When I first joined 18F, the team had just released the first beta version of the design system, and they were eager to expand the system to cover more use cases; not only expanding the UI components to include things like data visualizations and mobile native apps, but also building and launching products directly on the platform. In a nutshell, cloud.gov is the GitHub Pages for government in beast mode. Powered by USWDS, it comes built-in with the ability to customize design features that meet federal security standards from the start.

To get up to speed, I began by completing a quick literature study of previous research and documentation to better understand how the design system was created and its use. I then interviewed the project leads and product owners, as well as UX researchers, early adopters, and prospect users, to identify the diverse user needs. This allowed me to compare themes and patterns of user behaviors across sources and quickly compare the value of new ideas against the current design system.

I studied how users jumpstart a project from scratch to identify the critical issues in the product development workflow. Collaborating with the core design system team along the way also allowed me to improve the design system itself by simplifying the information architecture, streamlining the navigation, and expanding on the UI components to cover the needs of newer products under development.

While the design system is excellent in supporting design and development problem solving and providing consistency to teams and users, a design system doesn’t answer all design decisions. In reality, teams make their first design decisions long before they consider the design patterns. And the problem with design systems is that having a library of design components can sometimes give the impression that all the design work has been completed. Although patterns do help teams hesitate less and build things in shorter amounts of time, it is the how and the why a group of patterns and components are stitched together that result in outstanding design.

For users to build suitable user interfaces on top of the design system, it’s essential to decide on the structure with a clear hierarchy and logical reading order. Besides, all government websites and applications shouldn’t look exactly the same because trust and recognition are not universal, and the design must instead reflect the tone and subject matter of each agency’s distinct objectives. I started an experiment by designing more robust designs considerably as a starting point for the templates using the existing UI components, pushing the limit as far as it could go. Then to get to those desired outputs, I worked backwards to design the web builder controls, inspired by site builders like Webflow, Squarespace, WordPress, and Behance.

By breaking down the whole pre-built pages into sections and blocks to fill the void between templates and components, people can choose the most appropriate sections based on their content that when pieced together, build an ideal layout that tells a compelling story with relatively minimal design effort. The components that make up sections, such as the hero section, gallery, or graph, each have a specific purpose and are constrained by the overall look and feel established by the initial design template that was selected to provide uniformity across the whole site. All of this can be done without editing the design or one line of code.

This didn't completely remove the need for a developer or designer, but it significantly reduced subtle design decisions, such as the relative proportion of headline and body text or the amount of whitespace that people had to make everywhere previously with the base UI components. With the ability to preview a test site live in minutes, agencies can focus their efforts on more important areas like interactions and content.

Putting it to use, I realized we needed to do more to build trust among stakeholders, especially when they all are very opinionated designers and developers. Most partner agencies initially used the design systems for their websites off the shelf so there was some resistance moving to cloud.gov where they feared that they had to redo all the work. We addressed this in part by building real live sites using the new templates to demonstrate the potential and made an interactive guide to show how little work involved to build and customize with the new web publisher. We tested it first with 18F's own blog posts because of the high visibility and usage, then gradually moved on to updating the whole website and internal tools, before eventually migrating many other public facing products.

After a year of the beta run, we had a running list of hundreds of teams using cloud.gov, creating websites and applications with rich content and intricate data visualizations. In the last quarter alone, over 100 million people were exposed to those services created every day by notable partner agencies, including Treasury, Justice, Interior, Education, White House, Defense, NASA, and Homeland Security.

We continued to see more and more agencies begin relying on cloud.gov building great accessible products and services in record time. We also saw more agencies follow how we expanded on the US Web Design System creating their own iterations to meet their organization and product needs.

Design
JJ Moi / Ryan Thurwell / Eric Ronne / Gail Swanson / Meghana Khandekar

Development
Dave Cole / Marco Segreto / Michael Torres / Jeremia Kimelman

Further Readings
→ Inside Obama’s stealth startup
→ The secret startup that saved the worst website in America
→ Federalist join the US Web Design Standards
→ USWDS 2.0: Reinvent the experience, not the wheel
→ Path to 18F