Handling Content Types

HBP Spark’s catalog spans multiple content types, each with fundamentally different engagement patterns. A learner watching a video is in a different cognitive mode than one working through an interactive lesson. A learner listening to a podcast might not be looking at the screen at all. Consistency should be a shared foundation that lets format-specific decisions show through clearly.

Articles

For article pages, I established a clear priority hierarchy early in the design process:

1. The content: The article text, images, and structure are primary. Everything else is secondary.
2. Completion and progress: The “Mark Complete” action and any course-context indicators.
3. Context and metadata: Author byline, format, duration, skills covered.
4. Social actions: Bookmark, share, overflow menu.

This hierarchy determined spatial placement. The article title and content occupy the dominant region of the page. The “Mark Complete” action is positioned where it’s accessible without being distracting. Social actions are available but not competing for attention.

The “Mark Complete” Design

For reporting accuracy, implemented a manual “mark as complete” button. While initially, this feels like a friction point for the overall user flow, we did not feel comfortable equating scroll depth or time on page as an active learning goal.

We chose a user-controlled completion model: learners explicitly mark an article complete when they decide they’re done. This is a deliberate choice that respects learner autonomy.

Format and Duration Indicators

Every content type in HBP Spark shows format and duration prominently. For articles, this means the content type label (Article) and estimated reading time. These appear near the title, not buried in metadata.

Why so prominent? Because time is a decision variable. A learner choosing between two articles in a pathway will often factor in how long each will take. Hiding this information forces them to scroll or click to find it, adding friction to a decision they make constantly.

Language Accessibility

Article pages include a language selector that allows users to switch to available translations of the content. This is a global organization feature — many enterprise clients have workforces across multiple countries and need content accessible in multiple languages.

The language selector uses a globe icon with the current language shown — a pattern familiar from international websites. It’s available at the top of the page so users can switch before they start reading rather than midway through.

Videos and Podcasts

Video is the most attention-demanding content format on the platform. When a learner opens a video from a Harvard Business School professor, they’re committing to a focused viewing experience. The design has to earn and maintain that focus while providing enough context and control to make the experience feel intentional rather than passive.

The Player as the Primary Element

Unlike the article page where text is the content, the video page centers on a player component. The player’s placement, size, and behavior are the most consequential design decisions on the page.

We positioned the video player as the dominant visual element — large, centered, commanding. This is not novel design. It’s correct design. The learner came here to watch something. Make that unmistakably clear.

What surrounds the player matters too. We kept the area immediately around the player clean — no promotional content, no “you might also like” carousels, no distraction. The metadata (title, byline, duration, format label) appears below the player, where the eye naturally moves after deciding to watch.

The “About the Presenter” Section

HBP Spark features content from Harvard Business School faculty and leading business thinkers. For a learner selecting a video on negotiation by a specific HBS professor, who is presenting is often part of the value proposition — not just an afterthought.

We designed an “About the Presenter(s)” accordion below the video player. It’s collapsed by default, available on demand. Why collapsed? Because most learners who arrive at a video already know roughly who the presenter is — they may have selected the video because of the presenter. Showing the full bio unconditionally would add visual weight for every user to serve the minority who want that context.

The accordion pattern is the right call here. Available without imposing.

Social Actions and Transcripts

Bookmark, share, and overflow (ellipsis) actions appear on video pages as they do across all content types. The overflow menu contains actions that are useful but infrequent: reporting issues, accessing transcripts, viewing related courses. These don’t belong in the primary action row but shouldn’t be hidden so deeply that they’re unfindable.

Transcripts serve multiple user needs: accessibility for hearing-impaired learners, searchability, and note-taking. They expand who can access the content and how they can use it. Including them was non-negotiable from an accessibility standpoint; designing them well made them genuinely useful rather than a checkbox.

---

Lessons: The Most Structured Content Type

Lessons are the most structured content type in HBP Spark’s catalog. Where an article is essentially a long-form read and a video is a passive viewing experience, a lesson is an interactive learning module with its own internal structure — usually a combination of content blocks, interactive elements, and a defined completion state.

Designing the lesson detail page meant accommodating that internal structure while maintaining visual and functional consistency with the rest of the content detail pages.

The Lesson Content Zone

The most distinctive element of the lesson detail page is the content display area — a larger, structured canvas where lesson content is actually presented. This might include images, text blocks, interactive assessments, and navigation between lesson sections.

The design challenge: lessons aren’t static. Their internal layout is defined by the content creators at HBP, not by a single template. The detail page has to work as a container that accommodates variable lesson structures without breaking.

Our approach was to define the outer container with consistent chrome — navigation, actions, metadata — while allowing the interior lesson content zone to reflow around whatever the lesson requires. The consistent chrome gives learners orientation; the flexible interior handles content diversity.

Breadcrumbs for Nested Context

Lessons within HBP Spark are often part of larger pathways or courses. The breadcrumb navigation becomes especially important here because a learner might be three levels deep: they’re in a lesson, which is part of a section, which is part of a pathway.

