Skip to main content

NASA HCI Design System

Making it easier to create quality digital products for the agency

A collage of sample components from the design system.


As my team grew and the number of projects we were supporting increased over time, we were accruing lots of technical and design debt, and it was harder to do our work. I led the creation of our first design system to help overcome some of our most pressing challenges. Since the project began we've designed and implemented over half of our components, and we've been able to spend more time on things like accessibility and performance.

Since the project began, we've agreed on designs for almost all of our components and increased the number of issues the team has resolved per sprint by 10%.

Project details

My contribution

  • Product management
  • Facilitation and workshops
  • Interaction design
  • Visual design
  • Sprint planning


My team, the NASA HCI Group, designs and builds internal software for human spaceflight groups at the agency as they track data and make decisions. In the past two years, we've doubled in size, and the number of products and user communities we are supporting has increased exponentially. It was getting harder to design and build quality products. We were spending too much time working on small things like what a button should look like and not enough time on more important things like accessibility or performance. Our user interfaces were increasingly inconsistent, even within the same product. At the same time, our engineering team was undertaking an effort to rebuild key pages of our flagship product in React. While great for performance, we risked introducing even more competing standards. We knew the time was right to start thinking about our design practice in a new way.

A few colleagues and I began an effort to solve some of our biggest challenges with our first design system.

Our goal was to create a set of standardized components that would decrease the work required to maintain quality digital products for the agency.

The Design System

I'm responsible for four main parts of our design system: the documentation, Sketch library, icon pack, and content guide.


The most important part of our design system is the documentation. It's the nexus between design and engineering, and solves the core issues we identified of communication and sharing our common understanding.

We drew heavy inspiration from how other teams from Google to Shopify to the federal government did this. Each component page contains a summary, a live example, code snippets (React, Stylus, HTML, and CSS), visual design details, guidance for use, and accessibility guidance. It also contains links to sources. These might be other design systems, usability research, or our own, primary research. We document our sources because we want every decision we make in the system to be justified.

While other organizations have beautiful, public documentation sites, we wanted to be able to write and publish quickly. We already used Confluence for our other team documentation, so we created a new space there for the design system. This allowed us to publish changes quickly and often in a place that our team was already familiar with.

Three screenshots from our design system documentation.
Our Sketch library.

Sketch library

Our design team is primarily using Sketch these days, so we created a UI kit to make implementing the design system standards easier. This helps us solve a core issue of consistency within our design specs. By creating a Sketch Library file, designers are able to call up our components from any blank document, and they are automatically updated when we push changes to the system.

Icon pack

While our icon set is included in our Sketch Library, we also created a standard icon pack of ready-to-use PNGs and clean SVGs. This acts as a resource for designers who don't need to import the entire design system and for engineers to quickly grab new assets when they implement new components.

A few select icons from our pack.
The 'Abbreviations and acronyms' page from our content guide.

Content guide

We write a lot for our products. From inscriptions to labels and error messages to help guides, we didn't really have a standard on voice, tone, or how we approached mechanics like abbreviations (and there are a lot at NASA!) or technical words. We created a content guide to ensure a consistent style and keep our UI copy easy to understand.


While my colleague Chris and I had created limited UI kits in the past to help with our work, we knew we needed to do more to fundamentally transform the way the team worked and create lasting change.

Interface inventory

We began by taking a look at our current products and inventoried all the inconsistencies we could find, in both appearance and behavior. We uncovered more than 100 issues and added them to a running list.

A screenshot of a Google Sheet listing our more than 100 UI inconsistencies.
Our running list of interface inconsistencies. We used this as a starting point to guide our work and as one way to illustrate the problem to our team.
Five samples of different styles of alerts from our pre-existing designs.
We uncovered inconsistencies in how our elements looked even within the same product. For example, here are all the different ways we rendered alerts in our flagship product, Mission Assurance System.

Building foundations

We found some of the most fundamental inconsistencies in the very basics of our interface: typography, color, margins and padding. These things added up, and we knew in order to build a strong design system, we'd have to agree on some foundations.


At NASA, over 95% of our users are using Internet Explorer on Windows machines in a very tightly controlled IT environment. We wanted our text to be readable, simple, and something everyone already had on their machines. We were pretty much already using Arial everywhere in our products, so we decided on that. However, we had very inconsistent heading and paragraph styles, so we documented that based loosely on a standard type scale.

