Project Whiteboard vs Wiki: When to Use Each in Onplana

There is a particular meeting that happens on most project teams at least once. Someone opens a whiteboard to diagram the proposed system architecture. Someone else starts a project wiki page to capture the design decisions. A third person creates a task: "update the design doc after the meeting." Two weeks later, the whiteboard canvas is stale and nobody has updated it, the document exists but reflects the discussion as it stood before the last three decisions were made, and the task is still open. The information lived in three places and became authoritative in none of them.

This is not a collaboration problem. It is a tool selection problem. The whiteboard was the right artifact for the session: visual, real-time, low-commitment. The document was the wrong artifact for what the team actually needed after the session: a persistent, structured record of what was decided and why. The task was a symptom of the gap between the two.

Onplana ships both a project whiteboard and a project wiki because they serve genuinely different moments in project work. The failure mode is using either one for the wrong moment, or using a general-purpose document tool for both and getting neither right.

TL;DR. Use the project whiteboard when the team is exploring something that has not been decided yet: architecture, process flows, brainstorming, visual planning. Use the project wiki when something has been decided and needs to persist: decisions, process documentation, reference material, meeting notes that people will return to. The whiteboard serves the session; the wiki serves the project over its lifetime. Onplana ships both as project-native features, not separate workspace tools.

What Onplana Whiteboards and Wikis Actually Are

Onplana's whiteboards are powered by Excalidraw, an open-source virtual whiteboard optimized for hand-drawn-style diagrams. Each project can have multiple whiteboard canvases. The whiteboard supports freehand drawing, shapes, arrows, text labels, sticky notes, and image imports. Multiple team members can edit simultaneously; changes appear in real time.

Onplana's wikis are powered by BlockNote, a block-based rich-text editor similar in interaction model to Notion or Confluence's editor. Each project can have a structured wiki tree: pages with sub-pages, organized into a hierarchy that reflects the project's information architecture. Wiki pages support headings, tables, code blocks, file attachments, and cross-links to other wiki pages and to Onplana tasks.

The critical design difference is attachment: both tools are scoped to the project, not to a shared workspace. A whiteboard in Project A is not visible in Project B. A wiki page written for Project A does not appear in Project B's wiki. This means project context is always available without searching a shared knowledge base, and project members have exactly the information relevant to their project without noise from others.

When to Use a Whiteboard: Visual, Exploratory, Ephemeral

The whiteboard is the right tool when the primary output is visual and the outcome is not yet settled.

Architecture and system design sessions. When engineering teams are working out how components connect, the whiteboard canvas is faster than a wiki page. You can sketch, erase, rearrange, and revise without the overhead of editing structured text. The drawing reflects thinking in progress, not conclusions already reached. Most architecture diagrams go through four or five significant revisions in the session before the team lands on something to document.

Kickoff facilitation. In a project kickoff meeting, the whiteboard supports activities that a wiki page cannot: timeline mapping, assumption surfacing with sticky notes, roles-and-responsibilities diagrams that change as the discussion develops. The whiteboard captures the energy of the room. After the meeting, the outputs that need to persist get transferred to the wiki; the whiteboard stays as a record of the exploration that led to those outputs.

Process mapping. When a team is redesigning a workflow, the whiteboard lets everyone contribute to the diagram simultaneously. Swim lanes, decision points, and handoffs can be added and moved in real time. A wiki page would require one person to maintain the text while others describe changes verbally, which is slower and produces fewer iterations.

Retrospective exercises. Start-stop-continue boards, timeline reconstructions, and root-cause fishbone diagrams are all whiteboard-native formats. They are produced in a session, reviewed in the same session, and should not be revised after the fact. The whiteboard is appropriate precisely because the artifact is session-bound.

The common thread in these use cases is temporality. The whiteboard is the right tool when the output is a step in a process, not the final record of that process.

When to Use a Wiki: Structured, Searchable, Persistent

The wiki is the right tool when the primary output is reference material that team members will return to, search for, and update as the project evolves.

Decision log. Every significant project decision should be documented with the decision itself, the options considered, the rationale, and the date. This is the wiki's strongest use case. Unlike a whiteboard, a wiki page can be searched by keyword, linked to tasks, and retrieved by someone who joined the project three months after the decision was made. The discipline around goals, milestones, and decisions that separates well-run projects from chaotic ones depends on this kind of documented record.

Project charter and scope definition. A project charter belongs in the wiki, not in a whiteboard canvas or a shared drive folder. It is a document that new team members, sponsors, and stakeholders will read, refer to, and need to find quickly. The wiki's search capability and version history make it the right home for a document that may be revised and that carries contractual or governance weight.

Process documentation. When a process is settled and team members need to follow it consistently, a wiki page is the right artifact. "How to submit a change request," "how to run the weekly status update," "how to onboard a new vendor" are all wiki pages. They are not whiteboard canvases, because the readers are not exploring; they are looking for instructions.