The breadcrumb reads: Link > Link > Link — a condensed navigation trail that keeps the current context clear without consuming significant vertical space. On the lesson detail page, this trail is how learners know where they are in a larger learning sequence and how they return to the containing pathway.

The “Mark Complete” Position

On lessons, “Mark Complete” appears at the top of the page and again at the bottom of the lesson content — a dual placement that might look redundant but serves a real user need. At the top: for learners who are returning to a lesson they’ve already completed and just want to quickly navigate elsewhere. At the bottom: for learners who’ve just finished the lesson content and are ready to mark their progress.

This dual placement came from observing how learners actually navigate lesson content in testing. Some users scroll to the bottom of a page before reading a word — they want to know how long something is before committing. These users benefit from knowing the “Mark Complete” action is accessible from the top without requiring a scroll. Other users engage with the lesson linearly and naturally arrive at the completion action after finishing.

Images and Visual Content

Lessons frequently include images — diagrams, charts, illustrations that support the learning content. The detail page design needed to handle images gracefully: sizing them appropriately, ensuring they don’t break the reading flow, and providing enough visual weight to make image-heavy lessons feel rich rather than cluttered.

We avoided the common mistake of constraining all images to a fixed-width column. Diagrams that span the full content width are often diagrams for a reason — they have relationships and structures that benefit from space. The layout accommodates this.

Format Consistency Across Content Types

One design principle maintained across all detail pages, including lessons: format and duration metadata appear in the same position, with the same visual treatment, regardless of content type. A learner who opens an article, then a video, then a lesson should immediately know where to look for “how long will this take?”

This consistency might seem like a small thing. But learning platforms often break this pattern — different content types developed at different times by different teams end up with different layouts. The result is a learner who has to re-orient on every page. Format consistency reduces cognitive overhead across the whole catalog.

The Lesson as a Different Kind of Commitment

One subtle design implication of the lesson format: lessons require more active engagement than articles or videos. They often have check-your-understanding questions or require the learner to make choices within the content. This means the engagement pattern is different — more interactive, less passive.

The detail page design reflects this through the content zone architecture: it’s designed to host interactivity, not just display static content. Getting this right required close collaboration with the content team to understand what kinds of interactivity lessons might contain, and ensuring the page structure could accommodate them without requiring custom engineering for each lesson.

---

Podcasts: Designing for Listening

Podcasts present a unique design challenge in a learning platform: audio content is fundamentally non-visual. A learner engaging with a podcast might not be looking at the screen at all. They might be commuting, walking, or sitting with their phone in their pocket.

Designing the podcast detail page required thinking about the full spectrum of listening contexts and ensuring the design served all of them.

The Player Controls as Primary Interface

For podcast content, the player controls aren’t a secondary element — they’re the core of the page. The play button, scrubber, and volume controls need to be immediately accessible, large enough to tap easily on mobile, and unambiguous in their function.

We positioned the primary “Play” action prominently above the fold — a large, clearly labeled control that a learner can tap immediately without having to hunt for it. The pattern echoes native podcast apps because that’s what users expect and what they can operate without looking.

The secondary playback controls — speed, skip forward/backward, volume — live in a slightly less prominent position but remain accessible from the main view. These are the controls that power listeners use; casual listeners may never touch them.

The Transcript as a Content Parallel

One of the most valuable elements on a podcast detail page is the transcript. This is true for three distinct user groups:

• Accessibility users who can’t or don’t want to listen to audio content.
• Search users who want to find a specific segment without scrubbing through the audio.
• Note-taking users who want to reference specific quotes or passages from the episode.

We designed the transcript as a collapsible section — present but not dominating the page. When expanded, it presents the full episode text in a readable format. Ideally (and in future versions), the transcript would scroll in sync with playback, highlighting the currently playing section. For V1, the static transcript was the right tradeoff.

Duration and Format Metadata

Like all content types, podcasts display their duration and format prominently. For podcasts, duration is especially salient — it’s a major decision factor. A learner choosing between a 13-minute podcast and a 45-minute one is making a different time commitment. Making this visible upfront respects that decision.

The format label is also meaningful: learners who strongly prefer audio content can use the format badge as a quick scan when browsing the catalog. This is one reason format labels need to be consistent and prominent across all content types — they enable filtering by preference even when a formal filter isn’t being applied.

Completion for Continuous Audio

Like video, podcast completion is user-controlled rather than auto-detected based on playback position. This serves the same reasoning: a learner might skip to a specific segment, listen while multitasking, or pause and return over multiple sessions. None of these engagement patterns should be penalized with incomplete status.

We also considered the case where a podcast transcript makes the audio content accessible without listening. If a learner reads the full transcript, they’ve engaged with the content. Requiring them to play the audio to mark complete would be unnecessarily restrictive.

Social Actions in an Audio Context

Bookmark, share, and overflow appear on podcast pages as on all content types. There’s a particular reason bookmark matters for podcasts: audio content is inherently harder to return to a specific moment in. Bookmarking a podcast saves the episode itself, not a timestamp (in V1), which is useful for building a listening queue but not for returning to a specific moment.

