Onboarding content editors to run experiments from Storyblok, what do they need to learn?
We are rolling the Optimize app out to a six-person editorial team and I am writing the internal guide. Before I document the wrong mental model, what does the editor-facing workflow actually look like day to day?
Specifically I want to draw the line clearly: which parts do editors own once things are set up, and which parts still belong to the developers. Our team is comfortable in Storyblok but has never run experiments before
1 answer
The line is clean, which should make your guide short.
Developer side, one-time work: linking Storyblok blocks to Croct slots. Once a block is connected to its slot, developers are out of the day-to-day loop for that block.
Editor side, everything after that. Editors build experiences and A/B tests from inside Storyblok's interface, without touching code. The flow they will repeat is three steps:
- Define the audience (who should see it).
- Specify the content for the slot (what they see).
- Preview and publish, with scheduling if the change should go live later.
For your review process, preview links are worth a section of their own: they are shareable and valid for 24 hours, so an editor can send a link to stakeholders for sign-off before launching. That tends to be the part editorial teams adopt fastest.
A practical structure for the guide: one page on the three-step flow, one page on previews and scheduling, and a short list of which blocks are already linked to slots so editors know where they can experiment today.