The Admin Catalog: Making Content Management Feel Manageable

One of the earliest challenges we faced when building HBR/Spark was figuring out what an admin’s day-to-day relationship with their content catalog actually looked like. Admins at enterprise organizations are not full-time content curators. They’re L&D managers, HR leads, or department heads who have been handed the keys to a learning platform on top of everything else they already do.

What we learned from conversations with admins was that they typically arrive at the Catalog with one of three intentions:

1. They need to find a specific pathway to edit or share it.
2. They want to see what’s published, what’s stuck in draft, what needs updating in their organization
3. They’re about to create something new.

The Anatomy of the Catalog

Balancing the admin needs with our internal Design System, we landed on a table layout, a prominent “Create Pathway” button, and a status filter to narrow down the items created in the organization.

The table felt right for a few reasons. A grid of cards would look nice but would make comparison and scanning harder when admins in larger organizations could be dealing with hundreds (or in edge cases, thousands) of custom pathways. A table surfaces the metadata on load, without making the admin click into each pathway to find out.

In larger organizations, multiple admins share access to a catalog. Without knowing who last touched a pathway, you get into situations where an admin starts editing something their colleague is in the middle of updating. To mitigate this, we came up with two guardrails:

• Locked Pathways: we implemented logic to lock a pathway that is already open by a different user or on a different tab to avoid version history issues.
• Last Modified by column: On first glance, you can see who last opened the pathway, so the user can reach out to said person and either unlock the pathway or ask questions about changes.

Catalog Actions

One of the biggest pain points for Admins is the fact that, in our old platform, custom pathways would be live the moment they were created and there was no way to have pending updates that are done but not live.

To add to the complexity of this problem, when we brought up this pain point to the development team, they argued against the cost and effort to maintain version history for each custom pathway.

We came up with a solution that worked for everyone:

• Updates Pending: Once an admin starts editing a published pathway, the system creates a temporary new version where Admins can edit and save without publishing, while everyone else sees the published version of said pathway. Once the admin is ready to publish, the temporary new version becomes the published version. This solution cuts costs on version history storage for the organization and still gives the flexibility needed for Admins to do their work well.

What We Deliberately Left Out

We spent real time deciding what not to put on this page. We cut a bulk publish action, a content preview pane, and inline editing. Each of those features made sense in isolation but added enough complexity that the page would start to feel like a power tool that required training to use.

An admin who opens their catalog for the first time should be able to orient themselves in under ten seconds. That constraint shaped every decision about what made the cut.