🎓 Lesson 21: Project Workflow — Review, Versioning, Localization & Team Handoff

Building a course is only half the job. The other half is the discipline around it: getting feedback without chaos, never losing a good version, translating for other audiences, and handing a project to someone else so they aren't left guessing. These habits separate a one-off file from a professional production — and unlike any single feature, they'll serve you in every tool you ever use.

📚 What You'll Learn

By the end of this lesson, you will be able to:

Run a clean review cycle — collect stakeholder feedback, triage it, and iterate without endless rounds
Set up a versioning and file-naming scheme that protects binary Captivate projects All-New
Understand localization: exporting text for translation and managing per-language versions, captions, and audio
Prepare a team handoff — project files, assets, shared standards, and the documentation that makes a project pick-up-able
Reuse themes and templates so a team's courses stay consistent Win + Mac

⏱️ Estimated Time: 40 minutes

🎯 Project: Set up a versioning scheme and a review checklist for your project, and export (or plan the export of) its text for a hypothetical translation.

In This Lesson

The Production Loop

A finished course rarely comes out of one straight line of work. It comes out of a loop you go around more than once: you plan, you build, you get it reviewed, you revise, you publish — and then, because courses live for years, you maintain it. Seeing that shape up front is what turns "make a course" into "run a project."

graph LR A["📋 Plan
(objectives & storyboard)"] --> B["🔨 Build
(slides & components)"] B --> C["👀 Review
(stakeholder feedback)"] C --> D["✏️ Revise
(triage & fix)"] D --> E["🚀 Publish
(HTML5 / SCORM / xAPI)"] E --> F["🔧 Maintain
(updates & new versions)"] F --> C style A fill:#bfdbfe,color:#1e293b style B fill:#c7d2fe,color:#1e293b style C fill:#fde68a,color:#1e293b style D fill:#fed7aa,color:#1e293b style E fill:#bbf7d0,color:#1e293b style F fill:#f1f5f9,color:#1e293b

Figure 1 — The production loop. The arrow from Maintain back to Review is the point: a course is a living thing you revisit, not a file you finish once.

Notice the loop doesn't end at Publish. Policies change, screenshots go stale, a new hire spots a typo, a translation is requested. Every one of those sends you back around — which is exactly why the four disciplines in this lesson (review, versioning, localization, handoff) matter. They're what let you go around the loop again calmly instead of rebuilding from a pile of confusingly named files.

⚠️ A note on where features live

The all-new Adobe Captivate is evolving quickly, and the exact menus for exporting text or sharing a project for review shift from release to release. This lesson teaches the discipline — the habits that hold no matter what the buttons are called — and points you to Adobe's current Help for the exact clicks in your version. Learn the workflow and you'll adapt to any menu.

Review Cycles That Don't Spiral

The most common way a course project goes off the rails isn't a technical bug — it's a review that never ends. Vague feedback, contradictory notes from three people, changes requested after you thought you were done. A little structure prevents almost all of it.

Share for feedback

The goal of a review is to put the course in front of stakeholders — the subject-matter expert, the manager, the compliance officer — in a way they can actually experience, then collect their comments in one place. Captivate can publish a preview or a shareable output for exactly this; hosted review-and-collaboration services may exist too, and if a hosted service meters or bills separately, treat it as Add-on / Metered and check the current terms before you rely on it. The reliable fallback that always works: publish an HTML5 preview (Lesson 15), share the link, and collect feedback in a shared doc or spreadsheet.

✅ Make feedback actionable

Ask reviewers for feedback tied to a location and a reason, not a vibe. "Slide 4, the objective says 'identify' but the quiz asks them to 'explain' — mismatch" is fixable. "The middle feels off" is not. Give reviewers the slide numbers and a simple form: where, what's wrong, what you'd expect instead. You'll cut your revision rounds in half.

Triage, don't obey

Not every note becomes a change. Your job is to triage: group the feedback, resolve contradictions (two reviewers want opposite things — someone has to decide), separate "must fix" from "nice to have," and push back respectfully when a request would break an objective or accessibility. Then batch the fixes into a single revision pass rather than changing things one frantic email at a time.

💡 Lock the scope of each round. Agree up front how many review rounds a project gets (two is common: one substantive, one final polish). Open-ended reviewing is how a one-week project becomes a two-month one. Saying "this is the final review before publish" is not rude — it's professional.

Versioning & File Naming

Here's a fact that changes how you must work: a Captivate project file is binary. Unlike a plain-text code file, you can't cleanly "diff" two versions or merge two people's edits automatically. If two people edit the same .cpt and you try to combine them, you can't — one overwrites the other. That single fact drives the whole versioning discipline.

🚫 The nightmare this prevents

You've seen it: a folder full of course_final.cpt, course_final_v2.cpt, course_final_REAL.cpt, course_final_use-this-one.cpt. Nobody knows which is current, someone edits the wrong one, and a day of work vanishes. A naming scheme and dated backups make that impossible. This is five minutes of habit that saves you a very bad afternoon.

A naming scheme that works

You don't need special software — you need a convention everyone follows. A dependable pattern:

Piece	Example	Why
Project name	`fire-safety`	Short, no spaces, consistent across every file
Version number	`v03`	Zero-padded so files sort correctly (v01, v02… v10)
Date (ISO)	`2026-09-15`	Year-month-day sorts chronologically by name
Status (optional)	`review` / `final`	Marks where a file sits in the loop

Put together, a file becomes fire-safety_v03_2026-09-15_review.cpt — self-documenting, sortable, and impossible to confuse with another version. Bump the version number every time you reach a meaningful milestone, and keep the old file rather than overwriting it.

💾 Back up the project, not just the publish

Publishing produces HTML5/SCORM output — but that output is not your editable source. If you lose the .cpt (or .cptx in Classic), you can't easily edit the course again. Keep dated copies of the source project in a backed-up location (a synced cloud folder counts, as long as you're saving distinct dated versions and not just overwriting one file). And keep your assets — images, audio, video — organized alongside the project so a restore is complete.

