How to build an interactive case study in Flex

Pull a hero, a stat card, and a quote module straight from the Components Library, drop in your customer's actual numbers and words, and you've got a shareable, on-brand story ready before your next call.

1. Match your goal to a structure

Before you touch a component, know what job this case study needs to do. That decision shapes everything downstream, including how much data you show, whether you need a persona intro, and whether you need to customize things further with the SDK.

Want the reasoning behind why interactive formats outperform static ones? We cover that here — this guide picks up from "you're sold, now build it."

Three goals cover most case studies, each with its own backbone:

Prove the impact

Backbone: Hero with the headline claim → intro stat blocks up top (not buried in a sidebar) → narrative "how" section → testimonial for credibility → results grid → closing CTA. You can see that structure at work in this Ceros case study featuring Russell Investments, where the numbers are load-bearing, not decoration.

Arm your sales team.

Backbone: Persona/customer intro (who is this, what did they need) → pain-points grid → proof via embedded video or demo → stat callout paired with a written result → pull-quote → short "next steps" close. This template lets the reader pick how deep they go. Fill it once; every reader gets the version they came for.

Show the transformation.

Backbone: Hero establishes the stakes → before/after toggle lets the viewer flip between states → stacked goal cards reveal results one at a time as they scroll. Built around a switch, not a straight narrative scroll (more on build gotchas in Best practices down below). Like this template:

Pick the goal that matches your story, then jump copy components directly from the library and drop them into your canvas.

Browse components by purpose

You don't need to design a case study from scratch. Ceros's component library already has the pieces. Here's what to reach for, organized by the job each one does.

Open with the scene. Every case study starts with a hero. Set the headline claim or the stakes before anything else.

Source: ceros.com/components/hero-panel-reveal/

Another option:

Source: ceros.com/components/video-banner-manufacturing-showcase/

Land a number. When a stat is the whole point of a section, give it room.

Source: ceros.com/components/animated-stats-card/

Alternate that features a progress bar with animated numbers on the third tab:

Source: ceros.com/components/progress-bar-component/

Back it with a voice. A pull-quote does the credibility work a paragraph of your own copy can't. Use the customer's own words.

Source: ceros.com/components/quote-module/

Option with multiple quotes, or a persona intro:

Source: ceros.com/components/testimonial-wall-component/

Walk through the timeline. When your case study's story is really about progression — phases of a rollout, milestones on the way to a result — a sticky vertical timeline keeps the throughline pinned in place while each stage reveals as the viewer scrolls.

Source: ceros.com/components/vertical-timeline-stick-to-parent/

Play the proof. Nothing sells a story like watching it happen. Embed the video instead of describing it.

Source: ceros.com/components/youtube-player-component/

Organize without overwhelming. Tabs let you fit a persona intro, pain points, and results into one screen instead of a long scroll.

Source: ceros.com/components/tab-panel-component/

Alternate (long-form or step-based):

Source: ceros.com/components/tiles-with-pop-ups/

Grab whichever ones match your goal. You don't need all seven buckets in one case study.

Import components onto your canvas

Every component page has a Copy component button. Click it, open your Flex canvas, and paste. It drops in fully built, and you can then tweak the style and copy from there.

A couple of things worth knowing before you start pasting:

• Paste preserves the source's look, not the destination's. A pasted component keeps its original colors and background rather than adapting to your canvas, so a component built on a dark background stays dark when dropped onto a white canvas. Check the surrounding color and spacing before you move on; you may need to adjust the component (or your canvas) to make it feel native rather than bolted on.

• One component, one job. Be intentional about the components you use to build your story. A case study with a hero, a toggle, a stat card, a quote, an embedded video, tabs, and a reveal grid stops feeling like a story and starts feeling like a component showcase.

• Components update independently. If the library refreshes a component after you've pasted it, your version stays as-is. You won't get surprise changes to something you've already customized.

Make it yours with SDK

This is where a case study stops looking templated. Flex SDK powers anything logic-based: a stat that counts up on scroll, a toggle that swaps content instead of just images, a pricing module that responds to a click.

Name it before you script it. Whatever you're driving — a video, a toggle, a stat counter — select it in Flex and give it a locator in the SDK Locators inspector (e.g. hero-video, results-toggle). That name is what your script (or Flex AI, if you're prompting it) hooks into, and it means you can restyle or move the element later without breaking the logic. Skip this step and there's nothing for the SDK to grab onto.

