Draw

Draw overview

How teams use Kaidera Draw for secure project whiteboards, diagrams, collaboration, and requirements planning.

Public draft for dev reviewLast verified 2026-05-22

Created from Phase 2 docs inventory and the current Draw/Excalidraw product direction.

What Draw is

Draw is the visual workspace for an Kaidera project. It gives teams a place to sketch workflows, product ideas, system maps, customer journeys, UI concepts, and review notes without separating the diagram from the project.

Why it exists

Many projects are easier to explain visually than in text. Draw lets a customer show the shape of the idea, then connect that visual artifact to requirements, FileVault, Workbench, and worker tasks.

Self-hosted project whiteboards

The current Draw direction is a secure, self-hosted, integrated whiteboard experience based on Excalidraw. The customer-facing value is that diagrams become part of the project instead of living in a separate disconnected tool.

Where files live

Draw files should be saved into FileVault so the whiteboard remains attached to the right project. That makes it easier for users and AI workers to find the visual source when requirements or reviews depend on it.

Common uses

Use Draw when the idea is easier to see than describe.

  • Map a customer journey or internal workflow.
  • Sketch a product screen or dashboard layout.
  • Show how teams, systems, or handoffs connect.
  • Turn a rough idea into reviewable requirements.
  • Explain changes during a project review.

Collaboration

Draw should support team collaboration around the same project artifact. A good Draw session should make it clear which project the board belongs to, what the diagram is for, and what decision or requirement it supports.

Import and export

Users should be able to work with Draw files and useful exports. Imports help preserve existing diagrams. Exports help share diagrams in reviews, documents, or customer-facing materials.

Diagram to requirements

A Draw board can become a source for requirements. The user can describe the diagram, ask the team to interpret the workflow, and use the resulting requirements as the basis for scoped project work.

What to avoid

Do not treat a diagram as final requirements by itself. A diagram should be paired with notes, owner decisions, constraints, and review expectations before the build work starts.

What can go wrong

Draw work becomes hard to use when boards are not saved to the project, names are vague, important decisions are left only as visual hints, or the diagram is updated without updating the requirements.

Read next

Read FileVault to understand where Draw files are stored. Read Create your first project to understand how a diagram can become scoped work.

Website context

Connect this guide back to the product story

The technology docs map links this page to the public technology narrative and helps buyers move from a capability overview into the right operating guide.

Open technology docs map →