NASA HCI Design System
Making it easier to create quality digital products for the agency
Summary
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
- HTML/CSS
- Sprint planning
Collaborators
Background
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.
Documentation
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.
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.
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.
Approach
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.
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.
Type
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.
Spacing
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.
Color
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.
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.
- Principles: These are core, single-sentence ideas that we base the rest of our designs on. If you have nothing else to go from, make sure your design meets these principles.
- Foundations: The core pieces that make up everything else in the system. Type, colors, spacing, iconography, shadows, and our grid.
- Components: Fundamental components that make up larger ones. Things like buttons, links, form controls, and more.
- Complex components: Larger components made up of several smaller ones, like dialogs, popovers, and alerts.
- Product-specific components: Our flagship product, Mission Assurance System, has it's own very special use cases and is very complex. There are components it uses thant don't really come in handy for our other work. While we do use them over and over again, we separate these out so the team is encouraged to start with more fundamental patterns for new work.
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.
- Proposal: Things we're playing around with but might not end up standardizing.
- Identified: We've decided as a team that we want to standardize this component, but haven't done much work beyond that.
- Design review: We've begun doing some design work on this component, but things will change rapidly.
- Design complete: We've agreed on the design for a component but it hasn't been implemented into code yet.
- Partially implemented: Some code has been written and published for this component. It can be used in live products with the expectation it may change.
- Code complete: The core code for this component has been written and it's ready to use in production.
- Under review: We're considering making destabilizing design or code changes to this component, so proceed with caution.
- Deprecated: This component might be live right now, but we've decided not use it anymore, at least in it's current iteration, moving forward.
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.
Challenges
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.
Outcomes
Project progress
90%
Of components design complete
40%
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
10%
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.