A few real patterns worth knowing:

Dynamic modules respond to input. With SDK, your results section doesn't have to be static text. You can tie it to something the viewer clicks. For example: build a set of tabs, one per goal or persona (say, "cost savings" vs. "time saved"), and wire an SDK module so that clicking a tab swaps in the matching stats and narrative for that result. The numbers can even animate or count up as they appear, rather than just appearing instantly.

Sliders usually aren't native; they're custom. If you want a draggable slider for a case study (a timeline of results, a before/after drag reveal), that's typically built as a custom embed through Flex AI rather than a stock component. It works, but expect a few rounds of prompting to get the interaction feeling right. One internal build needed several passes before the drag behavior felt smooth.

Watch the nested-embed trap. If your before/after ends up as two separate Flex experiences embedded side by side rather than one component-level toggle, there's a known display bug (that we're working to resolve!); the embedded version can render zoomed in or stuck on the wrong breakpoint. Safer path: build the toggle as a single component with SDK-driven show/hide, not two embedded experiences.

Where the code lives. Settings > Custom HTML > Body HTML. It runs on both the standalone preview and the published experience, so a stat counter or toggle that looks inactive in the editor isn't necessarily broken.

Best practices

Pick your design mode before you build, not after. Flex offers Fully Responsive (content reflows and restacks between breakpoints) and Scale (content stays locked and uniformly zooms). For a case study meant to rank and get shared as a public page, use Fully Responsive mode. It's built for SEO and holds up across the real range of screen sizes your audience will view it on. Scale mode is fine for a one-off embed at a fixed width, but it's the wrong call for anything you want Google to index.

Hidden isn't unloaded. If you build separate desktop/tablet/mobile versions of your stat cards or embedded video and just hide the ones that don't apply, Flex still loads all of them in the background. One real case: four mobile videos looked lightweight, but 12 video players were initializing behind the scenes across breakpoints, pulling 340MB and choking Safari. For a case study leaning on video testimonials or embedded proof, build one responsive version. Don't duplicate across breakpoints and hide.

Check your embed dimensions before you publish. A testimonial or video embed with fixed width/height won't scale down on mobile. It gets clipped at the bottom instead. Use relative sizing or "Fit content" on the container, not just the asset inside it.

Test the mobile breakpoint, not just a resized browser window. A common miss: no mobile variant has been created, so "mobile" just shows a shrunk desktop layout. Confirm a real mobile variant exists and test the experience on an actual device. Desktop performance can hide problems that only show up on a phone.

Bonus: Prompts for building from scratch

Everything so far has been about reusing what's already built by pulling components from the library, dropping them on your canvas, customizing from there. But sometimes the library doesn't have what you need, or your case study calls for something more custom. That's when you prompt Flex AI to build it from nothing.

Pro tip: Prompt Flex AI using Plan mode.

Turning a written case study or transcript into a first draft:

Build a fully responsive case study experience from this [transcript/doc link]. Use the customer's actual quotes and numbers verbatim — don't generate new copy or invent stats. [Describe your goal — prove impact, arm sales, or show transformation — and structure it using that backbone from Section 1.]

Recreating a multi-page story, page by page (This pattern has worked best for Ceros internally for complex, multi-page builds. One page at a time beats trying to get it all in one shot):

I need to build a multipage case study as a fully responsive Flex experience, and I'd like to go page by page. I'll paste in reference screenshots and image files for each section. Use the copy verbatim from what I share, don't generate new. What do you need from me to get started?

Building a stat callout section:

Create a stat callout section that has one large percentage or number, a short label beneath it, and 1-2 sentences of supporting context. Match it to [describe layout/tone].

Building a before/after toggle:

Build a toggle that switches between two states of the same layout — a "before" and "after" — using a single switch component, not two separate embedded experiences. [Describe what changes between states.]

Building a dynamic SDK module (Describe the logic in plain English. Flex AI writes the SDK code for you):

Build a [pricing calculator / interactive quiz / countdown timer] that responds to user input and updates the displayed result. [Describe the input it should respond to, the logic behind the result, and what the result should look like once displayed.]

The pattern across all of these prompts: specific inputs (real copy, real screenshots, exact described behavior you want to achieve) get you a usable result in one or two passes. Vague prompts are where the back-and-forth creeps in.

Learn more about prompting with Flex AI.

There you have it!

Ready to build your interactive case study? Start a free trial of Flex and pull your first component onto the canvas.