← Back to all work

Case Study · Great Learning

Program Management System: a self-serve home for every program launch.

A self-serve platform that gave multiple stakeholders a single place to launch, manage, and customize programs. By removing developer dependencies, it cut program launch time from 7 days to under 24 hours and freed teams to focus on higher-impact work.

PMS dashboard and the create-to-publish flow
Role
Lead UX Designer
Team
2 Product Managers · 5 Engineers
My work
Product & platform design · Information architecture · Stakeholder research
Timeline
6 months

Impact

Launch turnaround

7d → <24h

Once content is approved, roughly 7x faster.

Developer dependency

−80–90%

For program creation and edits.

Content changes

Hours → 15–20 min

About 90% faster, rebrands included.

The existing workflow

Launching a new program involved multiple teams working independently across different tools. Each had a clear role, but the process lacked a single source of truth.

01

Academics

Researched market demand and finalized the program topic.

02

University partnerships

Confirmed the partner and commercial terms.

03

Spec document (PSD)

Captured the full program details in one place.

04

Sales

Generated the program code; set pricing, region, point of contact.

05

Marketing

Started campaign assets — brochure, landing page, program page, form.

06

Design

Translated the brochure into on-brand digital experiences.

07

Approval + Dev

Assets went for university approval while developers built pages alongside.

Where things broke down

There was no centralized workflow tying these teams together.

Requirements were collected and shared through Excel sheets.

Teams worked asynchronously with limited visibility into each other's progress.

Developers often built assets before approvals were complete, leading to rework.

Programs frequently sat idle for days waiting for every dependency to clear.

The business impact

7+ days

Every new program took at least a week before it was ready to launch — a week of missed marketing, delayed lead generation, and unnecessary developer effort, every single time.

Understanding the problem

Before jumping into solutions, I needed to understand how every team worked together without disrupting a process already critical to the business. Along with the Product Manager, I interviewed stakeholders across Academics, Sales, Marketing, Product, and Developers to map the entire workflow from idea to launch.

What we uncovered

Communication lived everywhere.

No single source of truth — teams relied on Excel sheets, emails, and Slack, making it hard to track progress or resolve blockers quickly.

Scaling exposed the bottlenecks.

One program at a time was manageable. Five at once overwhelmed Product and Design, turning them into the bottleneck for the whole business.

Developers became content managers.

Even small changes — a price, a line of copy, a date — meant a request to Product, then a wait for engineering to prioritize it.

Brand consistency depended on individuals.

There were no guardrails or reusable systems to ensure every landing page and asset followed university brand guidelines.

Every delay pushed revenue further away.

Even after approval, it still took over a week before marketing could start acquiring leads — every day waiting was a day of lost opportunity.

This process was already inefficient for a single program. As the company expanded its university partnerships and launched multiple programs simultaneously, more launches meant more manual work, more dependencies, and a greater risk of delays that directly impacted revenue and partner experience.

Stakeholder mapping diagram — power versus interest, plotting university partner, academics, marketing, product, design, and sales

Description : Stakeholder Mapping

Reframing the brief

At first glance, the ask sounded simple:

"Build a tool to create program pages."

That only solved one part of the problem — we'd end up with a faster page builder while keeping the same bottlenecks and dependencies. After understanding the workflow, I reframed it:

"Empower the marketing team to launch programs end-to-end without relying on Product, Design, or Engineering."

The goal wasn't to build another internal tool. It was to give stakeholders ownership, reduce manual handoffs, and cut the time it took to bring a new program to market.

Success metrics

Under 24 hours

Launch a new program once content is approved, down from a 7-day floor.

One place

Stakeholders get a single place to create and manage everything for a launch.

Consistent & scalable

A repeatable workflow in place of a manual, error-prone process.

Design principles

Every design decision came back to three principles.

Self-serve, reduce dependencies.

Marketing should be able to launch and manage a program without depending on Product, Design, or Engineering. If changing a headline requires a developer, the system isn't doing its job.

Build consistency into the product.

Instead of relying on people to remember brand guidelines, templates, validations, and publishing rules should guide users toward the right outcome every time.

Keep everything in one place.