Localization & Translation

Sooner or later a course you build for one audience will be wanted in another language. Doing that well is localization — and the professional move is to plan for it rather than rebuild the whole course five times.

The core idea is to separate the words from the design. Captivate can export the on-screen text of a project into a file a translator can work in, then reimport the translated text back into a copy of the project — so the layout, images, and interactions are built once and only the words change per language. (Adobe's exact export format and menu path change between releases; check current Help for your version. Captivate Classic Classic has long-standing text export/import for this, and the all-new tool All-New continues to grow its localization support — verify what your version offers.)

🌍 What localization touches beyond text

On-screen text — exported, translated, reimported. Remember some languages run longer than English, so leave room in your layout (responsive design from Lesson 7 helps here).
Audio narration — re-recorded or re-generated per language; keep a clean script so a voice artist or text-to-speech has an exact source.
Closed captions — translated per language, tied to the audio (accessibility from Lesson 14 doesn't get a pass in translation).
Images with embedded words — a screenshot or graphic with baked-in text needs a localized version too; that's why authors avoid text-in-images when they can.
Cultural fit — examples, names, dates, and units that make sense locally, not just literally translated words.

💡 Design for translation from day one. The single biggest favor you can do a future translator is to keep text out of images and leave breathing room in your layouts. A course designed with localization in mind translates in days; one that wasn't can take weeks of rework. You don't have to translate now — you just have to not make it hard later.

Team Handoff & Shared Standards

The final discipline is the one that makes a project survive you: could a colleague open your work next month and pick it up without a single phone call? If the honest answer is "no," the project is fragile. A good handoff fixes that, and it's mostly about packaging and documentation, not clever features.

What a complete handoff package contains

The source project file(s) — the current, correctly named .cpt (or .cptx), not just the published output.
All assets — original images, audio, video, and fonts, organized in clearly named folders so nothing is missing on another machine.
The plan — the storyboard and objectives (from Lesson 4) so the next person knows the intent, not just the current state.
Publish settings & targets — how it's meant to be published (HTML5, SCORM version) and where it's hosted or which LMS it lives on.
A short read-me — a plain document noting anything non-obvious: naming scheme, theme used, known issues, who to ask about the content.

✅ Shared standards keep a team's courses consistent

When more than one author builds courses, agree on standards once and reuse them: a shared theme (Lesson 6) so brand colors and fonts match across every course, reusable templates / quick-start projects (Lesson 10) so new courses start consistent, a common naming convention, and an agreed accessibility baseline (Lesson 14). This is why themes and templates exist — they're how a team's work looks like it came from one place, even when five people built it. Captivate runs on both Windows and Mac Win + Mac, so a mixed-OS team can share the same project files and standards without anyone being left out.

Do this well and you've built something better than a course: a repeatable practice. The next project starts faster, the team argues less, and work doesn't grind to a halt when one person is out. That's what "working like a pro" actually means — not fancier features, but a process other people can trust.

🎯 Try It: Set Up Your Workflow

🏋️ Activity: Give your project a professional backbone (~20 minutes)

Objective: Turn the four disciplines into concrete artifacts you'll actually use on your capstone project. No new Captivate features required — this is process work you can do on any project, on Windows or Mac.

Steps

Write your file-naming scheme and rename your current project file to match — e.g. my-topic_v01_2026-09-15_draft.cpt. Decide where dated backups will live. (⏱️ 4 min)
Draft a short review checklist you'll send reviewers: ask for slide number, what's wrong, and what they'd expect instead — plus your rule for how many rounds the project gets. (⏱️ 5 min)
Do a localization dry run: export your project's text for translation (or, if you're not building yet, list every place words appear — slides, captions, narration script, any text baked into images). Note anything that would be hard to translate. (⏱️ 6 min)
Write a five-line handoff read-me: where the source file and assets live, the theme used, the publish target, and one known issue or "to-do." (⏱️ 5 min)

💡 Hint

If you're not on the trial yet or haven't started building, do every step on paper against a hypothetical version of your capstone. The whole point is the habit, not the file. The localization step is especially eye-opening on paper — you'll spot text hiding in places you'd forgotten, like button labels and image captions.

✅ Activity Complete When…

Your project file follows a clear, sortable naming scheme and has a backup home
You have a review checklist that asks for location-specific, actionable feedback
You've identified everywhere text lives in your project (the localization list)
You have a short read-me a colleague could actually pick the project up from

🎯 Quick Quiz

Question 1: Why is a strict versioning-and-naming habit especially important for Captivate projects?

Question 2: What's the professional approach to localizing a course into another language?

📓 Learning Journal

Start your Learning Journal today — a note in your favorite app, a doc, or a paper notebook. It's where you turn "I read that" into "I can do that." After each lesson, jot down:

Key concepts you learned
Things that clicked for you
Questions or confusion points to revisit
Ideas you want to try
Your progress and how you feel about learning this

✍️ This lesson's prompt: Which of the four disciplines — review, versioning, localization, handoff — would have saved you the most pain on a past project (school, work, anything)? Write down the one habit from this lesson you're most likely to actually adopt, and why.

📝 Lesson Summary

🎓 Key Takeaways

A course lives in a loop — plan, build, review, revise, publish, maintain — and the loop doesn't end at publish. Good workflow lets you go around it calmly.
Run review cycles that ask for location-specific, actionable feedback; triage rather than obey, and lock the number of rounds so reviews don't spiral.
Captivate projects are binary — use a dated, zero-padded, self-documenting naming scheme and back up the source project, not just the published output.
Localize by separating words from design (export/translate/reimport text; redo audio and captions per language), and hand off with source files, assets, the plan, publish settings, and a read-me. Shared themes and templates keep a team consistent.

🎉 What You've Accomplished

You've stepped up from "person who can build a course" to "person who can run a course project." Reviews that converge, versions you never lose, translations that don't mean rebuilding, and handoffs a colleague can actually use — that's the professional layer that most self-taught authors never quite nail. You've got the map now, and it works in every authoring tool you'll ever touch.

❓ Common Questions at This Stage

Do I need special version-control software like Git for Captivate?

No. Git shines for plain-text code, but Captivate projects are binary, so Git can't merge or diff them usefully. A disciplined naming scheme plus dated backups in a synced, backed-up folder is the practical answer most teams use. The habit matters far more than the tool.

Where exactly is the "export text for translation" button in my version?

It moves between releases, and the all-new tool and Classic handle it differently, so we won't send you to a menu path that may have changed. Check Adobe's current Captivate Help for your installed version. The principle — separate words from design, export, translate, reimport — is what stays true.

I'm a team of one. Is any of this worth it for me?

Yes — versioning and a handoff read-me are for future you, who will absolutely forget why a slide was built a certain way six months from now. And "a team of one" has a habit of becoming two; setting standards early means you're ready when it does.

🔭 Looking Ahead

That's the end of the workflow foundations. In Lesson 22, the capstone begins: you'll take your own topic and turn it into a real plan — audience, measurable objectives, and a full storyboard — ready to build for keeps.

✅ Before the Next Lesson

Write this lesson's journal prompt — the one workflow habit you'll adopt
Rename your project file to your new scheme and set up its backup home
Have a topic ready for the capstone — the plan you make in Lesson 22 is the one you'll build

📚 Additional Resources

Course Glossary — every term in plain language
Quick-Reference Cheat Sheet — including the project-workflow loop
Captivate Help & Support — the official docs for current export, review, and publish steps

🌟 Encouragement for the Journey

You now have both halves of the craft: how to build a course, and how to run the project around it. That's the complete professional picture — and it means you're ready to do the real thing. The capstone is where it all comes together. Let's build something you'll be proud to publish.