Hybrid programs

Hone | Est. 10 minutes
Hybrid programs overview
Part of our moderately scary looking flow diagram helping us get alignment on the problem space

The team

Sole product designer, working closely with our CEO, Senior Product Manager, and Director of Engineering. I set design strategy, made scope decisions, produced all design explorations, and facilitated alignment across product, engineering, and executive stakeholders.

The timeline

In progress a/o Q2 2026

The 10 second version

Hone customers have been manually stitching together blended learning experiences since we launched Membership programs in 2023 but as our AI product has matured and private programs have grown in strategic importance, the friction of doing this outside the platform can no longer be ignored.

Read on to see how I:

→ Navigate high ambiguity on a project with wide commercial stakes

→ Design across multiple user types and surfaces simultaneously

→ Work through complex open questions before a line of code is written

The problem

Hone offers three distinct ways for users to learn:

  • Programs: structured, cohort-based classes for a specific group of learners
  • Membership classes: open sessions learners self-select into from a public schedule
  • AI sessions: on-demand, AI coach-led learning and practice

For a while, customers who wanted to combine these modalities into one learning journey had to do so manually. The most common workaround was to create separate programs and assign the same group of learners to each. Admins managed the seams of this experience themselves, often with help from their Hone customer account managers, and communicated the full journey to learners outside the platform.

It was functional, but it wasn't cohesive for either the admin or learners. Tracking progress across a journey consisting of multiple, stitched-together programs was a manual effort. And as Hone has grown, this workaround has started to show its limits.

Two customer examples illustrate the problem well.

  • One enterprise customer built a program to develop a cohort of senior leaders. Part of that journey involved our Executive Discussion format, a Membership class where senior leaders from different organizations come together for a facilitated conversation. Because private programs and Membership classes couldn't be combined, they had to create two separate programs for the same group of learners and coordinate the experience themselves.
  • Another customer took a more complex approach. Their learners enroll in a Membership program through their external Learning Management System, complete LinkedIn Learning modules as part of a broader company-wide learning journey, and then meet quarterly for private facilitated discussions hosted on Hone. The Hone piece alone spans two separate programs. The admin is responsible for making sure the pieces connect.

These are no longer edge cases. As Hone has leaned further into AI and private programs have grown in commercial importance, more customers are trying to combine modalities. The friction has reached a point where it's affecting sales conversations and renewal decisions.

The design challenge

Supporting hybrid programs isn't just a matter of letting admins add different session types to the same container. It requires rethinking several things at once, including:

  • How admins build and configure a program that contains fundamentally different types of content
  • How learners understand what's in a program, what order to do it in, and where they stand
  • How to reconcile the relative priority of different content types
  • How admins track progress across session types in an interface they already rely on heavily for other data

The process

Scoping the work

Before getting into design, the team needed to align on what "hybrid programs" actually means to build and, specifically, what the smallest valuable version of it looks like. I'm leading alignment (across teams as broad as Marketing, Learning Experience, and our C-suite) right now.

Some of the questions we're working through:

  • Completion logic: Hone's existing completion model relies on a "core" designation: classes marked core are required, non-core are optional. A learner completes a program when they've attended all core sessions. We also added a custom completion percentage this year (e.g. "complete any 3 of 5 sessions") which is slightly in tension with the core model. When you add AI sessions to the mix, which are short and on-demand rather than scheduled and attended, the question of how to weight completion becomes more complicated. Should a 10-minute AI roleplay count the same as a 90-minute live class? The Core concept is foundational enough to the platform that any changes carry significant product and technical risk so we've chosen to scope it as a separate decision rather than let it block hybrid program progress.
  • Sequencing: Hone's positioning around AI sessions is that they work best as reinforcement after a live class. Attend a session on giving feedback, then practice the skill through an AI roleplay. Without sequencing support, there's no way to guide learners through a reinforcement experience or verify that the intended sequence is being followed. At the same time, formal sequencing adds complexity to both the admin and the learner experience.
  • Admin visibility: Admins already use Hone's learner table to track attendance, completion, and 20+ other program data points. Adding hybrid programs means surfacing per-learner completion status across three different session types in a table that's already doing some heavy lifting. The challenge is keeping the data scannable while still giving admins the depth they need to act on what they're seeing.

Early design explorations

With alignment on scope still in progress, I built early explorations across the three highest-priority surfaces to align the team on direction and surface open questions.

The program builder. Rather than asking admins to select a program type upfront, the new builder infers the type from what the admin adds. This removes a decision point that would require admins to anticipate what they'll need before they've built anything. Admins can designate any session as core or non-core, set a completion threshold, and optionally configure sequencing.

A modal window with three example classes. For each class, a user can choose a prerequisite, whether to designate the class as core, and can order the set of classes manually, as well as set sequencing and completion requirements.
The program builder

Soft ordering where a sequence is suggested but not enforced is a possible future addition. For now, Hone already implicitly supports soft ordering given that sessions are presented to learners in the order they were added to a program. Making that explicit is lower priority than enforced prerequisites, which unlock use cases that currently aren't possible at all.

The admin learner table. The existing table shows per-learner program activity, but wasn't built to handle three distinct session types with different completion states. The exploration here expands on Hone's existing bubble-based visual for each session in a program, with a legend identifying type by shape. Clicking a learner's row opens a popover with per-session details including session name, type, completion status, and lock state with prerequisite context where applicable. This keeps the table itself scannable while preserving the depth admins need without requiring a separate reporting view.

A few example rows of the learner table are shown. Bubbles of different shapes are shown that indicate different content types.
The learner table within a program

The learner view. Learners need to understand what a program contains, what they've done, and what to do next, particularly when some sessions are locked. This exploration shows a program card with a progress bar and an ordered session list. Locked sessions are visible with a clear explanation of what's required to unlock them. The goal is giving learners enough context to act without requiring them to understand the underlying program logic.

A card contains five example classes. Two classes are completed, one is able to be completed now, one requires an enrollment action, and the last one is locked pending completion of another class.
The learner-facing program view

Where things stand

The team is actively working through the open questions, particularly around completion logic and what the right MVP scope looks like. Design is in progress on the more discrete surfaces where direction is clearer.

Ask me about:

  • How completion logic and the core designation might evolve as hybrid programs scale
  • The sequencing model and what enforced prerequisites unlock for customers
  • How this work connects to the Skills Dashboard and AI session reporting surfaces being developed in parallel