How to Write a Motion-Graphics Treatment That Explains the Idea

Write the relationship first. Before you name a transition, describe what the viewer should understand after the graphic changes. A motion sequence can reveal a grouping, an order, or a dependency. It can also hide one. If every screen looks different but the idea doesn't get clearer, the treatment is decorating, not explaining.

The method below uses an invented process—a fictional repair desk—to show how four graphic states can carry one relationship. No boards, animation, or viewer observation have been completed here. The point is to write what each change explains, keep enough context for the next state to be readable, and notice when an attractive transition changes the meaning instead of clarifying it.

Write the relationship before drawing the screens

Choose one process from the commercial's agreed information that isn't a number. State its essential relationship in plain language. For the fictional repair desk, the relationship is: booking becomes available only when diagnosis is complete and parts are available. Both conditions must be satisfied. That's a conjunction, not a sequence.

Write that sentence before you sketch. If the brief says "diagnosis and parts," don't turn it into "diagnosis, then parts" because a single arrow looks cleaner. A single arrow can make a conjunction look like a chain. If the underlying process is unsettled—maybe parts are checked first, maybe diagnosis can happen without parts—clarify that before you polish any animation. Motion won't fix an unclear relationship. It will make the unclear relationship look intentional.

Separate what is supplied fact from what is invented for demonstration. In this example, the repair desk process is invented. It is not a real service promise. The method of stating the relationship is the lesson; the repair desk is a prop.

Give each state one new piece of understanding

Describe a beginning, a change, and the resulting relationship. Name the thing the viewer follows across them. In the repair desk example, the viewer follows the request itself: a card labeled "Request #482." The request can acquire two status markers—one for diagnosis, one for parts—without becoming a different request.

Specify the label, shape, or position that preserves identity. Do not make color the sole identifier. The card has a stable label, a stable shape, and a stable position on the left. The status markers are separate chips. Color can reinforce a change, but if color is the only signal, a viewer who misses the color shift loses the thread.

Here is the proposed state sequence. Each state adds one new piece of understanding:

• State 1: Request submitted. Diagnosis: Pending. Parts: Pending.
• State 2: Diagnosis: Complete. Parts: Pending.
• State 3: Diagnosis: Complete. Parts: Complete.
• State 4: Booking available. Both conditions complete.

These are proposed explanatory choices, not measured improvements in comprehension. The goal is to make the relationship readable, not to prove that viewers learn faster.

Keep the context that the next state needs

Choose what stays visible, what moves, and what disappears. If two checks are independent, placing them one after another may wrongly suggest that the second waits for the first. In the repair desk example, diagnosis and parts are independent. One can clear while the other remains unresolved. If you show diagnosis clearing, then wipe to a parts screen, then wipe to booking, the viewer may read a serial dependency: first diagnosis, then parts, then booking. That's not the relationship. The relationship is that both must clear before booking.

Show the dependency explicitly rather than expecting timing alone to carry it. Keep the request card visible. Keep both status chips visible. Let the diagnosis chip change to "Complete" while the parts chip stays "Pending." Then let the parts chip change to "Complete." Now the viewer can compare the two states and see that one condition cleared while the other remained open. The final state can show a "Book repair" button appearing below both cleared chips, connected to each. That makes the conjunction visible.

Preserve an unresolved marker long enough to make the final change interpretable. In this example, the parts chip should stay on screen until the viewer can compare it with the completed diagnosis chip. Don't assign a universal reading duration unless you have evidence for that number. "Long enough to compare" is a design decision; "2.5 seconds" is a claim that needs its own support.

Compare meaningful motion with an attractive wrong turn

Keep the same information and compare two transition descriptions. In version A, the original request remains visible while its conditions change. The diagnosis chip clears. The parts chip stays pending. Then the parts chip clears. The booking button appears below both. The viewer can see that booking depends on both checks because both checks are still on screen when booking becomes available.

In version B, a wipe replaces everything with a celebratory final screen: "Booking available!" The request card is gone. The diagnosis and parts chips are gone. The wipe is not inherently bad. A wipe can be a clean, energetic transition. It is inadequate here if it removes the reason the final state became possible. Version B makes it look like booking simply followed the previous screen. It suggests a serial dependency—one thing after another—or no dependency at all. Version A makes the conjunction available to the viewer.

Ask which relationship each version actually makes available. That question is the test. If the transition only makes the next screen look different, it hasn't earned its place in an explanatory sequence.

Write the treatment passage before the style adjectives

Describe the objects, their change, and what that change means. Then add surface qualities only where they support those decisions. A treatment passage for the repair desk might read:

A request card labeled "Request #482" sits at left. It carries two status chips: "Diagnosis" and "Parts." Diagnosis changes from "Pending" to "Complete." Parts remains "Pending." The request card does not move. When Parts changes to "Complete," a "Book repair" button appears below both chips, with two lines connecting the button to each cleared chip. The viewer is intended to infer that booking becomes available only when both checks are complete. This is a fictional process, not a real service promise. No viewer testing has been done.