Meeting notes with long-term relevance. Not all meeting notes need to be in the wiki. Notes from a recurring standup rarely need to be searchable six months later. Notes from a steering committee meeting, a scope change discussion, or a technical review with documented decisions do need to persist. The distinction is whether future team members will ever need to find the record. If yes, wiki. If no, a shared document or a task comment is fine.

The Decision Framework: A Comparison

The table below summarizes the key dimensions where whiteboard and wiki differ.

Dimension	Whiteboard	Wiki
Primary format	Visual canvas: shapes, arrows, freehand, sticky notes	Structured text: headings, tables, code blocks, lists
Best for	Exploration, brainstorming, diagramming in progress	Documentation, reference, decisions, process records
Durability	Session-bound: relevant while the exploration is active	Persistent: relevant for the life of the project
Searchability	Not indexed by text; searched by title only	Full-text search across all wiki pages
Collaboration style	Simultaneous real-time editing, no structure required	Structured editing, one author at a time per page
Change over time	Expected to be left as a snapshot or abandoned	Expected to be maintained and updated as facts change
Audit trail	Snapshot versions saved; not a full edit history	Full revision history with author and timestamp per edit
Appropriate audience	Project team members who were in the session	Any project stakeholder, including future team members

The dimension that determines the correct choice most of the time is durability. If the output needs to be accurate and findable in three months, use the wiki. If the output is a step in the process of reaching something that will be documented later, use the whiteboard.

How Whiteboards and Wikis Work Together in a Project Lifecycle

Whiteboards and wikis are not competing tools; they occupy different phases of the same process. The diagram below shows where each is most active across the project lifecycle.

In the kickoff phase, the whiteboard is active: process diagrams, stakeholder maps, assumption lists. The wiki receives its first content in parallel: the project charter and initial decisions made in the kickoff. As planning progresses, the whiteboard handles design and architecture sessions. The wiki grows to include process documentation, scope definitions, and the decision log.

During execution, whiteboard usage drops to occasional use for retrospectives and ad-hoc design sessions. The wiki becomes the primary information store: status reports, runbooks, technical decisions, meeting notes from steering committees. At project close, the wiki receives the close-out documentation. The whiteboards are retained as a record of how the team worked, but they are not the archive; the wiki is.

Common Misuses to Avoid

Using the whiteboard as a permanent diagram store. Architecture diagrams that are supposed to be current and authoritative should not live only on a whiteboard canvas. They should be documented as a wiki page with an embedded image or a written description. The whiteboard version goes stale as the architecture evolves; the wiki page is updated deliberately and its history is audited.

Using the wiki for brainstorming. Starting a wiki page to capture ideas before decisions have been made produces a document that is half-exploration and half-record. It is not suitable as a reference document because parts of it are obsolete before it is finished. Brainstorm on the whiteboard, then document what was decided in the wiki.

Creating one wiki page for everything. A single project wiki page that accumulates all meeting notes, decisions, and documentation becomes unsearchable and unusable. Structure the wiki from the start: a top-level page for the project overview, sub-pages for key documents (charter, scope, decision log, process guides), and sub-pages under each of those for specific content. The initial investment in wiki structure pays off as the project grows.

Not linking wiki pages to tasks. Onplana supports links from tasks to wiki pages and from wiki pages to tasks. When a task implements a decision documented in the wiki, link the task to the relevant wiki page. When a wiki page documents a process, link to the tasks that implement that process. Cross-linking makes the project's information architecture navigable rather than a collection of isolated artifacts.

Setting Up Your Wiki Structure for a New Project

A good default wiki structure for a new project covers four top-level pages.

Overview. The project charter, objectives, success criteria, and key stakeholders. This is the first page a new team member reads. It should always be current.

Decisions. A chronological log of significant project decisions. Each entry includes the decision, the options considered, the rationale, and the date. This is the most important page in the project wiki; without it, the team relitigates the same decisions repeatedly.

Process guides. How-to documentation for repeating processes specific to this project: how to submit a change request, how to run the weekly status review, how to onboard a new vendor. As processes are refined, this page is updated.

Meeting notes. Notes from steering committee meetings, technical reviews, and any other meeting with documented decisions. Not all meetings warrant wiki notes; the test is whether future team members will need to find the record.

Start with this structure at project initiation rather than building it retroactively. A wiki that is set up at the beginning gets used consistently. A wiki that is created in month three to organize accumulated documents gets treated as a documentation project rather than a living record.

For project teams that are starting from a document that already exists in another system, Onplana's wiki editor supports paste-from-Word and paste-from-Confluence for common block types. The transition from an external document store to the project wiki does not require rebuilding content from scratch.

The full capabilities of Onplana's whiteboard and wiki features, including version history, access controls, and cross-linking options, are documented on the Onplana features page.