CASE STUDY 03 · CLIENT SYSTEMS
Quality is
a system.
For an independent art school in Munich, I designed the system their content moves through: publication checks, decision criteria, reporting structure and site-architecture guidance.
The deliverable was not more content.
The core work was a publication QA package: severity-scored checks, consistent report templates and a binary ready/not-ready decision. The system turns subjective review into a repeatable release gate and gives the client a clear priority order when issues compete for attention.
Publishing would create material user, legal or technical risk.
Resolve before release because the issue affects the page’s primary job.
Important improvement with a planned owner and deadline.
Polish that does not block a ready verdict.
Architecture decisions came before page production.
I worked through which pages should exist across programmes, locations, courses and teachers. Hub-and-spoke planning created clearer relationships while page-existence criteria reduced cannibalisation and doorway-page risk.
The useful question was not “Can we create this page?” It was “Does this page serve a distinct audience need, and can it carry enough original value to justify its own URL?”
The inherited stack was part of the challenge.
The site runs on WordPress with Avada—a stack I did not choose—for a client with its own priorities and publishing habits. That constraint makes the system more representative of real website work than a greenfield build. Good operating models have to survive the tools and decision-making structures already in place.
The autonomy and review logic is expanded on the approach page. No internal messages, colleague quotes, restricted screenshots or proprietary client data are published.
Scope and limits
This page describes methodology and verified deliverables. It does not claim that every designed workflow is deployed or used autonomously. The client remains anonymised until written permission is documented.