The distinction between “bookmarking a piece of content” and “saving a specific moment within content” is worth tracking for future development. For a listening-focused platform, saved timestamps are a meaningful feature. For V1 of a multi-format content platform, episode-level bookmarks were the right scope.

What Podcast Design Taught Me

Designing for audio-first content taught me to question assumptions about visual primacy. Most of my design experience up to this project had been building screens for visual consumption. Podcasts introduced a use case where the screen is secondary — the experience is primarily auditory, and the screen serves as a control surface rather than a content surface.

That inversion changed how I thought about the relative importance of player controls vs. metadata display, and reinforced the value of transcripts as a genuinely functional, not just accessible, feature.

---

Translations: Making Global Access Feel Local

Harvard Business Publishing has a global audience. The organizations using HBP Spark have workforces across multiple continents, speaking dozens of languages. Designing translation support into the content detail pages wasn’t a nice-to-have — it was a core accessibility and inclusion requirement.

The design challenge: make language switching feel obvious, natural, and non-disruptive, without letting it complicate the page for the majority of users who are consuming content in their default language.

The Language Selector Pattern

We placed the language selector at the top of the content detail page, above the title and body content, using a globe icon paired with the current language label. This position communicates: this is a page-level control, not a section-level one. Changing the language changes the whole page.

The globe icon is nearly universal in digital contexts for “language/region.” Combining it with a text label (“English”) removes any ambiguity. Users who want to switch languages see it immediately; users who don’t need it see a small, non-intrusive label they can ignore.

The selector opens a dropdown listing available languages. We organized these alphabetically rather than by popularity, because “most popular” varies by organization — an all-German company has different preferences than a US-only team.

What Translations Actually Cover

One of the more nuanced decisions in translation design: which elements of a page get translated and which don’t?

For HBP content, translations apply to the substantive learning content: the article text, video subtitles, lesson materials, podcast transcripts. Platform UI elements (navigation labels, action buttons) are handled through a separate localization system.

This distinction matters for design. The translated content looks the same structurally — same title hierarchy, same section layout — but in a different language. The platform chrome stays consistent regardless of content language. This consistency is important for administrators managing a multi-language catalog: they’re always seeing the same interface, even if the content language changes.

Designing with Real Translated Content

The translations design used real content — not placeholder text — to demonstrate how the language switch works in context. This was intentional: it revealed that article lengths, word counts, and typographic patterns vary significantly between languages. A German translation of an English article is typically 20–30% longer. The layout needed to accommodate this gracefully.

Testing with actual translated content instead of “lorem ipsum” surfaced layout issues early: text that wrapped unexpectedly, titles that truncated at awkward points, sections that broke in visually confusing ways. These are bugs that placeholder text never reveals.

The Translation as a Signal of Respect

There’s something deeper about translation design worth naming. When a learner from Mexico City or Osaka opens a learning platform and can access expert content in their language — not a machine-translated afterthought, but properly localized content — they receive a signal that this platform was built for them, not just for English speakers.

That signal has real implications for engagement and trust. Learners who feel included engage more deeply. Content that feels natural in your language is content you’re more likely to finish.

Designing translation access to be as frictionless as possible — one tap, a visible selector, consistent position across all content types — was a small design investment with outsized implications for who feels welcome on the platform.

Available Languages as Metadata

The design also surfaces available languages explicitly in pathway metadata: Arabic, English, French, German, Japanese, Portuguese, Simplified Chinese, Spanish. This wasn’t an accident — surfacing available languages at the pathway level helps admins and learners make decisions before they invest time in a piece of content.

An admin deciding whether to include a pathway in a program for a Spanish-speaking cohort wants to know before assigning it whether Spanish is available. A learner scanning the catalog can use the language metadata as a quick filter for content they can actually consume.

Information that enables decisions should live at the decision point — not buried inside the content itself.

---

What These Five Pages Have in Common

Articles, video, lessons, podcasts, and translations are each different in what they ask of a learner. But looking across all five, a few shared principles held the system together:

Completion is always user-initiated. Across every content type, we resisted auto-detection in favor of a deliberate “Mark Complete” action. This respects the diversity of how people actually consume learning content and treats completion as a meaningful act rather than a passive trigger.

Accessibility isn’t a layer — it’s a feature. Transcripts for video and podcasts, language access for global users, dual completion placement for different navigation styles — in every case, what started as an accessibility consideration turned into a feature that genuinely improved the experience for all users.

Format metadata belongs everywhere, consistently. Duration, format label, and language availability need to be in the same place, treated the same way, on every content type. Learners shouldn’t have to re-learn the page on every content type.

The container holds; the interior adapts. Consistent chrome — navigation, actions, metadata — gives learners orientation. The content zone inside adapts to whatever the format requires. Uniform wrappers, flexible contents.

Designing across format types is an exercise in knowing which decisions to standardize and which to let vary. These five pages were a good test of that judgment.