Build a Data-Responsive Commercial Template: Flexible Layout or Restricted Inputs?

A commercial graphic stops being a layout the moment someone other than you types into it. The sample headline ran two lines. The delivered one runs five. The qualification that used to sit under the claim now sits across the product block, and the gap that made it read as a qualification has closed to nothing. Nothing errored. The render is clean, exports, and goes to review looking like a decision somebody made.

The reflex is to enlarge the text box. That doesn't repair the composition, it relocates the failure to whichever string comes next. A reusable commercial needs three separate things built in this order:

• Spatial dependencies stated against rendered bounds — the geometry the design actually needs, not the geometry a placeholder happened to produce.
• A bounded set of accepted input shapes, so the flexible route has a defined end.
• A declared exception route for the inputs that fall outside that set.

One of those is a build, one is an editorial decision, one is production plumbing that teams skip and then rediscover as a bug at the worst possible hour.

What follows is a construction and a test design, not a record of one. The dependency direction in the application is genuinely unresolved by the provider's own text, and the only honest way through is a two-layer check run before the card is built. The numbers below are the arithmetic of the design, not a log from a render. They are what you should know before you touch anything.

Draw the spatial rule before touching the controls

Start with the smallest set of fields that describes the job: a headline, a qualification, a product region, and an optional badge. Now decide, in words, what may wrap, what is fixed, and what moves together. This is a drawing task, and it is the part people skip.

1080 × 1080

  y=136    [ badge strip — 40 tall, reserved even when empty ]
  y=200    HEADLINE          x=120   box w=840   64 / 76
  y=?      └─ rendered bottom + 40
           QUALIFICATION     x=120   box w=840   32 / 40
  y=680    ── floor: qualification bottom may not pass
  y=720    PRODUCT           x=120–960   300 tall, drawn once
  y=1020

Spelled out, the intended dependencies are narrow on purpose:

• Qualification top = headline rendered bottom + 40. Nothing else about the headline matters. Not its size, not its style, not how long it is in characters.
• Qualification left = 120, a frame margin. Not the headline's left edge. If the headline's box grows sideways, the qualification must not be dragged along with it.
• Product region is written down once at y=720 and never computed from anything.
• Badge occupies a reserved strip. Its absence leaves the strip empty rather than closing the stack.

That last one is a decision, not a default. You could collapse the strip so the headline rises when there's no badge. Pick collapse if this is a one-off frame that should feel tight. Hold the strip if the card ships as a set of variants that must cut together, because a headline that lands on a different baseline in variant four will be visible in the edit. Either answer is defensible; an undocumented answer is not, because it will be discovered on a render rather than chosen in advance.

Run the line arithmetic now, before any software is involved. At 76 px leading from a top of 200, a headline's rendered bottom is 200 + 76 × lines. Add the 40 px gap for the qualification top, add 40 for one line of qualification, and measure the result against the 680 floor.

Read the bottom row twice. The five-line headline is the last one that fits, it fits with twenty pixels to spare, and the moment the qualification wraps to a second line the design is out by twenty the other way. Twenty pixels is not a margin. It is a coincidence, and it tells you the automatic route ends somewhere around the point where the composition has already stopped being the composition you approved. A five-line headline at 64 px is 380 pixels of type in a 1080 frame. Whatever is happening at that size, the qualification is no longer the supporting line — it is a caption to a wall of text.

Knowing that before you build is the entire benefit. You now have a stated rule, a numeric boundary, and a named case that will not be handled automatically.

Prove one parent–child dependency in the native application

Do not start with the card. Start with two layers: one text layer and one solid rectangle. The text is the driver. The rectangle is the thing that should follow. No product, no badge, no floor, no margin discipline.

The reason for the reduction is diagnostic rather than pedagogical. If the full card misbehaves, you have five candidate relationships and one symptom. With two layers, a wrong result is a wrong result about exactly one thing.

The procedure is short:

1. Select the layer that will move. In this experiment that is the rectangle, not the text. Selecting the wrong one is the most common first mistake, and the symptom of that mistake looks identical to a broken tool.
2. Declare its parent — the text layer — and set the edge relationship you want: the rectangle's top edge to the parent's bottom edge, offset by a fixed gap.
3. Change the driver's bounds by retyping. Go from one line to three and watch the rectangle. Note which way it moves and whether it moves at all.
4. Then change the driver's position without retyping. Move the text layer up 100 px and watch the rectangle again.

Step 4 is the one people skip, and it separates two tests that look like one. A relationship that fires on content change and a relationship that fires on position change are not the same relationship, and a build can pass the first while failing the second. Do both before you believe anything.

The provider's documentation is not going to settle this for you. The responsive graphics page — specifically the Responsive Design—Position material, checked on 18 September 2026, with the page itself updated on 7 January 2026 — documents selecting a responding layer, naming a parent, and states that graphic layers can respond to changes in another layer through explicit parent-edge relationships. It also, on the same page, contains a rectangle-and-text example whose wording describes the dependency from the opposite end. The two descriptions do not agree. That contradiction is not a footnote you can resolve by reading more carefully; it is a real ambiguity, and it has at least two innocent explanations. The example may concern a simpler or differently labelled behaviour than the parent-edge controls. Or the controls may not do what their surrounding prose implies. Nothing in the page distinguishes those.

