Welcome to the Lumere style guide.

The goal of this document is to serve as a reference for the basic elements that make up our user interface, to give examples of their use, and to define the contexts in which they should be used. It also covers user interface copywriting, formats, and basic interaction patterns. Topics relating to the overall Lumere brand or to marketing-specific guidelines are not covered, except insofar as they pertain to the user interface.

This is a living document.

Our products mirror the process by which they're developed—they're iterative, agile, and in a state of constant change and improvement. As our products evolve, so too do our conventions for visual design, interaction, and writing. When these changes are introduced into the software, the guide should be updated accordingly, including the addition of new UI patterns and standards.

This is a collaborative document.

Like our wiki, this style guide is a group effort. If the markup for a given component changes, please make sure you update the comments to reflect this change. Likewise, if you're adding a new helper class to a documented component, make sure that class is included in the appropriate section of the style guide.

Design principles

Whenever conditions are such as to prevent the act of production from being an experience in which the whole creature is alive and in which he possesses his living through enjoyment, the product will lack something of being aesthetic. No matter how useful it is for special and limited ends, it will not be useful in the ultimate degree—that of contributing directly and liberally to an expanding and enriched life. —John Dewey

Ultimately, we strive to help our users make better decisions and realize better outcomes by empowering them and making their lives easier. We always need to remain cognizant of the fact that our users’ relationship with our solution is not merely functional, but also emotional. If our products cause frustation, our make our users look bad in front of their peers, we’ll have lost their allegiance and trust, our most valuable asset. Conversely, if we enable them to reach greater successes and delight them through the ease by which they can accomplish things, we’ll create advocates and allies that help us to do better and better work.

It’s important to remember that each small component of an experience contributes to its totality, and that no detail is too small to be important to a user’s perception of the product.

Where there is output, let there be input. —Alan Cooper

When presented with editable information, users should not be forced to navigate to a separate page or mode. Instead, provide controls nearby allowing them to directly manipulate the information.

No matter how cool you think your interface is, it’d be better if there were less of it. —Alan Cooper

User interfaces, particularly for new features, should begin by presenting the minimum viable quantity of content and controls. This doesn’t mean that the interface can’t be powerful, or allow control over complex functionality—only that it should appear simple, and avoid including elements that don’t directly support the user’s goals. If you’re questioning whether someone needs to know something or do something at a certain point within your UI, leave it out.

Lumen design system

Our design system is organized according to a series of principles that aid us in bringing clarity to our interface, maintain consistency, and communicate intent to our users.

Group related content or functionality within a discrete container (Gestalt principle of containment).

• Containers help our brains to recognize a set of individual elements as related to one another. In the context of a user interface, this assists the user in quickly understanding the relationships between a set of individual elements, independent of other content that may be present on the page.
• Each container, like a ribon, card, callout, or filter form container, should have border and utilize the $default-box-shadow variable to give it dimensionality. This helps each container to communicate its purpose as a discrete functional or informational unit.

Containers should be discrete and not collide with one another or overlap on the same z-layer.

• Each container can be thought of as a physical object, for example a sheet of paper placed on your desk. It can be placed adjacent to another sheet of paper placed flat on the desk, but the two can't overlap without being on separate planes along the z-axis.
• Within a single z-layer, consistent horizontal and vertical spacing between containers should always be maintained.