From creating a program to publishing and managing it, everything should happen on one centralized platform — not across spreadsheets, docs, and tools.

Designing the solution

Templatize everything that repeats.

I audited every landing page, program page, and email created during a launch. Most followed a common structure, so I broke them into reusable components and master templates.

Enable/disable sections Reorder content safely Stay on brand by default
Template system visuals

Validate the editor before designing it.

Before investing in high-fidelity design, I built an AI-assisted prototype in Loveable to test how the editor should work — aligning the team on direction and catching usability gaps early.

Rapid prototype Early usability signal Faster Figma handoff
Loveable editor prototype

Design the workflow, not just the screens.

I mapped the full information architecture: how a program moves from creation to launch, which stakeholder owns each step, what permissions each role needs, and where approvals happen.

Stage ownership Role permissions Approval handoffs
Workflow & access mapping

Final UI & prototype

The final flow and prototype used for internal testing before it went to development.

figma.com/proto/Portfolio_2026
Open ↗

What changed after validation

Walking stakeholders through the prototype helped validate the direction and uncover a few non-negotiable requirements before moving into detailed design.

Secure approval without added friction.

University partners needed to review pages before they went live, but creating an account wasn't an option — so we introduced a secure, no-login shareable preview link.

Make every change traceable.

With multiple stakeholders working on the same program, teams needed full visibility into who changed what, and when. A detailed activity log became part of the platform.

Support draft changes on live pages.

Publishing shouldn't lock a page. Teams could keep editing while the live version stayed unchanged until the next publish.

Learning from real usage

PMS wasn't launched all at once. We rolled it out in phases, starting with new program launches before migrating existing ones. The first 11 program launches validated the core workflow, but also surfaced a few friction points that only appeared in real-world usage.

Problem

Content creation was still manual.

The editor removed developer dependency, but marketers were still writing content in a separate doc before copying it into the platform.

Solution

Using AI to draft the first content.

The Product Specification Document (PSD) became the single source of truth. An AI workflow used it to generate the first draft while automatically applying brand voice, section intent, character limits, and content guidelines.

Brand voice applied Character limits respected Ready-to-edit draft
pms.app/editor — AI Draft
Open ↗
Problem

Image uploads kept breaking pages.

Even with clear instructions, image specs were rarely followed — wrong dimensions and large files caused layout issues after publishing.

Solution

An image editor built into the upload flow.

The platform crops to the required aspect ratio, enforces dimensions, optimizes file size, and previews desktop and mobile before approving.

Auto-crop & resize File-size optimization Desktop/mobile preview
pms.app/upload — Image Editor
Open ↗
Problem

New university brands still required designers.

Every new university came with its own brand guidelines. Creating a new template still depended on Design and Engineering.

Solution

A Claude-powered Theme Builder.

A workflow reads a university's brand guidelines and extracts colors, typography, spacing, and brand variables straight into the Theme Builder.

Colors & typography Spacing & variables Preview before publish

Impact

7d → <24h

Launch turnaround once content is approved, roughly 7x faster

~80–90%

Drop in developer dependency for program creation and edits

15–20 min

Content changes, down from hours or days, about 90% faster

40+

Programs launched and managed in parallel, without added PM or dev bandwidth

"The transition has been a transformative experience for our team's marketing efforts… the Quick Edit feature has been a standout, letting us produce collateral far faster than before."
— Marketing stakeholder

Reflections

Looking back, a few things worked exactly as I had hoped, while others taught me what I'd approach differently next time.

Build guardrails into the product, not the process.

One of the biggest wins wasn't the page builder itself—it was making the right way of working the easiest way. By building validations, approvals, templates, and publishing rules into the platform, teams could work independently without compromising quality or brand consistency.

Define flexibility earlier.

One challenge throughout the project was deciding when to support a new use case and when to encourage teams to use an existing template. If I were to do this again, I'd define those boundaries much earlier — a clear framework for what stays standardized and what earns customization would make those calls faster and more consistent.

Use AI where it adds value, not everywhere.

AI earned its place because it solved repetitive work and produced results people could easily review and improve — generating a first draft, or extracting brand guidelines. The goal was never to replace human decisions, only the manual work slowing teams down.

More where this came from.