How to adopt Plasmic
We have seen Plasmic rolled out at companies small and large, so we have seen what helps ensure a smooth adoption. Plasmic is a distinct tool and can radically change the workflow across engineering, marketing, design, and product—here we provide some guidance on how to bring the whole team on board and answer some common questions.
We break down the two main production use cases for Plasmic as “building content” and “building apps.”
You can start with a single landing page, or a promotional section to be inserted into some other (existing) page in your site/app.
Simply build the content in Plasmic, using it as a page builder. Use the Headless API to integrate into your website’s codebase, and you’re done.
From now on, editors can directly publish changes or new content. (This is similar to the use case of a CMS, but with an easier, faster, and more enjoyable experience for building rich page layouts.)
It means that the content you’re creating is “fixed.”
Examples of static content:
- A landing page for a particular customer segment that shows hero images, marketing copy, seasonal product collections, and a call-to-action button.
- A section of your conversion page that reinforces your value proposition and showcases some testimonials.
- A section of your product’s logged-in dashboard that offers a discount for upgrading plans or some recently launched product updates.
Examples of dynamic content:
- A product listings page that lets users interactively browse product categories, apply filters, and search your product catalog.
- An admin dashboard page that shows a collection of metrics and graphs that your admin users can customize.
- A shopping cart management UI that lets users edit number of products, remove products, save for later, etc.
- Your interactive design system components including dropdowns, accordions, and other interactive elements.
While the content you’re creating is mostly static, it can be dropped in anywhere, including interactive parts of your app. Imagine a promotional section that is embedded as part of your dynamic checkout flow or logged-in admin dashboard.
Note that Plasmic has been used to build all of the dynamic content examples above, but this is a more advanced use case. See the below section on building apps.
Most commonly, marketers and designers use Plasmic Studio. Teams usually adopt Plasmic in order to empower non-developers to help themselves to content changes.
Developers set up one-time integration and provide code components as building blocks, but afterward, publishing content changes from Plasmic doesn’t need to involve developers.
Some other typical audience use cases:
- Developers use Plasmic as a UI builder—see section below on building apps.
- Designers and developers use Plasmic as a tool to create rich prototypes and mock-ups where they can add code, use their existing code components, and ensure a smooth transition to production.
An extremely powerful feature is that developers can provide code components as building blocks for their non-developers to use. Code components make it possible to drag-and-drop existing design systems, data, and interactions in Plasmic. See some examples of code components.
This starts to blur the line between static and dynamic content. For instance, as part of your static landing page, you can display a collection of products from your database, or a set of recent blog posts from a (traditional) CMS. You can even start using Plasmic to design all of the dynamic content displays in your app—such as that product listing page we described earlier.
Alternatively, developers can take designs and attach code to them, using the overrides API available on all Plasmic-built components. This is for adding behavior or interactivity to designs, and is much more prominent when building apps. This tends to add a certain degree of coupling between the design and the code. Between these two approaches, code components are preferable, but sometimes it’s necessary to add behavior to existing designs.
You can use code to start creating dynamic content that displays data from data sources. This is typically done using code components.
For many users building websites and using Plasmic to visually manage page content, this is the end of the story.
If all you want out of Plasmic is a way to open up the content editing experience to everyone, then don’t feel like you “need to” graduate to building full apps in Plasmic! Content management is the most common use case for Plasmic today.
Read on if you are working on a “complex”, interactive/stateful application with Plasmic.
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, mixins 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.
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.
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.