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.

This manifests as a set of collaboration, inefficiency, and quality issues:

  • Total duplication of work by designers and developers inevitably lead to errors and discrepancies. These bugs are frustrating to both design and engineering; design must either continuously request fixes from engineering or fix these discrepancies, and engineering must allocate resources to what they often deem as low-priority issues. Most design orgs report high volumes of visual bugs that are missed or de-prioritized, a common source of frustration.
  • Because designs are crafted in a different medium from code, designers and developers often must go back-and-forth over feasibility or inconsistency/reuse of existing components.
  • Similarly, implementation of designs can take place across multiple platforms, such as web, iOS, and Android. There is nothing keeping these in sync; it is easy for these to diverge by default.
  • If the production code has diverged from the original designs, designers must spend time updating or re-creating the current look and feel of the production app back in their design tool when building upon existing work, resulting in more duplication of work.
  • Because implementing designs is not a one-time affair, but ongoing over the life of the product, these debts compound through the life of the product.

Plasmic is a system 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 logic/data/behavior into the code in a natural way. Unlike a one-time code export, our goal is to maintain separation between the presentation and logic, so that design can iterate more independently of engineering.

Benefits for having a single source of truth:

  • No duplication of work — Engineers no longer need to spend time creating or updating presentational code that tries to replicate what the designer already created.
  • Designers control presentation — Designers can have control over the design as it exists in the product and iterate faster without being fully dependent on engineers. The resulting actual product is guaranteed to match what the designers have created.
  • Consistency across platforms — Designers can control how similar or different the product looks and feels across platforms like Web, iOS, and Android.
  • Design in realistic environments — Because designers work in the target medium instead of with vector drawing tools, designers can get faster feedback and constraints around feasibility directly from design tool, instead of going back-and-forth with engineering.
  • Developer involvement in design — Developers can comment on designs in Plasmic, and even use Plasmic directly to tweak designs and produce better production code.

Other properties of Plasmic:

  • Zero lock-in — stop using Plasmic any time, keeping the source code already generated for you.
  • Flexibility — developers still own defining component interfaces the way they want. We also accommodate a number of target dialects, styling systems, etc., to ensure we fit in well with your codebase.
  • Integration with design tools — Plasmic complements and integrates with your team’s existing design tools—it will allow you to import your existing designs and component libraries.
  • Incremental adoption — start with a single component, and work seamlessly with the rest of your codebase/components.
  • Production-grade abstractions — design tokens, style presets, and variants enable maximum reuse and systematic propagation of changes.

What is Plasmic?

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.

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, working with existing codebases. 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.

Further learning

The starting point for learning Plasmic is Learn Plasmic. You can follow along with tutorials, read through our developer guides, and explore example projects there.

Thank you for reading!

Was this page helpful?

Have feedback on this page? Let us know on our forum.