Architektur zuerst: Warum wir bei jedem Projekt Struktur vor Ästhetik entwerfen

Was Architektur im Kontext einer Website bedeutet

Wenn wir über Architektur in der Webentwicklung sprechen, meinen wir die zugrundeliegende Struktur, die bestimmt, wie eine Website organisiert ist, wie Inhalte gruppiert werden und wie Nutzer sich durch sie bewegen. Sie ist verschieden von - und kommt vor - dem visuellen Design einzelner Seiten.

Architektur umfasst: die Menge der Seitentypen (welche Arten von Seiten muss diese Website haben?), die Navigationsstruktur (wie stehen diese Seiten zueinander in Beziehung, und wie gelangen Nutzer zwischen ihnen?), das Inhaltsmodell (welche Informationen muss jeder Seitentyp enthalten?) und die URL-Struktur (wie werden Seiten adressiert, und was kommuniziert diese Adresse?).

Keine dieser Fragen ist visuell. Sie haben nichts damit zu tun, ob das Hero-Bild vollbreit oder eingerahmt sein soll, oder ob die Farbpalette warm oder kühl sein soll. Es sind strukturelle Fragen, und sie haben Konsequenzen, die die gesamte Lebensdauer der Website andauern.

Was passiert, wenn die Ästhetik zuerst kommt

Der häufigste alternative Ansatz - mit einem visuellen Design in Figma oder ähnlichem zu beginnen - produziert schnell ansprechende Mockups. Das ist ein Grund für seine Beliebtheit. Ein poliertes visuelles Design fühlt sich nach Fortschritt an und gibt Kunden frühzeitig etwas Konkretes, worauf sie reagieren können.

Das Problem ist, dass visuelle Mockups implizite strukturelle Entscheidungen treffen, die dem echten Inhalt oft nicht standhalten. Ein Homepage-Design könnte eine einzelne Überschrift und einen zweiteiligen Untertitel voraussetzen. Wenn der Kunde seinen tatsächlichen Text schickt, sind es vier Absätze. Das Design bricht.

Ein Services-Seitendesign könnte fünf Leistungen in einem dreispaltigen Raster voraussetzen. Der Kunde hat elf Leistungen in vier Kategorien. Das Raster funktioniert nicht. Ein neues Layout muss entworfen werden, was möglicherweise mit der visuellen Sprache des restlichen Designs in Konflikt steht.

Diese Konflikte sind keine seltenen Ausnahmefälle. Sie sind das vorhersehbare Ergebnis des Entwurfs visueller Layouts, bevor man versteht, welchen Inhalt sie aufnehmen müssen. Jede Design-Revision, die passiert, weil echter Inhalt nicht zur angenommenen Struktur passt, ist ein Kostenpunkt, den Architektur-zuerst vermeidet.

Informationsarchitektur: das erste Ergebnis

Bei Linekern ist das erste Ergebnis bei jedem Projekt ein Informationsarchitektur-Dokument. Es listet jede Seite auf, die die Website braucht, beschreibt, was jede Seite enthält, definiert die Navigationshierarchie und legt die URL-Struktur fest.

Das klingt nach bürokratischem Overhead. In der Praxis dauert es zwei bis vier Stunden, es zu erstellen, und spart deutlich mehr an Revisions-Zyklen ein. Es erzwingt, dass zwei Dinge gleichzeitig passieren: Der Kunde muss artikulieren, was seine Website tatsächlich sagen muss, und wir müssen das Unternehmen gut genug verstehen, um zu wissen, ob die vorgeschlagene Struktur ihm dienen wird.

Häufige Erkenntnisse in dieser Phase: Der Kunde glaubt, er braucht eine Seite für jede Leistung, hat aber tatsächlich drei Leistungslinien, die jeweils eine Seite sein sollten, nicht fünfzehn einzelne Leistungen als separate Seiten. Oder die Website braucht einen Ressourcen-Bereich, der im ursprünglichen Briefing nicht vorgesehen war. Oder die vom Kunden vorgeschlagene Navigationsstruktur würde die kommerziell wichtigsten Seiten zwei Ebenen tief vergraben.

Das sind strukturelle Probleme. Sie in einem Dokument zu finden ist günstig. Sie in einem fertigen Design zu finden - oder schlimmer, nach dem Launch - ist teuer.

Inhaltszonen und Seitentypen

