Duration

2 months (2023)

Tools

Figma (Design, Figjam), Github, Paper

The challenge

The idea was straightforward: let content creators publish across multiple communities at once, with each community having its own visibility rules and lifecycle. The execution was not straightforward at all. The more we pulled at the thread, the more we found underneath - content ownership, synced learner progress, independent publish schedules, state conflicts. It was essentially a CMS inside a CMS.

Context

The multi-community publishing system was designed to control content visibility and manage distinct publishing lifecycles across StackUp's different communities. We explored it twice, built prototypes both times, and shelved it both times. This is the story of why that was the right call.

The solution

We made the call to cut the feature before it created more problems than it solved. That's not a failure - it's a product decision. Knowing when to stop is a skill too.

In this case study

First cut: deceptively simple

Second cut: now we knew what we didn't know

Why we put it down

First cut: deceptively simple

Our first attempt was scoped into the admin portal release. A lightweight publishing interface - visibility toggles, status previews, built right into the existing admin flow. It looked manageable on paper.

Early prototype: publishing options built into the admin flow, with visibility toggles and status previews. View working proto here.

In practice, content behaviour was unpredictable post-publish. Updates weren't reflected consistently across communities. There was no reliable way for anyone to know what learners in different communities were actually seeing at any given time. We shipped the admin portal and quietly left this dormant.