Designing the Pathway Editor

The Pathway Editor is the most complex screen in HBP Spark. It’s where admins spend the most deliberate design time — building, organizing, and refining the learning experiences they’ll publish to their organizations. Getting it right meant designing not just individual features, but a coherent system where every decision reinforces the same mental model.

---

The Three-Zone Mental Model

The entire editor is organized into three zones, and every feature lives in one of them:

The canvas is the truth: what you see in the editing canvas is what the pathway contains.

The top bar is the control plane: publish/update, save, status — lifecycle management.

The overflow menu is the secondary toolkit: important but infrequent actions, one deliberate click away.

When deciding where a new feature should live, this framework was the decision tool. Does it affect content? Canvas. Does it affect the pathway’s lifecycle? Top bar. Important but infrequent? Overflow.

The Autosave Contract

Across every editor state — Draft, Updates Pending, locked, mid-edit — autosave always applies. There is no state where the editor might lose work.

Autosave sounds like a small technical detail, but it’s the foundation of trust between the admin and the editor. Without it, admins develop compensatory behaviors (saving constantly, working in smaller sessions, exporting frequently) that are symptoms of anxiety, not the feature working as intended.

The autosave indicator lives in the top bar, always visible. When a change is made it shows “Saving…”; when saved, a confirmation state. Too large and it becomes a source of anxiety; too small and it’s missed. Subtle, persistent, legible on close inspection, not distracting in peripheral vision.

Save and Close as the Universal Exit

Across all editor states, ← Save and Close is the exit mechanism. The label doesn’t change based on which state you’re in. An admin who learns this once doesn’t have to relearn it.

---

The Pathway Header: Identity and Auto-Calculated Metadata

The pathway header carries the pathway’s identity — title, description, skills, item count, duration — and serves two very different users simultaneously.

For the admin: Every field in the header is inline-editable. Clicking the title puts focus directly in the field — no edit mode toggle, no secondary panel. This mirrors how people edit document titles in Notion or Google Docs; that familiarity reduces the learning curve.

Skills selection uses a tagging interface drawn from the HBR Leadership Framework taxonomy. Skills tags drive recommendations; a pathway without them is invisible to the recommendation engine’s skill-matching logic. The “Skills: None Selected” default is a gentle nudge, not a requirement.

For the learner: The header answers “should I do this?” before they commit. Title and description first (what is it?), skills next (why should I care?), time commitment last (can I do this?). That hierarchy mirrors the decision-making sequence a learner actually goes through.

Item count and duration are auto-calculated — they update as content is added or removed. If an admin is targeting a 30-minute pathway and the header shows 4 hours, something is wrong and they know immediately. The duration in the header is a real-time health check, not a manually set field.

Character limits — 200 for the title, more generous for description — are design decisions as much as technical ones. A pathway title over 200 characters is probably trying to do too much.

---

Building a Pathway: Content Types

The editor supports three types of content, each reflecting a different real source admins draw from:

Catalog Items and the Embedded Browser

Adding a catalog item opens a full catalog browser within the editor — not a navigation away from it. The editing session is preserved; autosave is active; context is clear. Navigating away to search and back would break flow and risk losing state.

The browser uses the same filters as the main search page (Format, Duration, Publication Date, Skill, Language) but presents them expanded by default — the assumption is that the admin is in retrieval mode, not browsing mode. The “Skill” filter is especially powerful here: filtering by skill transforms a 25,000-item catalog into a contextually relevant subset.

Both HBP catalog content and org-created content appear in the browser. The “From Your Organization” section lets admins include their own org-created pathways within a larger pathway — supporting nested learning journey design where an “Introduction to Leadership” pathway might include specific HBP-created pathways on individual skills as items.

Links: Bringing the Whole Web In

Link items are first-class citizens in a pathway: title, optional description, optional duration, URL. They appear alongside HBP catalog items and can be marked complete like any other item.

The harder design question links raise: how do you track completion for an external resource? Honestly — you can’t, automatically. Link completion is user-initiated. We made this explicit by surfacing the “Mark Complete” action more prominently on link items than on catalog items where completion can be inferred.

Link items carry an external link icon (↗) in the learner view — a standard convention that sets expectations. Learners shouldn’t be surprised when clicking a link takes them outside the platform.

Posts: The Admin’s Own Voice

Posts are the most distinctive content type — authored directly by the admin. They can contain text, images, and structured content. They’re the pathway creator’s institutional voice: the context-setting introductions and organizational framing that HBP content can’t provide.

No matter how good a content library is, it can’t know that your company is in the middle of a restructuring, or what frameworks your leadership team uses. A post at the top of a pathway section can say: “Before you dig into these resources, here’s why we’re focused on this right now…” That bridging function is what makes a pathway feel designed for your organization rather than licensed from a catalog.

The post editor is intentionally simple — lightweight rich text, not a full CMS. Admins who over-invest in post formatting end up spending more time on visual polish than on content itself.

One interesting behavior: when an HBP pathway is duplicated by a client admin, any HBP “Learning Activities” in that pathway become Posts in the duplicated version — converting HBP-owned content into client-editable content. This is a deliberate design decision that enables customization without breaking the original.

---

Organizing Content: Reordering, Layout, and Optional Items

Drag-to-Reorder

Sequence matters in learning. The ability to rearrange items is fundamental to the editorial capability the platform is selling.

The drag handle (⠿) is visible at all times in the editor — not hidden until hover. Hover-dependent affordances fail on touch devices and for keyboard users, and hiding handles makes reordering feel like a hidden feature rather than a core one.

