Break the handoff into clear steps
Design handoff usually mixes maturity, setup, docs, and trial timing. Splitting those layers makes the sequence easier to follow.
Guide · Design to Unity Handoff
How should design files be handed off to Unity developers?
The safer order is to identify the current path first, then separate maturity, setup, and trial scope before a larger rollout decision.
A design-to-Unity handoff question should be split into path choice, maturity, setup work, and project-specific blockers instead of flattening everything into docs.
Different paths have different readiness
A released path and a Beta path should never be evaluated with the same assumptions.
Clarify the order before execution starts
Once the sequence is clear, move into docs and path-specific pages with fewer detours.
Suggested reading order
1
Name the source and target first
Do not stay at the vague “design handoff” layer. Resolve the source tool and target engine first.
2
Check the path maturity
Use roadmap and path-level pages to confirm whether the current route is released or still Beta.
3
Route setup into docs
Once the path is clear, use prerequisites and getting-started docs for the actual setup work.
4
Validate one real module before expansion
Use a contained UI slice before you expand the handoff workflow to a wider team or project surface.
Best fit for questions like these
- The real question is about workflow sequence, not only one narrow path detail or one setup screen.
- You want one place that connects workflow, docs, and trial timing.
- The team is still organizing how design, development, and product status should connect.
Common misunderstandings to clear first
- Do not stay only in docs. Clarify the path, status, and pilot scope first.
- If the question is already only about one narrow path, move into that path detail next.
- If the blocker has become project-specific, community support should take over.
Capability Status
Confirm the current delivery boundary before planning rollout
Use the roadmap as the source of truth for what is released, what is in Beta, and what is still planned.
A design-to-Unity handoff question should be split into path choice, maturity, setup work, and project-specific blockers instead of flattening everything into docs.
Released
Lanhu → Unity
Beta
Lanhu → Cocos, Figma → Unity, and Figma → Cocos
Planned
Platform expansion beyond Unity plus the planned agent and plugin marketplace
FAQ
Common questions
When should I step back to the broader Unity workflow?
Step back when the question is still about status, setup order, and trial timing together rather than one handoff detail.
When should I review the path-specific details?
As soon as the source-to-engine path is already clear and the next question becomes path-specific.
When does pricing become relevant?
Only after the handoff sequence, chosen path, and first validation scope are already clear enough for a real trial decision.
Next steps
Browse Guide Pages
View related pages in this category and choose the next route that best matches your workflow.
Unity UI delivery workflow
Review status, setup, and next-step decisions in one place.
Review Figma to Unity path
Move here when the handoff question narrows to the Figma Beta path.
Documentation home
Return to docs once the path and sequence are already clear.
Pricing
Use pricing only after the project already knows what kind of trial path it is preparing for.