Die Entscheidung beginnt beim Ziel, nicht beim Design.

Ein Relaunch kann attraktiv wirken, obwohl die wichtigste Hürde an einer unklaren Leistung oder einem ungeeigneten Kontaktweg liegt. Umgekehrt können viele kleine Korrekturen teuer werden, wenn Navigation, Komponenten und Betrieb bei jeder Änderung gegeneinander arbeiten.

Deshalb werden zuerst vier Fragen getrennt: Was sollen passende Besucher verstehen? Welche Entscheidung soll die Website erleichtern? Welche Teile des Bestands funktionieren bereits? Welche technischen oder organisatorischen Grenzen verhindern eine verlässliche Weiterentwicklung?

Ein Befund beschreibt eine Aufgabe, nicht einen Geschmack.

„Die Website wirkt alt“ ist noch kein belastbarer Entscheidungsgrund. Hilfreicher ist ein konkreter Befund: Eine priorisierte Leistung bleibt unverständlich, die mobile Navigation verhindert einen Kernweg oder wesentliche Inhalte lassen sich im vorhandenen System nicht zuverlässig pflegen.

Zu jedem Befund gehören die betroffene Seite, eine beobachtbare Auswirkung und ein Zielzustand. So lassen sich Verbesserung und Neubau an derselben Aufgabe vergleichen, statt zwei unterschiedlich große Wunschlisten gegeneinander zu rechnen.

Gezielt verbessern, wenn die Grundlage noch trägt.

Eine Verbesserung ist meist sinnvoll, wenn die zentralen Seitentypen technisch stabil sind, das visuelle System konsistent erweitert werden kann und die größten Lücken klar eingegrenzt sind. Typische Module sind eine verständlichere Leistungsseite, eine bessere interne Führung, eine sauberere Kontaktstrecke oder die Korrektur konkreter Indexierungsprobleme.

Der Vorteil liegt nicht nur im kleineren Umfang. Ein begrenzter Sprint liefert schneller Beobachtungen darüber, ob die angenommene Hürde tatsächlich relevant war. Voraussetzung ist ein schriftlicher Prüfrahmen: Welche Seiten ändern sich, welche bewusst nicht und woran gilt das Modul als funktional abgenommen?

Neu bauen, wenn das System die Aufgabe verhindert.

Ein neues Website-System wird plausibel, wenn wichtige Inhalte im Bestand nicht zuverlässig serverseitig erreichbar sind, mobile Reihenfolge und Barrierefreiheit nur mit wiederkehrenden Sonderlösungen funktionieren oder die Informationsarchitektur mehrere Zielgruppen dauerhaft vermischt.

Auch der Betrieb gehört zur Entscheidung. Wenn jede Textänderung Entwicklerzugriff braucht, sicherheitsrelevante Abhängigkeiten nicht gepflegt werden können oder das System keine verlässliche Veröffentlichung und Rücknahme ermöglicht, ist ein weiterer kosmetischer Patch selten die wirtschaftlichere Antwort.

Eine kleine Entscheidungsmatrix.

Verbessern: Die Hauptstruktur passt, Probleme sind lokalisierbar, Inhalte können eigenständig gepflegt werden und ein begrenztes Modul erzeugt einen prüfbaren Fortschritt.

Neu bauen: Struktur, Komponenten oder Betrieb blockieren mehrere priorisierte Ziele gleichzeitig; Änderungen erzeugen regelmäßig neue Inkonsistenzen; oder die Sicherheits- und Zugänglichkeitsbasis ist nicht belastbar.

Noch nicht entscheiden: Zielgruppen, Angebot, Verantwortlichkeiten oder notwendige Freigaben sind so offen, dass beide Wege auf Annahmen beruhen würden. Dann ist eine Diagnose die kleinere und ehrlichere erste Leistung.

Beide Varianten über denselben Zeitraum vergleichen.

Ein kleiner Startpreis für Einzelkorrekturen ist nicht mit einem vollständigen Neubau vergleichbar, wenn wiederkehrende Pflege, technische Altlasten und spätere Erweiterungen ausgeblendet bleiben. Umgekehrt rechtfertigt eine lange Wunschliste keinen Neubau, wenn ein begrenzter Sprint die wichtigste Annahme günstiger prüfen kann.

Der Vergleich nennt deshalb für beide Wege denselben Zeithorizont, enthaltene Arbeit, Mitwirkung, laufende Pflege, Risiken und Rückkehrmöglichkeit. Ein kleiner Prototyp oder eine überarbeitete Kernseite kann vor dem großen Auftrag zeigen, ob Struktur und Arbeitsweise tragen.

Abnahme: Funktion, Verständnis und Geschäftswirkung trennen.

Eine technische Prüfung kann zeigen, dass Links, Formulare, Statuscodes und Layoutzustände funktionieren. Ein moderierter Verständnistest kann Hinweise geben, ob Menschen Leistung und nächsten Schritt erfassen. Ob daraus passendere Anfragen entstehen, braucht dagegen reale Daten über einen vereinbarten Zeitraum.

Diese Nachweise sind nicht austauschbar. Auch automatisierte Barrierefreiheitsprüfungen ersetzen keine sachkundige menschliche Bewertung. Ein ehrlicher Abschluss benennt deshalb, was getestet wurde, welche Beobachtung daraus folgt und was weiterhin offen bleibt.

Arbeitsmittel

Entscheidungsmatrix

BeobachtungEher verbessernEher neu bauen
InformationsarchitekturHauptwege sind tragfähig; wenige LückenZielgruppen und Leistungen bleiben strukturell vermischt
Technik und BetriebSicher pflegbar und erweiterbarWiederkehrende Sonderlösungen oder ungepflegte Basis
LernrisikoEin begrenzter Sprint prüft die AnnahmeEinzelmaßnahmen können das Grundproblem nicht isolieren
BefundWenige Seiten oder Komponenten haben klar benannte FehlerMehrere Kernwege scheitern an derselben Systemgrenze
ZeithorizontPflege und Erweiterung bleiben über den Vergleichszeitraum tragfähigFortgesetzte Reparaturen wären im selben Zeitraum riskanter als die Migration