Automation
Content Audit Automation Tool
99.5%
Reduction in audit time
218x
Faster than manual review
< 3 months
Concept to delivered audit
A 2,000-URL content audit. The plan was to do it by hand.
, Content migration project, national tourism authority
Client
National Tourism Authority (Ireland)
Role
UX Design Lead + Automation Architect
Timeline
May 2025, Aug 2025
Tools
Figma, FigJam, n8n, Airtable
A website migration. And 2,000 pages to sort through.
A national tourism authority was rebuilding their website from the ground up. Before anything new could be designed, someone needed to decide what happened to the existing 2,000 pages, what migrated, what got rewritten, and what got cut. I joined as UX Design Lead, responsible for the information architecture and wireframes for the new site. Then the content team mentioned their plan for the audit. Two hours per page. Manually. One reviewer at a time.
THE PROBLEM WITH MANUAL AUDITS
"Different reviewers make different calls on the same content. Criteria drift. Quality degrades as fatigue sets in. And at 2,000 URLs, the maths is brutal."
1,700 pages × 2 hrs manual review time, the problem CAAT was built to solve
The tools were fragmented. The process was invisible.
Content designers doing audits manually weren't just slow, they were working across disconnected tools with no shared standard. One person's "needs updating" was another's "migrate as-is." There was no common rubric, no audit trail, and no way to make decisions defensible at scale. The problem wasn't the humans. It was that nobody had designed the process they were being asked to run.
01
No shared criteria
Every reviewer made judgment calls in isolation. The same page could get a different recommendation depending on who reviewed it and on which day.
02
Fragmented tooling
Performance data lived in one place, SEO signals in another, content quality was a gut call. Nobody had a single view of what was actually happening with any given page.
03
No scalable output
At 2,000 pages, manual review wasn't just slow, it was a process that would inevitably degrade in quality before it finished. Fatigue is a design problem.
Built in stages. Trusted because of it.
The scoring rubric co-developed with the content team, built before automation, applicable beyond content audits
Defining what good looks like before measuring it.
The first step wasn't building anything automated. It was sitting down with the content team and defining what a good page actually looked like, in writing, with examples. A 0–5 scoring matrix across performance and quality dimensions: content freshness, readability, tone and brand alignment, user guidance, technical signals. Every criterion had a threshold and a definition. We ran the first ten pages through it manually to pressure-test the framework before we trusted it to anything else. What became clear during this process was that the rubric wasn't specific to content migration. The same structure, define criteria, weight by importance, score against evidence, surface rationale, applies directly to UX audits, heuristic reviews, and accessibility assessments. The methodology is reusable for any structured evaluation where consistency and scale matter.
A designer mapping a system. In FigJam, obviously.
Once the rubric was agreed, I mapped the full automation workflow in FigJam before touching n8n. Where does the data come from? What gets scored? What triggers a recommendation? Where does the human reviewer step in? Mapping it visually first meant that when I built it, I was building something with a clear logic, not reverse-engineering a process from code. The workflow pulled performance data, technical quality signals, and content indicators, ran them through the scoring framework, generated a plain English recommendation and rationale for each page, and compiled everything into a structured dashboard.
The full CAAT workflow, Trigger & URL Discovery → Data Collection → Merging & Scoring → Output → Delivery
Before: 5 disconnected tools, manual correlation. After: unified pipeline via n8n, OpenAI and Airtable.
Ten pages. Both methods. Side by side.
The pilot was the argument. We didn't ask the content team to trust the automation, we showed them. The same ten pages, assessed manually and by the system, outputs compared side by side. Where the system disagreed with the human reviewer, we went back to the rubric. Sometimes the rubric needed tightening. Sometimes the human reviewer had applied criteria inconsistently. The iteration loop between rubric, system, and human judgment continued until the outputs were reliably trustworthy. Then we scaled.
99.5% reduction in audit time.
Rubric co-developed in the first month. System built and piloted at six weeks. Phase one audit complete, all 2,000 pages assessed, scored, and compiled into structured dashboards, by month three. Every page had a recommendation and a rationale. Migration decisions were defensible, consistent, and done.
AND THAT'S HOW IT GOT A NAME
The content team started calling it CAAT, Content Audit Automation Tool. It kept running after the project ended. Then it got a proper interface.
The comparison that made the case, same page, same depth of insight, a fraction of the time
From n8n workflow to a product with its own interface, see CAAT end to end
From n8n workflow to a product with a UI.
What started as a workflow became a standalone tool. CAAT evolved beyond the initial engagement, it got an interface, a dashboard, and a structure that meant someone other than me could run it. The system architecture connected performance data, technical quality indicators, and content signals through a processing layer, with every output human-readable and human-reviewable. The human oversight node was a deliberate design decision from the start: this was built to support the content team's judgment, not replace it.
You can't make the case for automation in the abstract.
The pilot was the right move, technically and politically. Ten pages proved what a presentation couldn't. The rubric co-development was equally important: adoption requires people to see their own judgment reflected in the output. If I did it again, I'd scope the automation as its own workstream from the start. Running two parallel tracks while learning a new tool in real time is manageable, but both deserved more space. The tool outlasted the project. The methodology it introduced, structured criteria, consistent scoring, visible rationale, is one I've carried into other audits since. Including design ones.
When the audit that took an hour now takes one minute.
