Plasmic Studio Guide

Welcome

This guide describes the Plasmic Studio design tool and its core concepts.

If you prefer a more concrete primer to Plasmic in the context of an actual project, check out the +Tour of the TodoMVC Plasmic project.

Please let us know any and all your questions and thoughts!  Reach us on our Slack community or at team@plasmic.app.

What is Plasmic?

Building products is complex.  On product teams, design and engineering most frequently collaborate around a handoff process.  Today, this is a messy process, with multiple rounds of back and forth and many questions being raised.  Designers spend significant time in design tools crafting high-fidelity vector drawings; however, vector drawing tools do not nudge designers towards thinking critically through the different states and contexts they must design for, to make proper use of the design system, and to be considerate of feasibility of implementation; doing so requires a lot of explicit effort and discipline.  Developers take these drawings and recreate the intent of the designer from scratch, by hand, using code.  Inevitably, many things fall through the cracks.  Designers spend further time working with developers on finding and fixing these issues, or they reconcile the quirks of the actual production implementation back into their design files to be on the same page as the real product. Ultimately both sources of truth are almost never in sync, and it takes a lot of repeated manual effort from both sides to stay close to each other.

We see this as a collaboration problem and believe that better tooling can make a difference

Plasmic is a design tool to bridge the gap between design and engineering by enabling a designer-controlled single source of truth for visuals that ship in the final product, while allowing engineers to add just the logic/data/behavior needed to take the designs into production.  Unlike a one-time code export, we allow the designer to continue iterating on the design, and have those new changes be seamlessly reflected in generated code without discarding the work developers have done.

To learn more about the motivation and rationale, please see +Plasmic Background.

Plasmic vs other tools

What sets Plasmic apart

  • Focus on design-engineering collaboration.  Streamlining and automating handoff enables consistency between design and production, helps communicate advanced layout and interactions, and empowers designers to impact the product without needing developers as translators.  Plasmic lets you have a single source of truth across design and engineering.
  • Focus on high-fidelity design.  You can start with your familiar freeform design tool functionality that is critical to exploratory design, but access the tools and concepts needed to refine your designs for production and make your design system scale.  You can represent component states, compose components together, design across different contexts (such as screen size, platform, locale, theme, dark mode, etc.), manage design tokens (color, etc.), all while using a full-featured layout engine that ensures your designs are appropriate for production. 

What Plasmic is not

  • A general vector drawing tool.  While you can absolutely draw screens from scratch in Plasmic, we’re not aiming to be a full Figma replacement.  Instead, we will make it easy for you to import your design assets and exploratory designs from other best-of-breed tools such as Figma, Sketch, and Illustrator.
  • An end-to-end app builder.  Our goal is to help product teams consisting of designers and developers.  While designers will be responsible for how components look, developers will be attaching component behaviors and data storage to Plasmic-generated UI by writing conventional code. 
  • A traditional codegen tool,  which typically import from vector drawing tools and spit out code. A fundamental issue is that the source tool cannot represent various concepts needed for UIs that go into production (states, composition, layout, style abstractions, etc.).  These tools often make a best guess as to the intent of the designer, but are typically far short of the mark because vector drawing tools are just too far apart from production code. At best, these tools provide a rough starting point that developers then heavily edit and mold into a real product. And, ultimately, the code generation is a one-time affair; once the developers have edited the generated code, you cannot generate code (mostly for updated visual design) again without blowing away the developers' changes, severely limiting the design tool’s applicability in a product that requires ongoing iteration.
  • An IDE UI builder.  These focus on implementation rather than design, typically assuming a highly technical user (developer).  They generally do not encourage the fast and flexible exploratory design that is the strength of most vector design tools.  Users are expected to specify in the editor how the UI integrates with the code, such as specifying event handler callbacks or data bindings within the context of the production codebase.

Basic concepts

A project is a “file” containing designs, analogous to a Figma file, Sketch file, etc.  You can share projects, inviting other people as editors or commenters.

  • Components, or reusable chunks of UI, similar to symbols in Sketch or components in Figma.  We describe these in detail below.
  • Reusable styles including tokens and mixins.  We describe these in detail below.
  • ArenaA canvas or workspace, analogous to “pages in Figma/Sketch.  This is where artboards are laid out.  A project has multiple arenas you can switch between. All arenas in the same project share the same set of components and reusable styles.
  • Artboard Where the drawing happens.  Unlike Figma/Sketch, you can only draw in artboards, not in the space between artboards.  An artboard can either be used as a scratch pad, or for editing the master instance of your components. The artboard can also be independently sized (width/height) and placed anywhere in the arena.

Studio UI

The Studio UI has majorly five sections - the top toolbar, the canvas, the left bar, the right bar, and the component panel.


The canvas is the large area in the middle of the Studio UI showing the arena you’re currently viewing.

The left bar contains a few tabs:

  • Tree shows the structure of artboards (and the component in it) in your arena, similar to the layers panel in other tools.  A key difference is that the ordering is reversed from how layers work in other tools; we go top-down rather than bottom-up, so the elements lower on the list will draw on top of elements higher on the list.
  • Gallery shows the components you have built, as well as some basic building blocks you can use in your designs. 
  • Assets shows the reusable styles defined in the project.

The right bar contains info about what you’ve currently selected.  It shows the properties of the selected element or artboard for you to inspect/edit.

The floating components panel is shown whenever your selection is within a component artboard.

Components

A component is a reusable chunk of UI, similar to symbols in Sketch or components in Figma.  You can have small components like Buttons or Icons, large components for a whole Screen or Webpage, and things in between such as Login Form, Tweet, etc.  You can have many instances of any component.