Notice what that passage does not do. It doesn't say "smooth" or "playful." It describes the objects, the change, and the intended inference. Surface qualities can come later—if a glow on the "Complete" chip helps the change register, that's a support decision. If a glow is just there because glows look good, it's decoration.

Separate the proposed viewer inference from a factual claim about the product. "The viewer is intended to infer that booking requires both checks" is an inference you are designing for. "The service requires both checks" is a product claim. In this invented example, the process itself is fictional, so the treatment must label it that way. If you were working with a real service, you would need the real process confirmed before you animated it.

When a simplification would conceal an exception, restore the exception or narrow the example. Suppose some repair requests can book without a parts check because the part is already in stock. If the graphic shows every request going through both checks, it hides that branch. You could add a second path, or you could narrow the example to requests that need a part. Both are honest. Quietly dropping the exception is not.

Numerical comparisons require their own evidence and encoding work, not a persuasive motion flourish. If you want to show that one path is faster, or that more requests clear, that's a quantitative claim. It needs its own data and its own visual encoding. Motion alone doesn't make it true. This article is about nonnumeric relationships—grouping, order, dependency—where the graphic's job is to make a structure readable.

The repair desk sequence, annotated

Here is the full four-state plan as a treatment would lay it out. This is a planning sketch. No boards have been drawn, no animation has been produced, and no viewer has been observed.

Each state retains the context the next state needs. The request card never disappears, so the viewer always knows which request is changing. The chips never disappear, so the viewer can compare a cleared condition with an unresolved one. The final state keeps both cleared chips visible while the button appears, so the conjunction is visible at the moment it matters.

Now the decorative alternative. In this version, after state 2, a full-screen wipe replaces the request card with a celebratory screen that says "Booking available!" The request card, the diagnosis chip, and the parts chip are gone. The viewer sees a clean final screen, but the relationship that made booking possible has been wiped away. It looks like booking followed diagnosis directly. That suggests a serial dependency: diagnosis, then booking. Or it suggests no dependency at all. The wipe is attractive; it is also less explanatory.

The problem is not the wipe. The problem is that the wipe removes the evidence for the relationship. If the final screen showed both cleared chips next to the booking button, the wipe could still work as a transition into a summary state. The test is whether the viewer can still read the dependency. If the dependency has been erased, the motion has changed the meaning.

End with the sequence, not the style

End the treatment with the reader's state sequence and a plain account of what each change explains. For the repair desk, that account is: request submitted, diagnosis complete, parts complete, booking available. The first state establishes the request and its two open conditions. The second shows that one condition can clear while the other waits. The third shows the second condition clearing. The fourth shows booking becoming available only after both conditions are complete.

Remove any transition justified only by making the next screen look different. If a transition doesn't help the viewer understand a grouping, an order, or a dependency, it might still be a fine piece of motion—but it isn't doing explanatory work. In a treatment for an information-led commercial, that distinction is the whole job. Write the relationship first. Keep the identity and context visible. Compare the meaningful motion with the attractive wrong turn. Then let the style adjectives in only where they support what the viewer is supposed to understand.

Frequently asked questions

What is the first thing to write in a motion-graphics treatment?

Write the relationship first, in plain language. For the fictional repair desk, the relationship is that booking becomes available only when diagnosis is complete and parts are available, so both conditions must be satisfied. That is a conjunction, not a sequence. Write that sentence before sketching; motion will not fix an unclear relationship, it will make it look intentional.

Why can a single arrow or a full-screen wipe mislead viewers?

A single arrow can make a conjunction look like a chain. If diagnosis clears, then a wipe shows parts, then a wipe shows booking, the viewer may read serial dependency: first diagnosis, then parts, then booking. A wipe to a “Booking available!” screen removes the request card and both chips, so it erases the evidence that booking depended on both checks. The problem is not the wipe itself; it is that the dependency has been wiped away.

How do you keep identity and context readable across states?

Name the thing the viewer follows, such as “Request #482.” Give it a stable label, shape, and position; do not make color the sole identifier. Keep the request card and both status chips visible. Let diagnosis change to Complete while parts stays Pending, then let parts change to Complete. In the final state, show the book-repair button below both cleared chips with lines connecting it to each. Preserve an unresolved marker long enough to compare; “long enough to compare” is a design decision, while “2.5 seconds” is a claim needing support.

When should style adjectives appear, and what about exceptions or numeric claims?

Describe the objects, their change, and what that change means first. Add surface qualities only where they support those decisions; a glow on the “Complete” chip may help the change register, but a glow that is there because glows look good is decoration. Separate the intended viewer inference from a factual product claim. If a simplification conceals an exception, restore the exception or narrow the example. Numerical comparisons need their own data and visual encoding; motion alone does not make a quantitative claim true.

Further reading

• Stage the Relationship Before You Describe the Performances — When the relationship is carried by people rather than screens, this rewrites feelings as intentions with an object and an obstacle, staged before anyone performs.
• What Is a Style Frame? Show the Proposed Commercial, Not Just Its References — Before turning a state into artwork for review, this sets out what a designed still can and cannot let a collaborator judge, and why a second state is worth drawing.