When a user drags an item, a ghost preview shows exactly where it will land before they release. Without this, users guess; with it, they know. The interaction works both within sections (reordering items in a section) and between sections (moving an item to a different part of the pathway) — reflecting real editorial decisions admins make.

Keyboard reordering is supported: selecting an item and using arrow keys to move it up or down. Every reorder is an autosave event — no separate “save order” step, consistent with how the entire editor works.

Rows vs. Columns: Layout as Instructional Signal

Each section can display its items in row layout (vertical list) or column layout (horizontal grid). This looks like a display preference. It’s actually an instructional design decision.

Row layout is linear and implies sequence: do these things, in this order.

Column layout is parallel and implies parity: these things are equally valid — explore what interests you.

An admin who understands this can use layout as a communication tool. A required onboarding sequence? Rows. A curated collection of supplementary reading where any entry point is valid? Columns.

New sections default to row layout — the safer default that works reasonably well for both sequential and non-sequential content. Column layout requires a deliberate choice. Layout changes preview in real time in the canvas; no need to check the published view to know what it will look like.

Optional Items: Required vs. Total

The “Mark as Optional” action lives in each item’s context menu — reflecting its usage pattern: a deliberate configuration decision during pathway setup, not a frequent editing action.

When marked optional, an item receives an “Optional” label in both the editor and the learner-facing view. We chose “Optional” over “Bonus” (implies it’s not serious), “Supplementary” (jargon), or “Advanced” (doesn’t fit all cases). Optional is direct and neutral: you don’t have to do this, but you can.

The downstream implication: the pathway header shows required item count, not total item count. A pathway with 8 items (5 required, 3 optional) shows “5 required items.” When a learner is deciding whether to start a pathway, the required commitment is the decision-relevant number.

Required items define the completion threshold. Optional items are genuinely optional — not completing them has no effect on pathway completion status.

---

The Editor’s States

Draft State: Working Without an Audience

The Draft badge in the top bar is always visible when editing a draft pathway. It’s gray — a neutral color that reads “work in progress” without urgency or error. Orange would say “this needs attention.” Red would say “something is wrong.” Draft is neither; it’s intentional incompleteness.

In draft state, the pathway is invisible to learners: it doesn’t appear in search results, can’t be assigned, and doesn’t affect reporting. The editor is a safe container where work in progress has no consequences beyond itself.

The Publish button in draft mode initiates the transition to published. We didn’t add a confirmation modal — an admin who clicks Publish knows what they’re doing. What we did add: clear state-change communication after publishing. The badge updates from “Draft” to “Published,” the button changes to show update options, and the learner-facing view becomes active.

Updates Pending: When Live and In-Progress Coexist

The Updates Pending state is where the editor becomes genuinely sophisticated. A published version is live and being consumed by learners — while simultaneously, a modified version exists only in the editor.

The amber Updates Pending badge replaces the gray Draft badge. The “Publish” button label becomes “Update” — a small textual change with significant semantic weight. “Publish” implies taking something new and making it live. “Update” implies replacing an existing thing with an improved version. An admin who has used the platform for months should develop an intuitive sense that these are different actions.

Two new options appear in the overflow menu:

View Published Version opens a read-only preview of the live pathway — never editable. This prevents an admin from accidentally editing the published version instead of the in-progress one, while still giving them a way to see exactly what learners are currently experiencing.

Discard Changes abandons all in-progress edits and returns to the published state. It lives in the overflow menu rather than as a prominent button — exactly enough friction to prevent accidental execution. It’s one of the few places in the platform that warrants a confirmation modal. The action is irreversible and the cost of an accidental click is high.

For learners, Updates Pending is invisible. They see the published version throughout. When the admin clicks Update, learners who haven’t yet opened the pathway see the new version. Learners who are mid-pathway continue with the version they started — no forced refresh, no disruption.

---

The Pathway Details Panel: Secondary Settings

Settings that are important but infrequent live in a secondary panel accessed through the overflow menu, not in the main canvas.

The division is usage frequency, not importance:

• Inline in the canvas: title, description, skills — edited every session
• In the Pathway Details panel: thumbnail image, archival controls, discard/view-published options — edited occasionally

The thumbnail is optional but meaningful. A pathway with a custom thumbnail looks more intentional in the catalog. The recommended size (640×360px, 16:9) matches video thumbnail dimensions — ensuring pathway thumbnails look consistent alongside the media content they organize.

The Archive action lives here rather than in the main canvas toolbar. Placing it in a panel adds one click of deliberation — not buried, but not a single accidental click away either. For pathways in Updates Pending state, Discard Changes and View Published Version also appear here, contextually.

---

What the Editor Doesn’t Do

Equally important to what the editor does is what it doesn’t do:

• Manage learner completion data
• Show which learners have started the pathway
• Provide analytics on content performance
• Control organization-wide settings

These are all important. They just belong in other surfaces. The editor’s focus — exclusively on building and maintaining pathway content — is a design decision. Mixing content creation with consumption analytics would add complexity without serving the core task better.

What I’d Do Differently

The section creation and item addition flows could be more unified. Currently, creating a section and adding items are slightly separate journeys, creating a small mental overhead: “am I in section mode or item mode?”

In a future version, I’d explore a single “compose” mode where sections and items emerge from a single authoring flow — more like a document editor, less like a structured form builder. It’s a direction worth pursuing now that V1 has established what the content model actually needs.