Plasmic as UI builder

Plasmic is most commonly used for:

• Building apps
• Building websites
• Content management

However, there is another way of wielding Plasmic, as a UI builder devtool.

Here, developers use Plasmic to craft the presentational design of your components. These are synced into your otherwise normal application/product codebase. All the behavior/logic for these components is implemented in the codebase.

Why might this be interesting?

• Faster iteration than jumping between Chrome developer tools inspector and authoring CSS by hand.
• Enable non-developers to contribute to design and content.
• Scales to highly complex frontends.

How exactly does this work?

• You use Plasmic to build what your components look like.
• You use codegen to sync these componoents into your codebase.
• You use the component APIs to implement behavior and bring your designs to life.

The Plasmic team uses Plasmic in this way to build many parts of Plasmic Studio itself! It’s a demonstration of how you can apply this to some highly complex frontends.

What does adoption look like?

For complex apps or sites, developers can create v1, and invite designers and content editors to make changes.

What we see most commonly is that developers are the first to use Plasmic, as a UI builder that speeds up the development cycle. They can build the frontend from scratch, or use the Figma importer. During this phase, developers wire up the design to code. Here, Plasmic serves as a tool that simplifies much of CSS layout, provides instantaneous feedback without hot reload cycles, reflects visual changes simultaneously across multiple variants, and affords a rich principle system of tokens, style presets and variants.

Afterward, developers can invite designers and content editors to jump in and start making changes. Even if this is the extent of the team’s adoption of Plasmic, this already eliminates back-and-forth on design and content changes. Designers and content editors are empowered to directly make refinements, and developers are freed from being in the loop for large classes of the most common changes.

For complex apps with tight coupling between the design and code, we typically recommend using Codegen over the Headless API, to ensure that the generated code is part of your code’s version history.

Once designers and content editors are comfortable with making simple changes, they can start doing more significant authoring.

As the team gains comfort with Plasmic, rather than relying on developers to build out a high-fidelity v1, developers can build “just enough” of the frontend in Plasmic to be able to wire up the functionality from the code. This could include little to no design styling or content, a skeleton to be filled in. Afterward, designers and content editors can craft what is essentially the initial design, exerting direct ownership and control over the final shipping product.

Adopting Plasmic does not require displacing designers’ preferred tools.

While Plasmic can indeed be used for even creating wireframes and mock-ups, it is also non-dogmatic about workflow. It is perfectly acceptable to use Plasmic as a “production-only” tool that complements vector drawing tools—this still yields significant workflow benefits and reduced back-and-forth.

That said, designers using Plasmic for the initial design work can reap a number of benefits including eliminating handoff, ensuring production reflects their exact vision, and straddling fewer tools.

When introducing to developers, documentation is key to building trust.

So far, we’ve discussed scenarios where developers are introducing Plasmic to the organization. But when introducing Plasmic to a development team, getting their buy-in is the first step. Being able to get generated code is just one of many concerns. What is the workflow? How do you make updates? How do you interface with the generated code? What are the limitations and trade-offs? All of this requires education, and so documentation plays a central role in building developer trust.

Besides this documentation site, if you already have a project in Plasmic that you have been building, it auto-generates a developer documentation portal, which you can share with the development team (press the “Code” button in the toolbar from any Studio project). This details the API that each component exposes and features an interactive code playground where developers can explore this API.

How do I get started trying this?

Go through the tutorials in this section of the docs, for Minitwitter and for TodoMVC!

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