30% offEnding soon
FSD-035Frontend system design Premium

Design an Editable Org Chart

Design a large editable org chart with stable graph identity, lazy expansion, deterministic layout, validated moves, secure export, and accessible navigation.

Advanced 58 min read

An editable org chart is not a set of draggable employee cards. It is a permission-filtered graph editor where one accepted move can affect reporting paths, layout, approvals, exports, and historical evidence.

A demo can recursively render manager.children and move a card when it is dropped. A production chart must answer harder questions. Is the full organization really a tree? What happens when a branch is only partly loaded? Can a manager move someone whose descendants they cannot see? Which revision does the drag preview describe? How does a keyboard user inspect or edit the same relationships?

The design starts with graph identity and command semantics. Layout and drawing come later.

Clarify the organization model

Assume a company directory with tens of thousands of people, positions, vacancies, contractors, and teams. Users can search, expand branches, pan and zoom, inspect a person, switch between people and position views, and export an authorized slice. Editors can propose or perform reporting-line changes. Some changes take effect immediately; others are scheduled or require approval.

Ask whether a node represents a person, a position, or both. Ask which relationship is primary, which secondary links must appear, whether multiple managers are allowed, how vacancies and acting roles work, and whether the chart is current-only or time-aware. Then ask about maximum depth, fan-out, permission trimming, layout stability, mobile scope, collaboration, audit retention, export formats, and move approval rules.

These answers decide whether the browser is editing a tree, a graph, a projection of a graph, or a proposed future revision.

The public interview prompt

Design a browser-based editable org chart. Explain:

  • stable identities for people, positions, relationships, revisions, and effective dates;
  • tree-shaped primary reporting lines plus secondary graph edges, vacancies, and temporary assignments;
  • lazy branch expansion, search reveal, cache keys, generation guards, hidden-child counts, and permission projections;
  • deterministic layered layout, stable anchors, workers, viewport culling, SVG or Canvas, hit testing, and resize behavior;
  • pointer and keyboard selection, focus, pan and zoom, drag previews, drop targets, cycle checks, and server-validated move commands;
  • optimistic previews, approval workflows, concurrent edits, undo, audit history, presence, and conflict recovery;
  • semantic tree or treegrid navigation, relationship descriptions, reduced motion, high zoom, and text alternatives;
  • secure exports, data minimization, observability, testing, degraded modes, and rollout.

What the premium solution covers

The complete solution separates the authoritative organization graph from the browser's authorized projection and the layout worker's disposable coordinates. It follows one move from local preview through permission and cycle checks to a revisioned server command, including conflict recovery when another editor changes the branch first.

Original teaching media includes a frame-verified move lifecycle, an ownership map, a lazy-expansion receipt, and an export-accessibility contract. A deterministic budget lab lets the reader vary loaded people, expanded branches, layout cost, drag fan-out, permission checks, and export scope without needing an HR backend.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

Is an org chart always a tree?
No. The primary manager relationship is often tree-shaped, but dotted-line managers, temporary assignments, vacancies, shared teams, and cross-functional links make the full model a directed graph. Keep the primary hierarchy separate from secondary relationships.
Should drag and drop immediately change a reporting line?
No. Dragging creates a reversible preview. The server must validate authorization, cycles, effective dates, business rules, and the expected organization revision before committing the move.
How should a large org chart load?
Load a coherent root neighborhood first. Expand branches by stable node ID and cursor, preserve hidden-child counts, and guard responses with the organization revision and request generation.
Should layout coordinates be stored as source data?
Usually not for the canonical hierarchy. Store graph relationships and optional user layout preferences separately. Derived coordinates belong to a versioned layout projection and can be recomputed.
How can an org chart be accessible?
Do not make the visual graph the only interface. Pair it with a semantic tree or treegrid, roving focus, explicit expansion state, relationship descriptions, searchable node navigation, and a text export.
How should exports handle permissions?
The server must rebuild the export from the caller's authorized projection. A browser screenshot or cached full graph can expose hidden names, roles, vacancies, or relationships.