Moment.dev Branding

The name Moment is a reference to a physics term (the 0th moment) that refers to the amount of momentum needed to move something, such as a wheel on an axle. It is a metaphor for reducing the friction for a team to start working smoothly and quickly together.

I eventually settled on imagery that evoked a spinning wheel or whirlpool, which added some visual movement to the logo. Any similarities to OpenAI (which has become a household name since we launched this brand in early 2021) were completely unintentional.

There were a few major considerations when selecting typography and iconography for the Moment brand. This is a brief summary of a long process that involved many different font and icon tests, but these principles drove my decision-making.

1. Readability for prose and monospaced code. Moment is a text-dominant app, so readability had to come first.
2. Robust selection of icons, and special characters to enable internationalization.
3. Cohesive typography and iconography that feel like they fit together without too much tweaking.

Plex, by IBM, was a natural choice to meet these requirements. It's a superfamily that contains many weights, serif, sans, and mono that are all designed to work together. On top of that, it's a part of the carbon design system which has a gigantic icon library that works really well with Plex. It's also open source!

Plex & Carbon Icons were a natural choice that I don't regret even after three years of working with them. Kudos to the IBM team for providing such an amazing resource.

The color palette was a difficult challenge. I needed to choose a workable color palette in the early days of the product before we had a clear vision for what the product would eventually become. Furthermore, it had to be clear enough for developers to work with, while not requiring me to be involved in every single decision. Robust documentation that wouldn't fall out of date was not a realistic possibility in the early stages of the company.

I settled on creating an abstraction layer of stable design tokens that developers could learn easily, which mapped to a set of primitives I could change as the design system evolved with the product. This diagram illustrates the process.

When the developer needs to add some UI text, they have a limited set of choices. They know it'll either be text-primary, text-secondary, or text-tertiary. A semantic:primitive mapping layer then points that semantic token to a CSS variable, which design has full control over. Those primitive CSS variables can be changed at will for each theme in the app, and the developer never has to learn anything new or refactor any code.

As the designer, it is much easier to control the cohesiveness of the colors while ensuring they are hitting accessible contrast ratios. Changing hex values in single file is a much simpler and less risky thing to ship than needing to change design tokens in many files. It's a system that I am very happy with, and has simplified developer & designer collaboration.