Automating repetitive formatting tasks with AI

In my role as a DTP Specialist I work with a high, constant volume of banking notes: financial and technical documents with very repetitive structures, like data tables, footnotes, paragraph and character styles, numbering, cross-references. At that volume, a pattern shows up fast: a significant chunk of production time wasn't going into design decisions, it was going into mechanical tasks that repeated document after document.

Applying the same style set, fixing the same type of formatting error, reordering the same elements after translation.

I identified the pattern and set out to design automations (macros) for InDesign that would absorb the mechanical part of the workflow, using Claude as a development assistant.

The goal wasn't to automate as much as possible, but to free up production time to reinvest in real quality review.

Mapping the current flow. Before automating anything, I documented the production flow as it stood: which steps repeated across all documents, which varied by client or language, and which required judgment (does this table look right? does this footnote make sense in this context?) versus which were purely mechanical, like applying a paragraph style or adjusting a line break.

Classifying mechanical vs. judgment-based. I split tasks into two categories. On one side, mechanical and automatable: applying styles, cleaning up formatting inherited from translation, numbering and cross-references, structural table adjustments. On the other, tasks that couldn't be automated: any decision depending on linguistic or visual context, like tone consistency, information hierarchy, or cultural adaptation of the layout.

Designing the macros with Claude. For each mechanical task identified, I worked with Claude to design InDesign scripts that would reproduce the manual process consistently. My role was that of the domain specialist: defining exactly what should happen in each case, including exceptions, for example what to do if a style was already applied or if a table had an atypical structure.

Validating against real documents. Each macro was tested against real production documents before being integrated into the workflow, comparing the automated result against what would have been produced manually, and adjusting until the output was equal to or better, more consistent than the manual version.

Documenting so the team could adopt it. An automation only I can use has limited value. I documented each macro (what it does, when to use it, what it doesn't cover) so it could be adopted across the team, not just in my own individual workflow.

• Automate only what's mechanical, never judgment. The line was drawn by the type of task, not by how technically difficult it was to automate. Something mechanical but technically complex got automated; something simple but requiring judgment didn't.
• Prioritize by frequency and time saved, not technical interest. It was tempting to automate the most interesting thing to build first. Instead I prioritized by which tasks showed up in the most documents and consumed the most accumulated time.
• Design for team adoption, not just my own use. Every macro was documented and tested with the assumption that someone else on the team would use it without my direct supervision.

A set of macro-based automations integrated into the DTP production flow, eliminating the repetitive formatting tasks identified in the initial mapping, with usage documentation for the team.

The time recovered from mechanical tasks was redirected to real quality control: linguistic review, visual consistency, inconsistency detection. The work that actually needs a person thinking, not executing the same thing again.

Knowing what NOT to automate is as valuable as knowing how to automate.

That exercise of classifying before building changed how I approach any new workflow. The first question is no longer how do I automate this, but which part of this is actually mechanical.