So keep the ambiguity and let the application resolve it. After the two-layer run, exactly one of three outcomes will be true, and each has a distinct meaning:

• The rectangle moves, the text stays. The text is the parent and the rectangle is the responder. Build the card on that chain.
• The text moves when the rectangle moves. You have declared the relationship backwards, or you declared two relationships when you needed one.
• Both move. Something else is constraining a layer — a guide, a frame-edge anchor, a second relationship you didn't write down. Find it before continuing; a hidden constraint will resurface as an inexplicable failure three hours into the card.

The temptation at this point is to go find a control recipe and follow it. Resist that specifically. A page can tell you what a control is for; only your build tells you what it does. Reproducing untested steps is how a tutorial acquires instructions that nobody has ever seen work, and this piece is not going to add to that pile. The dependency-direction check is the outstanding item here. Until it runs, treat everything downstream as a proposal with a structure, not a verified method.

Connect actual content bounds to the complete composition

Once the two-layer run has shown which direction your build obeys, bring that verified relationship into the card, and confront the distinction that decides whether any of this works: a larger text box is not the same thing as larger rendered text.

The dependency you want reacts to ink — the geometry the glyphs actually occupy. The dependency you may have built reacts to the layer's box, which is a rectangle you control and which has nothing to do with where the letters stop. These behave identically until you change the box, and then they diverge completely.

The test is cheap. Leave the one-line headline in place and set its box to 400 px tall. Then look at the qualification.

• If it drops to the box floor, your dependency reads the box. Every future box adjustment is now a layout event, and the design's spacing is being driven by a container you sized for convenience.
• If it stays with the ink, the dependency reads the rendered extent, which is what the composition needs.

Neither result is a defect in the application. It is a fact about which quantity you attached, and you cannot fix it by wanting the other one. You fix it by anchoring differently or by keeping the box honest.

With that resolved, run the four content cases against the whole card, and write down what each one produces:

An extra line. One through five lines at 76 px leading. The qualification should track downward by exactly 76 px per added line and stop tracking the moment it would cross the floor. The prediction table above is your expected output. If the qualification moves on line one and stalls on line three, something about the relationship is conditional and you need to know what.

A wider line. Use a headline that renders wider than the 840 px box — a long product name with no comfortable break points, for instance, measuring roughly 1180 px at 64 px type. Watch the qualification's horizontal position. It should not move at all, because it is anchored at 120. If it drifts right, you have attached it to the headline's right edge or its centre, and a wide string will now drag the whole lower composition sideways. This case tests the axis the line count doesn't touch, which is why it has to be run separately.

There is a second failure hiding in the wide case, and it is worth naming so you don't misdiagnose it. If the headline's box grows to fit the longer string, its right edge moves from 960 to roughly 1300 — off a 1080-wide frame. That is not a dependency failure. It is a typography decision that the text should have wrapped, and no dependency rule will catch it. It gets caught by looking.

An absent optional field. Remove the badge. If you chose to reserve the strip, the render should show an empty band above the headline and a stack that has not moved. If you chose to collapse, the headline should rise into the strip's space by exactly 40 px. Both are fine outcomes. What is not fine is an unexplained gap — space that nobody decided to leave and nobody can point to a rule for. A gap with no author becomes a question in every review, and eventually somebody closes it manually.

A missing string entirely. Delete the headline and see what the qualification does. This case is not in the original list and it will happen, because an empty field and a short field are different inputs. A dependency anchored to a bottom edge that no longer exists can behave in ways that surprise you, and you want the surprise now rather than on delivery.

Choose where flexibility stops

You now have two complete alternatives and enough information to compare them honestly, under the same conditions, against the same four inputs.

The flexible composition. One headline field, one qualification field, dependencies doing the placement, a hard floor at 680. The accepted range is one to five headline lines with a one-line qualification, and one to four headline lines with a two-line qualification. Everything outside that range leaves the automatic route. The failure boundary is stated and known: five lines plus a wrapped qualification exceeds the floor, and that combination has to go to the exception composition rather than through the dependency.

The restricted-input version. Three approved headline shapes — one line, two lines, three lines — each drawn at its own size and position, each with a qualification slot authored to suit it. The dependency may still exist, but it is belt-and-braces rather than load-bearing. Anything outside the three shapes goes to a separate composition or back to whoever wrote the copy.

The restricted version is not the timid option, and it is usually the one where the hierarchy survives, because every shape was designed rather than accommodated. It also fails differently. Its failure is late: a copywriter who never saw the three shapes types a fourth into the field, and you find out at render. The flexible version's failure is silent: nothing looks broken, the composition just quietly degrades into something nobody chose. Decide which failure you would rather have, because you are choosing one of them.

