VARSITY BY INTERVIEWBIT · PROGRAM-PAGE SYSTEM
From one-off program pagesto a repeatable launch system.Six live pages reached 9.05% V2L.
I led the transformation of Varsity’s program-page process into a governed system that reduced page production and approvals from 3–4 days to 3–4 hours, created a more consistent learner experience, and gave Marketing and SEO greater launch ownership.
Lead Product Designer
Mid June 2026 to present
Design strategy, information architecture, workflow design and automation, and design QA
Design, engineering, marketing, and SEO
Acquisition: Jul 23–31 · Program funnel: through Jul 31, 2026
See all results ↓Business Context
Varsity needed to launch complex partner programs at campaign speed.
Varsity by InterviewBit launches professional certificate programs with institutions such as IIT Delhi and IIM Trichy. Each program page has to explain a complex curriculum, establish the credibility of the institution and instructors, answer questions about admissions and pricing, and convert interested visitors into qualified leads.
The subject matter changed between programs, but the learner journey was largely the same. As the launch pipeline grew, treating every page as a new website project became a business constraint: campaign teams waited for specialist support, testing slowed down, and every launch created new opportunities for inconsistency.
I reframed the assignment from “design another landing page” to “create a governed launch system that protects quality while allowing teams to move independently.”
Explain a complex offer
Turn curriculum, faculty, outcomes, eligibility, pricing, and admissions into one clear learner decision journey.
Protect partner credibility
Keep institutional claims, brand expression, program facts, and conversion journeys accurate across every launch.
Enable campaign iteration
Give Marketing and SEO enough control to launch and improve approved pages without restarting the design process.
The Challenge
Every launch repeated the same work—and blocked the next experiment.
The pages were structurally similar but operationally expensive. Each launch repeated the same information architecture, curriculum patterns, imagery, forms, metadata, and quality checks. The cost was not only production time; it affected how quickly the business could launch, learn, and improve.
Launch speed
3–4 days to build and approve one page, slowing campaign launches and reducing the time available to test propositions.
Experience drift
Section order, curriculum presentation, image style, and copy patterns changed from page to page, making Varsity feel less like one product.
Team dependency
Routine campaign, content, and SEO changes still depended on Design or Engineering, creating queues around specialist teams.
Launch quality was also fragile. Heavy images, missing metadata, incorrect forms, unfinished content, or cross-brand errors could reach production when checks happened late or relied on memory.
My Approach
Four moves turned one approved page into a repeatable launch system.
-
Step 01
Standardize the learner story
Mobbin
-
Step 02
Design the component system
-
Step 03
Encode the production rules
- Step 04Govern launch and transfer ownership
The workflow separates decisions that require human judgment from work that can be repeated safely: define the learner narrative, formalize the responsive component system, encode the production rules, and give growth teams a governed way to launch and maintain pages.
Standardize the learner story
Turn the partner brief and conversion goals into one clear sequence of learner questions.
Design the reusable component system
Design the responsive home page, program details page, enquiry forms, callback modal, admissions flow, payment states, and reusable components.
- Specify desktop and mobile behavior, content hierarchy, component variants, form states, image ratios, and interaction rules in Figma.
- Partner with Engineering to translate the approved screens into reusable Storyblok components—the content sections teams could assemble without rebuilding the page in code.
Encode the production rules
Turn the design and publishing decisions into reusable automation playbooks so the same standards travel with every build.
- Connect the content platform and image tools to assemble approved sections, prepare assets, wire forms, and preserve the correct institution structure.
- Encode content structure, image direction, publishing logic, SEO requirements, and safeguards into reusable “skill files”—structured instructions the team can run again.
- Buildstoryblok-program-page
- Go-livestoryblok-site-audit
- Verifyvarsity-page-audit
skill: storyblok-program-page
source: approved-programme-brief.pdf
target: Storyblok
house-style: approved
assets: generate-and-optimize
metadata: seo-and-schema
approval: required- ✓Reading approved programme brief
- ✓Mapping approved Storyblok components
- ✓Applying house style and image direction
- ✓Preparing metadata, SEO and schema
- ✓Running pre-publish checks
- →Preview ready — waiting for approval
- ✓Approval completed
- ✓Page generated on Storyblok
- ✻Claude sautéed for 30m 25s
Key Decisions
The system worked because thetrade-offs were deliberate.
The goal was not maximum automation or unlimited page flexibility. I made four decisions that balanced learner clarity, team autonomy, and launch safety.
Keep the core page order fixed
A consistent sequence gives learners a predictable decision journey and prevents campaign requests from weakening the narrative. Content changes by program; the logic does not.
Build with Storyblok components
A static template would be too rigid, while custom pages would preserve the Engineering bottleneck. Reusable sections created flexibility within approved boundaries.
Keep human approval gates
Institutional claims, learner promises, pricing, imagery, and partner representation require accountable judgment. Automation prepares the work; people approve what ships.
Separate build, pre-launch, and live QA
Each stage fails differently. A page can be correct in the content platform and still have a broken form or interaction on the live site, so each check has a focused role.
Figma Screens
The responsive screen library behind the publishing system.
Desktop and mobile layouts, lead-capture states, admissions flows, and reusable Storyblok components show how the system moves from design intent to a repeatable production build.
Desktop and mobile homepage flow
Responsive homepage system covering program discovery, faculty, value propositions, editorial content, and global navigation.
Desktop and mobile design - Program Details Page
Reusable desktop and mobile program detail templates for hero, curriculum, faculty, outcomes, proof, pricing, and admissions sections.
Forms and callback states
Enquiry form, request-a-callback modal, OTP, brochure download, and validation states.
Application and admission states
Responsive application states that carry learners from submission and university review through admission.
Fees, offers, and payment states
Responsive states for fee review, offers, payment confirmation, successful enrollment, and rejected applications.
Reusable design system blocks
Cards, nav, tabs, CTA bands, curriculum modules, accordions, and shared Storyblok-ready components.
The System
Three focused playbooks carried the same standardsfrom brief to live page.
The system separated page assembly, release readiness, and live-page verification. Internally these reusable automation playbooks were called “skill files”; each one handled a distinct production risk and could be maintained independently.
Page builder
Turns an approved program brief into a complete first draft using the fixed learner journey, reusable components, house style, forms, and metadata.
Release audit
Checks image weight and accessibility, search metadata, social previews, structured data, partner-brand safeguards, and publishing readiness.
Live-page QA
Tests the rendered experience in a browser, including links, calls to action, enquiry modals, and comprehension for the intended learner audience.
Content Model
Every page follows the same learner decision journey.
Engineering translated the approved Figma experience into reusable Storyblok components—content sections that teams could edit without rebuilding the page in code. Keeping their core order fixed makes every program feel like one Varsity product while allowing the facts, partner content, curriculum, pricing, and media to change.
Entry
Orient the learner and establish the program proposition.
Learning story
Explain the curriculum, outcomes, faculty, tools, and learning experience.
Trust and fit
Help learners judge credibility, eligibility, and cohort fit.
Conversion and close
Resolve pricing questions and create clear paths to enquiry.
View the complete 21-component Storyblok structure
| # | Section blok | Subcopy |
|---|---|---|
| 1 | `navbar` | Top navigation and primary CTA. |
| 2 | `program_hero` | Above-the-fold title, value proposition, and callback CTA. |
| 3 | `overview_band` | Scannable program overview: duration, format, key facts. |
| 4 | `curriculum_section` | The program curriculum, structured into modules and phases. |
| 4b | `projects_section` | Optional. Capstones/projects split out of the curriculum. |
| 5 | `cta_banner` | Mid-page conversion prompt. |
| 6 | `learning_objectives` | What a learner will be able to do on completion. |
| 7 | `faculty_carousel` | Program directors / instructors with photos and bios. |
| 8 | `tools_section` | The tools strip: official tool/vendor logos. |
| 9 | `why_now` | The market/timing rationale for the program. |
| 10 | `how_you_learn` | The learning model: live sessions, projects, mentorship. |
| 11 | `campus_immersion` | The in-person campus days at the partner institution. |
| 12 | `certificate_section` | The certificate and its issuing authority. |
| 13 | `who_should_enrol` | Target learner profiles and prerequisites. |
| 13b | `admissions_section` | Optional partner-program cohort calendar plus admission process. |
| 14 | `pricing_band` | Fee, GST, EMI table, View Plans modal, and partner-account compliance note. |
| 15 | `faq_section` | Frequently asked questions. |
| 16 | `cta_strip` | Closing conversion strip. |
| 17 | `top_strip` | Announcement / offer strip. |
| 18 | `footer` | Global footer. |
| - | `forms` (root-level) | Callback + brochure lead-capture forms: name, email, phone (+91), graduation year, experience. |
Design Language
One consistent visual and verbal style,encoded for every page.
Image style
Warm copper and orange concept art created a recognizable house style. Illustrations stayed object-led and text-free so they could scale across programs and screen sizes.
Copy voice
The first approved reference pages set the voice: direct, credible, learner-focused, and consistent across curriculum, outcomes, proof, pricing, and calls to action.
Asset quality
Illustrations were compressed for fast delivery, while official institution and tool logos stayed in crisp vector formats to protect brand accuracy.
Team Alignment
The handoff was an operating model, not a Figma file.
I aligned Design, Engineering, Marketing, and SEO around a clear division of responsibility. Specialist teams owned the system and its standards; growth teams gained control over approved day-to-day changes.
Set the experience standard
I defined the learner journey, responsive layouts, component behavior, visual direction, content rules, and human approval gates.
Build the reusable foundation
Engineering translated the approved designs into maintainable Storyblok components and shared interaction patterns.
Own campaign relevance
Marketing could adapt approved propositions, copy, and creative for each program without restarting the design process.
Own search readiness
SEO could manage search inputs, metadata, and ongoing content improvements within the governed system.
Results
The system improved speed, consistency, and ownership.
The clearest direct effect was operational: page production moved from days to hours, release checks became repeatable, and Marketing and SEO could operate approved variants with less day-to-day dependency on Design and Engineering.
Production moved from days to hours
The governed Storyblok workflow shortened page production and approval cycles.
Leads recorded across six live pages
2,220Observed visitor-to-lead conversion
9.05%Observed payments across the first two programs
58Additional breakdowns available on a call
The headline results above are public. Page-level traffic, stage-by-stage conversion rates, and program-level breakdowns remain hidden for confidentiality.
Attribution: From Jul 23–31, 2026, six live pages received 24,541 visitors, generated 2,220 leads, and recorded 9.05% visitor-to-lead conversion. The first two programs progressed to 58 payments by Jul 31. The system supported these outcomes through consistency, launch quality, and iteration speed; traffic quality, campaign strategy, program proposition, pricing, and the wider admissions journey also influenced conversion.
Delivery efficiency
Page-production and approval time after Storyblok and all three skill files were in use.
To complete requested page edits and secure final approval.
Acquisition performance
All six live Varsity pages from Jul 23–31, 2026. Jul 31 is a partial reporting day.
Page-level V2L
Program pages sustained strong lead conversion while the Varsity home page supported discovery.
| Page | V2L |
|---|---|
| Quantum Computing · IIT Delhi | ••.••% |
| AI Engineering / FDE · IIT Delhi | ••.••% |
| AI Operations · IIM Trichy | ••.••% |
| Generative AI · IIT Delhi | ••.••% |
| AI Marketing · IIM Trichy | ••.••% |
| Varsity home | ••.••% |
| Overall dashboard V2L | ••.••% |
Program conversion
FDE and Quantum from their early July launches through Jul 31, 2026.
Program breakdown
Each percentage shows conversion from the immediately preceding funnel stage.
| Program | Leads | Application started | Application submitted | Offer | Payment |
|---|---|---|---|---|---|
| Advanced Certificate in AI Forward Deployed Engineering | •••• | ••• (••.••%) | •• (••.••%) | •• (••.••%) | •• (••.••%) |
| Applied Quantum Computing and AI | •••• | ••• (••.••%) | •• (••.••%) | •• (••.••%) | •• (••.••%) |
| Total | •••• | ••• (••.••%) | ••• (••.••%) | ••• (••.••%) | •• (••.••%) |
Operating model change
What changed for the teams building, approving, and optimizing program pages.
What I Learned
The durable outcome was a shared way of working.
Design the operation, not only the interface
The reusable asset was the shared way of deciding, building, approving, publishing, and improving program pages—not only the components.
Automate repetition and preserve judgment
Mechanical work and predictable checks can move faster. Institutional claims, learner promises, brand expression, and final approval still need accountable people.
Treat autonomy as a design outcome
The system succeeded when Marketing and SEO could operate approved pages confidently—not simply when Design finished the interface.
Next Step
In progressMove intake upstream to one approved source.
I am exploring a future intake workflow in which Strategy or Marketing submits the university proposal and SEO inputs through one request. That approved source could prepare the brochure, program page, and initial campaign assets while retaining the same human approval gates.
This workflow is still in progress. The completed program-page system and its measured launch impact remain the primary outcome of this case study.
New programme request
Claude starts the generation workflow
One governed intake becomes the source for every launch asset.
Generate the programme brochure
Structure the university proposal, programme brief, curriculum, and proof into the approved brochure format.
Run storyblok-program-page
Build the Storyblok page with the approved slug, content model, house style, metadata, and pre-publish checks.
Generate a shortlist of creative ads
Use the governed campaign prompt to create reusable ad directions and launch-ready creative variants.
Automation prepares the launch system; teams still approve what ships.
Next Project