A snippet from our design system showing a few type styles.
A snippet from our design system showing how we do margins and padding.


Our margins and padding were all over the place. Not only did this mean page layouts looked… janky, but also that the information hierarchy on many pages was unclear. Taking some inspiration from Nathan Curtis, we outlined a base 16 spacing system that scaled non-linearly, making it easy to tell the difference between grouped parts of the page.


The colors in our products were varied and highly inconsistent. For instance, we were using over ten different hues of blue for basically reason. We also used and inconsistent set of colors for semantic meanings like errors or warnings. In addition, many of our color combinations didn't meet the minimum contrast recommendations required for accessibility. I was primarily responsible for creating our new palette.

I took inspiration from systems like Google Material, Mineral UI, Trello, and the colors we were already using to standardize our system. We defined a basic set of grays to use for most things like text, and a set of four semantic colors for errors, warnings, success messages, and information.

For our extended palette, containing many more colors from the rainbow, I outlined twelve hues, each with four steps. I limited the number of steps so it was easier for our team to make choices, but left room in case we wanted to add more later. In order to make the whole set cohesive, I introduced just a hint of "NASA blue" into each hue.

The most important part of creating our color palette, however, was providing guidance on accessible color combinations. For each swatch, I included it's WCAG contrast rating against white and our darkest and lightest grays.

A few swatches from our color palette.

Making (and measuring) progress

It was one thing do create the system, but another entirely to make it easy to use for our team and ensure adoption. As product manager, it was my responsibility to create a process for implementing and contributing to the design system. I did lots of research on existing design systems and leaders (including GitHub and our federal friends at 18F), and tried to create a process that worked for our team's unique needs.

Component framework

We adapted Brad Frost's Atomic Design to suit our needs. We divide the "things" inside our design system into five main groups.

Component statuses

When did we know we were "done" with a component? And how could the team know whether they could use something in their designs or code? I defined a few statuses that worked for our process.

A cadence for designing, building, and releasing the system

Drawing yet again on some fine reading from Nathan Curtis, I created a work and release cadence that fit into our existing process.

We were already doing engineering sprints on our other projects, so I introduced design sprints in order to structure the design work as well as provide an output that could be picked up by our developers as each new sprint began. The designers' work would be primarily focused on making updates to the design resources like our Sketch Library and the documentation, with code changes being made by engineers on their own schedule. While we proposed some code in our documentation to help our engineers get started (and giving me an opportunity to flex some of my HTML/CSS skills), we left most of the implementation up to them. This let us make progress without significantly uprooting our existing release cadence.


Making the system that was right for us

Lots of companies have well polished, gorgeous design systems that they can publish and maintain for public use. We don't have the same resources as most of those teams, so for us, we focused heavily on what would have the most immediate impact to our process and, as a result, our customers.

This meant moving rapidly, documenting as we went, and iterating over time. It meant not being afraid of having messy documentation. It meant using the vocabulary of the team, even if it didn't always match up with what we saw in the rest of the industry. And it meant designing patterns that were right for our users rather than doing things just because they are trendy.

Getting buy-in and keeping people included

The design system represented a huge change in thinking and process for our team. While no one was necessarily hostile to the idea, it was difficult to convince some folks that the system would be valuable and not distract from the "real" work.

My colleagues and I working on the system kept fighting, presenting often to our team leadership and keeping the rest of the team apprised of changes with a weekly (most of the time) newsletter. We made sure at every turn to continue illustrating the value of the design system, the main idea being that creating a better process for us meant better product outcomes for our users. Through a grassroots, bottom-up effort, and an emerging top-down buy in, we've managed to make progress.


Project progress


Of components design complete


Components code complete

To date, we've compeleted design work on almost half our components, and development work on almost half. There's a ways to go before everything is fully implemented, but we're seeing both designers and engineers start to adopt the system and think in a new way.

Improved workflow


More front-end tickets completed per sprint

It used to be that every front-end update needed a designer's full attention and a lot of back and forth between design and development. "Smaller" issues were ignored because of cost. With even a partial design system in place, we've seen a noticeable increase on what the front-end dev team has been able to accomplish in each sprint.