Cosmos Design System

I led a team to build and maintain a design system for a lunar rover.

What I did

Iris Rover

Iris, roughly the size of a shoe box, aims to be the U.S.'s first private robotic rover to explore the moon's surface. The flight operators use tele-operation ground software to control the rover from Earth.

Tele-operations design team

Iris design team consists of four sub-teams run by students.

As the software became more complex and the team grew larger, Iris ground software team started to face new challenges.

Since the flight mission has to be conducted without error, it was imperative for the design system to minimize the posibilities for confusion and latency.

The team needed a robust design system and organized structure.

🧑‍💻

Designer

"I need a navigation bar, but everyone's navigation bar looks different."

"I need an icon. Is there an icon for this? Where do I get an icon?"

🙋‍

New designer

"What does this feature do? Why is it designed this way?"

"What does this file do? Can I work on it? Can I grab components from here?"

🧑‍💻‍

Front-end developer

"Is this design final?"

"What happens when I click on this? What is the entry point for this screen?"

🧑‍🔧‍

End user: Misson Operator

"I need to constantly monitor the rover’s status."

"I can’t have any error in this mission. That means I can’t have any confusion or latency in the software."

...But Cosmos was still at a very early stage.

We looked into how the team was using Cosmos, and identified the areas that we could immediately improve.

• Components weren't published to the design system.
• Components were not named or grouped properly, and was not being used by the designers.
• Icons were in different sizes, placed on sub-pixels.

Our North Star

We started with setting the goals for the new Cosmos Design System team.

🛠

Functionality

• Cosmos should expedite the design & dev team’s work.
• Everything in Cosmos should be available in Figma to drag & drop from the assets panel.

👯‍♂️

Consistency

• The colors, iconography, and type system should be consistent within all of the sub-teams.
• Cosmos should provide a single source of truth for all the components.

📑

Documentation

• Cosmos documentation should constantly be evolving to accommodate the changing needs of the team.
• Cosmos should provide guidance for the new designers to jump into the system quickly.

Reorganizing Cosmos

Inspired by Atomic Design, I defined our own language and structure for our design system. We also listened to the design team's feedback on how the current Cosmos system was hard to navigate.

We reorganized our design system based on the following structure:

Stars

Stars are the fundamental UI elements in Cosmos that can't be broken down into smaller elements.

Colors & Typography

I ran through all of the occurrences of grayscale colors in the system and finalized the color palette.

Iconography Suite

• We expanded the iconography suite to 24px, 20px, 16px and 12px, following the 4px rule.
• All Cosmos icons share the same underlying grid structure to ensure consistency.

All of the cosmos icons now share the same grid, stroke weight, and naming convention.

Constellations

Constellations are collections of stars that form relatively simple UI components.

Controls Suite

I went through the existing controls and reorganized them into the Controls Suite. I made sure everything:

• follows the 4px rule
• is built from the Cosmos Stars (colors, typography, iconography)
• is named properly
• can be dragged & dropped from the Figma Assets panel
• has constraints set properly so it's resizable
• can switch instances easily based on the component state

Galaxies

Galaxies are collections of stars and constellations that form Cosmos.

Artboard Sizing Guidelines

We standardized the base artboard size to ensure seamless integration of the different features.

Establishing process

I established the Cosmos team's process and ways of staying connected with other teams.

Iteration

Whenever scientists identify something interesting on the moon's surface, they create a Point of Interest (PoI) card to enter it in the ground software. They assign a level of importance and category of the object and later use the object as a marker to plot the rover's pathway.

PoI card is a crucial component that appears in multiple features. Designers in the different sub-teams formed a task force group to consolidate PoIs. I was in charge of consolidating the PoI card and publishing the related components. Here's a rough process of our iteration.

Testing the design system

We tested the split screen interface, another big project of ours, with the soon-to-be mission operators. I wrote the test protocol and conducted the testing. We finalized the tab interaction, split screen flow and the command line interaction.

We also observed other teams' testing sessions to find the problems in the design system.

File management

I consolidated the file types and designed a standardized thumbnail to organize the files and easily communicate what the file is for. Our teammates loved it!

4 file types in Iris Design Team

Before

After

Building a framework for developer communication

As we moved closer to the shipping date, the team needed a well-thought-out framework for the design specs catered to our team's need.

Contextual Inquiry -
Understanding developers' workflow

Since the primary users for the design specs are the developers, I asked to observe how our developers translate the design specs into code. I also interviewed them about what helps or doesn't help them in the design specs.

What I learned

• The biggest pain point for the developers was that based on the current specs, it was hard to know how the screens are linked together.
• Developers have to guess the spacings and font size.
• Sometimes, developers have to ask around to find the designer and ask questions about the specs.
• Unlike what I assumed before, developers didn't feel the need for separate software or a plugin for developer handoffs since all of them were proficient in using Figma.

Sample Spec

Based on what I learned from the developers' workflow, I created sample design specs and tested it with the developers.

I suggested an interactive prototype that the developers can click through. I added redlines so that the developers don't have to guess the spacings.

Impact

• I asked the developers for feedback, and they told us the sample specs were really helpful! They asked us to implement this for all the features.
• The sample specs are being used as the guidelines by the design team for creating design specs.

Next steps

Staying connected

ask-cosmos

We ran #ask-cosmos channel on Slack to:

• discuss the design system
• quickly respond to the team's questions and needs
• keep the conversation up and running

Onboarding the new designers

To help the new designers jump into the system quickly and make the onboarding process as seamless as possible, we made a comprehensive documentation that explains the design rationale, how to use Cosmos effectively and how to navigate the file system.

Teamwork makes the design system work

Designing and implementing a design system was a constant conversation with our designers, developers, and our end users. We're proud that we transformed our design system into something that is deeply integrated into the team's process, and we'll continue to work rigorously to help the team perform to the best of their abilities.