Then handle the case that falls outside both. When the qualification would collide with the product region or lose its intended relationship to the claim, it should route to a deliberately authored alternate — the qualification moved below the product, set full width, with the headline's maximum reduced to suit. That alternate is a second composition, drawn and approved like the first. It is not an automatic squeeze. Shrinking type until the collision resolves is the one move that reliably destroys the thing the template exists to protect, because it preserves every element and the relationship between none of them.

Now check the dependency through motion, because a fitting static frame does not verify the animated interval.

If the headline has an entrance — a slide, a scale, a type-on — its rendered bounds change during that move. Ask a specific question: does the qualification ride the headline's bottom edge through every intermediate frame, or does it hold its settled position and animate separately? Neither answer is wrong, but they produce different films. A qualification that tracks a sliding headline can look like the whole block is one object. A qualification that holds still can look like a claim waiting for its support. What you cannot do is assume, and what you cannot do is check only the first and last frames, because the dependency is evaluated at a moment and the animation is a continuum of moments. Look at the middle.

If the headline scales up on entrance, expect the qualification to move by more than you think, because a scale animation moves the rendered bottom edge further than it moves the visible letterforms. That pumping is the sort of thing that passes a spot check and reads badly at speed.

Finally, the boundary of what any of this establishes. A layout that fits proves that the layout fits. It does not establish that the qualification stays on screen long enough to read, particularly if it wrapped to two lines in a slot designed for one. It does not establish that the same dependency survives a German headline of the same meaning, and the length difference between languages is not a layout problem you can solve with a floor. It does not establish that the qualification's content is accurate, substantiated, or approved — and the qualification is often the legally load-bearing line, which means it is exactly the line least suited to being generated automatically. And it does not establish that anything is wired to a live feed. A dependency responds to whatever bounds it is given. Nothing about that machinery knows whether the number in the claim was real.

What the template owes you

A finished template can state three things. The dependency it verified, in one sentence, in the direction the application actually implements. The content range it accepts, with the boundary expressed in the same units you draw in. And the case that leaves the automatic route, named out loud, with somewhere for it to go.

The third is what teams leave out, and it is the one that matters most, because an exception route that isn't written down doesn't not exist — it gets improvised by whoever is closest to the deadline. That person will shrink the type, or nudge the qualification down six pixels, and the hierarchy will die quietly on a frame that nobody reviews twice. A visible exception is part of the template. It is the part that says, in advance, this is where the automation stops and a person decides.

The dependency-direction check remains open until you run the two-layer test, and it is open in a specific way: the provider's page documents the selection and parent controls while a rectangle-and-text example on that page describes the relationship from the other end, and only a two-layer run in the installed application will settle which description your build obeys. Until that runs, the card's numbers above are a design with a stated arithmetic and a known failure boundary — which is more than most commercial templates carry, and less than an executable tutorial. Run the two layers first.

Frequently asked questions

What three things should a reusable data-responsive commercial template specify?

Spatial dependencies stated against rendered bounds, a bounded set of accepted input shapes, and a declared exception route for inputs outside that set. Those are separate tasks: one is a build, one is an editorial decision, and one is production plumbing.

Why is a larger text box not the same as larger rendered text?

A dependency may react to the layer's box rather than the ink the glyphs occupy. Test by leaving a one-line headline and setting its box to 400 px tall. If the qualification drops to the box floor, the dependency reads the box; if it stays with the ink, it reads the rendered extent. The design needs the rendered extent.

What does the two-layer test check, and why not rely on the provider's documentation alone?

It checks which way a parent–child dependency actually works in the installed application. The provider's page documents selecting a responding layer and naming a parent, but a rectangle-and-text example on the same page describes the dependency from the opposite end. The outcomes are: rectangle moves and text stays; text moves when rectangle moves; or both move because of a hidden constraint. Only the two-layer run settles which description your build obeys.

When does the flexible layout leave the automatic route?

In the stated design, it accepts one to five headline lines with a one-line qualification, and one to four headline lines with a two-line qualification. Five headline lines plus a wrapped qualification exceeds the floor. A qualification that would collide with the product region or lose its intended relationship to the claim should route to a deliberately authored alternate, not an automatic squeeze.

Why might a restricted-input template preserve hierarchy better than a flexible one?

A restricted version uses approved headline shapes — one, two, or three lines — each drawn at its own size and position with a qualification slot authored to suit it. Every shape was designed rather than accommodated, and the dependency is belt-and-braces rather than load-bearing. Its failure is late: someone types a fourth shape into the field and it is found at render. The flexible version's failure is silent: the composition degrades without looking broken.

Further reading

• Build a Browser-Based Treatment That Reflows Without Losing Its Reading Order — If a fixed frame with a floor is wrong for your delivery, this is the other route: a treatment that reflows and keeps its reading order intact.
• Make a Motion Study Change Length Without Stretching Its Important Beats — The same fixed-versus-flexible decision on the time axis: mark what must not change, give intervals floors and ceilings, and confirm the route is eligible before relying on it.