Sobald die Seitenliste definiert ist, entwerfen wir das Inhaltsmodell: Welche Informationen braucht jeder Seitentyp, und in welcher Form? Eine Leistungsseite könnte eine Überschrift, eine kurze Beschreibung, eine Liste von Features, eine Fallstudie-Referenz und einen CTA benötigen. Eine Über-uns-Seite benötigt einen narrativen Abschnitt, einen Team-Abschnitt mit individuellen Profilen und ein Wertestatement. Eine Kontaktseite benötigt ein Formular, Standortinformationen und einen FAQ-Bereich.

Das sind die Inhaltszonen - die benannten Bereiche, die jede Seite eines bestimmten Typs enthalten wird. Sie definieren, was die Kernset-CMS-Felder sein werden. Sie schränken auch das visuelle Design ein: Das Design muss für alle Inhalte funktionieren, die eine Seite dieses Typs enthalten wird, nicht nur für das spezifische Beispiel, das im Mockup verwendet wird.

Das ist die direkte Verbindung zwischen Informationsarchitektur und der CMS-Struktur. Wenn wir die Inhaltszonen in der Architekturphase korrekt definieren, werden die CMS-Felder, die daraus entstehen, kohärent und nutzbar sein. Wenn wir die Architekturphase überspringen und die CMS-Felder aus dem visuellen Mockup entwerfen, enden wir oft mit Feldern, die entweder zu restriktiv oder zu flexibel für das sind, was Redakteure tatsächlich tun müssen.

Navigationshierarchie und Nutzerreisen

Die Navigationsstruktur ist eine separate architektonische Entscheidung von der Seitenliste. Eine Website kann fünfzig Seiten haben, die in einer klaren dreistufigen Hierarchie organisiert sind, oder fünfzehn Seiten mit einer Navigation, die Nutzer zwingt, vier Klicks zu machen, um jedes Ziel zu erreichen. Die Anzahl der Seiten ist weniger wichtig als die strukturelle Logik, die sie verbindet.

Wir kartieren Nutzerreisen explizit in der Architekturphase: Wie bewegt sich ein potenzieller Kunde von der Landingpage zum Conversion-Punkt? Wo sind die Entscheidungsmomente? Welche Seiten sehen die meisten Nutzer, und auf welche greifen nur Nutzer zu, die bereits entschlossen sind? Das bestimmt, welche Seiten in der primären Navigation sein sollten, welche durch kontextuelle Links von anderen Seiten zugänglich sein sollten, und welche nur durch die Suche zu finden sein sollten.

Die URL-Struktur folgt aus dieser Hierarchie. Saubere, beschreibende URLs - /leistungen/webdesign/ statt /?p=234 - dienen sowohl der Navigationsklarheit als auch dem SEO. Sie sollten bewusst gestaltet werden, mit dem Verständnis, dass das Ändern von URLs nach dem Launch einer Website 301-Weiterleitungen erfordert und SEO-Risiken mit sich bringt.

Warum das zu besseren Ergebnissen führt

Der Architektur-zuerst-Ansatz produziert aus zwei zusammenlaufenden Gründen bessere Ergebnisse. Der erste ist die Vermeidung nachgelagerter Kosten: Strukturelle Probleme, die früh gefunden werden, sind günstig zu beheben; Strukturelle Probleme, die nach dem visuellen Design oder der Entwicklung gefunden werden, sind teuer. Der zweite ist, dass das tiefe Verständnis der Struktur einer Website vor ihrer Gestaltung visuelle Designs produziert, die tatsächlich mit den Inhalten funktionieren, die sie enthalten werden.

Ein Design für eine Leistungsseite, das in dem Wissen konzipiert wurde, dass es zwischen drei und zwölf Features in Kategorien mit nutzerdefininierten Namen aufnehmen muss, sieht anders aus als ein Design, das eine bestimmte Anzahl von Features mit bestimmten Namen vorausgesetzt hat. Es ist robuster. Es passt sich dem tatsächlichen Inhaltsbereich an, nicht nur dem Beispiel, das im Mockup verwendet wird.

Die Architekturphase fügt typischerweise eine Woche am Anfang eines Projekts hinzu. Sie entfernt weit mehr als eine Woche Revisionszeit aus der Mitte und dem Ende. Noch wichtiger ist, dass es bedeutet, dass die Website, die gebaut wird, die richtige für das Unternehmen ist - statt einer Website, die im Mockup richtig aussah und sich nach dem Hinzufügen echter Inhalte als strukturell problematisch herausstellte.