Oh, hey there designer! Thanks for your interest in contributing. Lunchbox wouldn't be possible without contributions from designers like you! We want to deliver useful, consistent patterns and guidelines, so we welcome your feedback, design contributions, ideas, or content suggestions.

Getting Involved

We need the help of designers like you to make Lunchbox into the mature design system we want it to be. But not all contributions are created equal (and that’s okay)! Take a look at our suggested levels of contribution and consider which fits you best:

Levels of Contribution

  • Extra Light: Passive feedback or ideas (i.e. “I found a typo…”)
  • Light: Small design tweaks or content edits (i.e. Tweaking a color)
  • Medium: Adding to or modifying guidelines or participating in the design process
  • Heavy: Designing an entire component

Contribute While You Work

You’re busy. We totally get that. Taking on additional responsibilities by contributing to Lunchbox may seem daunting – impossible, even.

Consider this: Designing for Lunchbox doesn’t need to be completely additive to your normal work load. As you’re identifying patterns and designing solutions during your every-day product work, keep a few things in mind:

  • Is this design component brand new or a different take on an existing pattern?
  • Is it a reusable? Is there reasonable potential for it to be used in other parts of the platform?

If the answer to these questions is yes, consider designing with the platform in mind, not just your specific application. This will go a long way toward designing Platform-ready components. So, what doesn’t being “platform ready” really mean?

Designing for the platform means…

  • Designing for scalability, flexibility, and sustainability.
    • Is the component flexible enough to be used by other applications with varying needs?
  • Documenting specs and usage guidelines.
    • How is it meant to work? How is an empty state handled? Hover state? Error messaging?
  • Ensuring the design component works with existing patterns and/or components
    • Does your component meet standards for style? If placed within a page, will it feel like a natural fit?

Designing a Component

What is a Component?

From a designer’s perspective, a component is a common, reusable design pattern that serves a specific purpose.

Take buttons, for example. Buttons are a common, reusable pattern with a simple purpose: to represent and carry out a user-initiated action. They carry a set of pre-defined styles (spacing, color), states (hover, focus, empty) and usage guidelines (when to use the primary button vs. the standard button).

Design components are made into FLUID components, a collection of HTML, CSS, and JavaScript that allow Developers to easily call the component into their code. The example below shows how a developer would call the a standard button component in an Angular application:

<fluid-button
    tmpl:label="Standard"
    skin="'standard'">
</fluid-button>

The Journey of a Component

Designing a component should follow a similar process to any other design project. Depending on its potential impact, you should spend the proper amount of time researching, designing, and iterating on the component. Once design-complete, the component should be formally placed on development’s backlog. Take a look at the journey of a basic component:

You are responsible for providing UX support to the development team responsible for buildilng the component.

Learn more about each phase in the Journey of a Component here.

Get in Touch

So, ready to get started? You can reach out to the team here:

Not sure where to start? No problem. We’re happy to work with you to figure out the proper level of contribution.

Howdy, developer! Thanks for being a part of building Lunchbox. Our goal is to deliver useful, consistent patterns and guidelines, and that can't happen without your help and support.

Getting Started with Fluid Components

Fluid Components are UI elements that can create consistent user interactions in a framework agnostic way. They enable developers to write code that handles a specific user interaction once, and then use that same code across many different types of codebases.

There are several pieces of technology that have been brought together to make Fluid Components possible:

  • Svelte, the “invisible UI framework”
  • Rollup, the module bundler
  • Jest, the unit test framework and test runner
  • Generative unit testing via TestCheck.js
  • Snooty, a friendly prop validator for component developers
  • A custom plugin architecture to integrate with various first-class UI frameworks (Angular, React, etc.)
  • Plop, our favorite code generator

Read more in the Fluid Components Github Repository

Github Repositories