Good questions.
Clear answers.

Zaoly is a standalone visual editor for digital products. Design pages and components on a canvas, give them reusable structure with masters, variants, and token bindings, then hand them to developers as code.

The handoff makes structure and design decisions easier to understand. Your team still reviews and integrates the output in the target product.

A project organizes a piece of work in Zaoly. A composition is the design document you edit; it can contain several pages, such as a home page, product page, and contact page. Masters and their instances belong to that composition.

Projects are independent, so you can create as many as you need for different brands, products, or experiments.

Start on an artboard, combine Zaoly Kit elements such as text, image, button, and layout, then edit the structure on the canvas. Turn recurring elements into masters, add variants, and bind colors or spacing to token paths.

Review the result in Preview and Preflight, then create a React module or handoff pack so developers get the component and its technical context.

No. Zaoly runs as a standalone product with its own editor, projects, Zaoly Kit, local token pack, and user accounts. Federation or an external collection is not required for the normal workflow.

To use a result in another application, take the code handoff and integrate it into that application.

The editor brings together a canvas, pages, layers, and an inspector for the selected element. Place building blocks, edit content, nest and reorder layers, and check the result on an artboard. Assets, comments, and component tools are part of the same workspace.

Your design remains an editable, structured document—ready for variants, responsive views, and developer handoff.

Switch between artboard widths and make deliberate layout changes for each breakpoint. For example, you can stack a two-column desktop composition on mobile and adjust its spacing and scale.

Zaoly does not automatically invent a finished mobile design from a desktop layout. The views help you make and communicate those responsive decisions.

Zaoly Kit provides starter elements such as Text, Button, Input, and Layout. A master is your reusable component definition in a composition; an instance places that master on a page.

Instances in that composition receive master changes. This is not a live link to masters in other projects or to code already exported. Use the Kit and React handoff for reuse beyond the composition.

A master can have named variants such as “Default” and “Editorial.” Each instance chooses the variant it needs while remaining part of the same component family.

Variants are designed states you define. Zaoly does not infer them automatically from arbitrary properties or from a third-party design-system library.

In the Kit Playground, select Kit elements, edit TSX, and review the result in a live preview. Props, token references, and handoff details make it useful for developers too.

A draft in the playground is not automatically published as a permanent package component; that requires the dedicated editor and Kit workflow.

The Zaoly pack starts with core design values for the Kit, including colors, typography, spacing, sizes, radii, shadows, and motion. Semantic paths such as color.action.primary let components refer to a role instead of a fixed value.

The pack is managed in Token Studio; you do not need an external brand service to design or use token bindings.

An override changes the value of an existing seed path while keeping its name. A custom token adds a new local path that was not in the seed pack.

The studio marks both clearly. You can reset an override to its seed value without rebuilding the pack structure.

Token Studio offers tools for each value type. Colors support HEX, RGB, HSL, and OKLCH; spacing and dimensions have a scale with live preview and direct input. Motion values can be adjusted by duration and curve.

You can also derive a value from another token path. The studio shows the resolved value while you work; changes are saved only when you choose to save.

Bind a component property to a token path. If two buttons use color.action.primary, changing that local value updates both when the editor loads the latest pack.

Already exported React code and external applications do not update by themselves. The handoff exposes token references so developers can connect them in the target system.

Yes. Token Studio includes readable Cards, JSON, and CSS views. Copy or download the output for reviews, documentation, or handoff into a React project.

Admins can preview new, changed, and invalid entries before applying a JSON import. CSS is an export view, not a way to import CSS back into the pack.

A composition has an owner who can share it with other Zaoly users. Editors can make changes; viewers can inspect the design without editing it. Access applies to the shared composition.

Each collaborator needs a Zaoly account; a public link is not a substitute for editor access.

Team presence shows who is in the workspace. Comments can refer to specific elements, and named versions record important milestones.

These tools support coordination and review; they do not automatically merge every simultaneous edit.

Yes. Open named versions read-only to review earlier milestones, then restore a version when needed. Zaoly creates a backup of the current state before restoring.

Undo and redo help with recent actions in the current session; named versions are better for documented decisions.

No. Roles, presence, comments, and versions help the team understand access and design history, but they do not guarantee that simultaneous changes to the same area merge without conflict.

For critical components, review the variant and token bindings, save a named version, and then hand the work to development.

Export a selected element, a whole page, or all pages. For reusable web components, the React export turns the edited structure into a module developers can inspect and integrate.

The Kit Playground offers a focused handoff for Kit components, including package, import, and module guidance.

Copy Code copies the generated module. Copy pack adds integration context: the Kit dependency, install and import notes, available token CSS values, and the module itself.

It gives developers a concrete starting point; it does not commit or release code to another repository automatically.

Before handoff, the editor checks issues such as missing image descriptions, unlabeled buttons, contrast, touch target size, tab order, and missing token bindings. “Ready for eng” reports blockers for the selected export scope.

A clear status means these automated checks found no blockers. It does not replace a full accessibility test, code review, product test, or approval in the target app.

The React handoff is the starting point. Developers take the module into the target project, set up Kit imports and token values, and connect the component to the app’s data, routing, and quality rules.

A Zaoly master does not become a live-synced master in every project. Design changes need a new handoff and review in the target system.

The editor offers React as well as other views, including Tailwind-oriented HTML, SwiftUI, HTML, and scene JSON. These serve different handoff and review needs; React is the primary path for reusable Kit components in web products.

Other frameworks do not automatically receive the same ready-to-use module. Teams may need to adapt the output to their own component contracts and runtime.

Zaoly currently uses local user accounts. An admin invites you; use the invitation link to set up your account, then sign in. Public self-registration is not available.

The admin currently shares the invitation link directly. This does not imply automatic email delivery or SSO.

Admins can edit and import the local token pack. Signed-in users can use its values in the editor; bound components pick up current values when those values are loaded.

Composition roles (owner, editor, viewer) are separate from the admin role for pack management.

Zaoly saves compositions as structured documents containing pages, layers, masters, and comments. The standard multi-user setup uses its own database; local development and tests also support a file fallback.

This describes product storage, not a promise of specific availability, automatic backups, or syncing with external applications.