← All worknow showing ( 08 ) / 24
← part of One hub, many communities

The feature we knew better than to ship

The feature we knew better than to ship key visual

publishing content across several communities at once, each with its own rules. we prototyped it twice and shelved it twice, and i think that was right.

Client StackUpDuration 2 months, 2023Role product designerTools figma, figjam, github
( 01 ) Challenge

it turned into a cms inside a cms.

the idea was simple. the more we pulled at it, the more we found: content ownership, synced learner progress, separate publish schedules, state conflicts.

( 02 ) First cut

deceptively simple.

we scoped a light version into the admin portal release: visibility toggles and status previews inside the existing flow. in practice, content behaved unpredictably after publishing, and nobody could tell what learners in each community were seeing. we shipped the portal and parked this for later.

visibility toggles and the unpublish check
( 03 ) Second cut

now we knew what we didn't know.

months later we came back with harder questions.

what happens when content is active in one community and paused in another?( 01 )
is learner progress shared across copies of the same quest?( 02 )
can each community set its own schedule?( 03 )
who owns content once it's shared?( 04 )
↗︎↑ these were product questions before they were design questions.
publishing flows across communities
( 04 ) Why we stopped

the cost of building it badly was higher than the cost of waiting.

doing it properly meant foundational decisions on ownership, syncing and permissions that would be expensive to undo. we wrote up our thinking for the team and went back to strengthening the core. the work gave us a vocabulary for problems we hadn't named, and a list of decisions to make properly if demand grows.

↖︎↑ i don't regret it.
Next track →
One hub, many communities