Jede Business-App, die ich gebaut habe, brauchte dieselben vier Seitentypen
1
Homepage
One per user group. Their top actions, and what needs them now.
2
Utility
Login, reset password, 404. Required, and not where the app gets good.
3
Entity
One per object. The list, the view that suits it, and adding a record.
4
Detail
One record in full, its actions, and everything related to it.
Four years of internal tools and portals, and about 90% of the pages were one of these.
In den letzten vier Jahren habe ich dutzende Business-Apps entwickelt. Interne Tools, CRMs, ERPs, Intranets, Kundenportale, Lieferantenportale, Deal-Rooms. Verschiedene Unternehmen, verschiedene Daten und fast jedes Mal derselbe Satz an Seiten.
Vier Familien. Sie decken etwa 90 % dessen ab, was eine Business-App benötigt. Wenn man sie kennt, wird die schwierigste Frage zu Beginn eines Projekts – welche Seiten brauche ich eigentlich? – zu einer kurzen Checkliste.
Ich spreche von Apps, in die man sich einloggt. Öffentliche Verzeichnisse und Marketing-Seiten funktionieren anders. Eine Business-App hat einen engen, definierten Umfang: Ein Kundenportal existiert, damit Kunden ihre Projekte und Aufgaben sehen können und Ihr Team den Überblick über alle hat. Genau diese Eingrenzung sorgt dafür, dass ein kleiner Satz an Seiten ausreicht.
1. Die Startseite und zuerst die Frage nach der Benutzergruppe
Bevor Sie eine Startseite entwerfen, listen Sie die Gruppen auf, die sich einloggen. Kunden und internes Personal. Lehrer, Eltern und Schüler. Mitarbeiter und das Finanzteam. Diese Entscheidung kommt vor allem anderen, da sie bestimmt, ob Sie eine oder mehrere Startseiten bauen.
Meine Faustregel: Wenn sich mehr als etwa die Hälfte der Blöcke auf der Seite zwischen zwei Gruppen unterscheiden würde, geben Sie jeder Gruppe eine eigene Startseite. Liegt es darunter, reicht eine Seite mit Sichtbarkeitsbedingungen für einige Blöcke.
Eine gemeinsame StartseiteGruppen überschneiden sich stark
- Einige Blöcke werden bedingt angezeigt
- Nur eine Seite beim Rebranding anzupassen
- Wird bei vielen Bedingungen schnell unübersichtlich
Eine Startseite pro GruppeGruppen haben unterschiedliche Bedürfnisse
- Jede Seite wirkt maßgeschneidert
- Keine Bedingungslogik zu verfolgen
- Gemeinsame Änderungen müssen doppelt gemacht werden
Was darauf gehört: die zwei bis vier Aktionen, die diese Gruppe am häufigsten ausführt, und die Dinge, bei denen sie jetzt handeln muss. Nicht mehr. Die App hat einen engen Umfang, also sollte auch die Startseite eng gefasst sein.
Ein Spesen-Tracker macht es konkret. Ein Mitarbeiter loggt sich ein, um einen Antrag zu stellen, also ist das Formular nur einen Klick entfernt und darunter stehen die eigenen, noch ausstehenden Anträge. Das Finanzteam loggt sich ein, um zu genehmigen, also sieht es die Anträge, die auf eine Entscheidung warten. Nicht jeder jemals eingereichte Antrag, nicht die abgelehnten aus dem März. Sondern die Liste, die bearbeitet werden muss.
Alles andere kann in der Navigationsleiste untergebracht werden und sollte es normalerweise auch.
2. Utility-Seiten, in die Sie keine Zeit investieren sollten
Login. Registrierung, oder eine deaktivierte Registrierung bei internen Tools, in die Nutzer eingeladen werden. Passwort vergessen und Passwort zurücksetzen. Die 404-Seite. Ein Onboarding-Flow, falls Nutzer ihr Profil vervollständigen müssen, bevor sie die App nutzen können.
Alles langweilig. Alles notwendig. Aber genau hier wird Ihre App nicht gut.
Das ist die Art von Seiten, die ich ungern baue, und mit Softr muss ich es nicht: Sie werden vorkonfiguriert ausgeliefert, die Arbeit liegt im Styling und Wording. Wenn Sie von Grund auf neu bauen, planen Sie sie trotzdem ein, denn sie existieren in jeder App. Wer die 404-Seite vergisst, riskiert, dass Nutzer in einer Sackgasse landen, ohne zurückzukommen.
3. Entity-Seiten, eine pro Objekt
Wenn die Datenbank einmal steht, schreiben diese Seiten sich fast von selbst. Eine Seite pro Tabelle, die für den Nutzer eine Bedeutung hat. Ein CRM hat Kontakte, Unternehmen, Deals, Aufgaben. Loggen Sie sich bei HubSpot ein, und genau so sieht die Navigation aus.
Die Seite listet Datensätze auf, wobei das Format eine Entscheidung pro Objekt ist:
- Eine Tabelle, wenn es darum geht, eine Zeile unter vielen zu finden und eine hohe Informationsdichte hilft.
- Ein Kanban-Board für alles, was einen Statusdurchlauf hat, wie Aufgaben oder Deals.
- Ein Kalender, wenn das Datum das primäre Navigationsmerkmal ist.
- Ein Raster aus Karten, wenn ein Logo oder ein Foto die Erkennung eines Datensatzes erleichtert.
Sie können zwei Formate als Tabs auf derselben Seite anbieten, wenn verschiedene Nutzer unterschiedlich arbeiten. In meinem CRM hat die Deals-Seite die Pipeline als Standard und daneben eine Tabellenansicht.
Auch die Aktionen gehören hierhin. Datensatz hinzufügen. Liste als CSV exportieren, was kaum Aufwand bedeutet, aber immer angefragt wird. CSV importieren, falls Daten in Stapeln ankommen.
Manchmal ist die Entity-Seite bereits das gesamte Feature. Eine Dokumententabelle mit Name und Datei, die mit nichts anderem verknüpft ist, kann einfach eine Liste mit Bearbeiten- und Löschen-Optionen in jeder Zeile sein. Eine Detailseite ist dann nicht nötig.
4. Detailseiten und was darunter liegt
Normalerweise möchte man einen Datensatz öffnen. Eine Tabellenzeile bietet keinen Platz zum Arbeiten, und ein Unternehmen hat eine Beschreibung, eine Website und Notizen, die irgendwo Platz finden müssen.
Eine Detailseite besteht aus drei Teilen.
Der Datensatz selbst mit den relevanten Feldern, also mehr als auf der Entity-Seite. Die Aktionen: bearbeiten, löschen, Status ändern, jemandem zuweisen. Berechtigungen werden hier individuell gesteuert, sodass beispielsweise nur Admins Kontakte löschen können, während jeder sie bearbeiten darf.
Dann der Teil, den ich immer hinzufüge und der eine App komplett wirken lässt: die verknüpften Datensätze, die darunter aufgelistet sind. Öffnen Sie ein Unternehmen und sehen Sie dessen Kontakte, Deals und vergangene Interaktionen. Öffnen Sie eine Aufgabe und sehen Sie das zugehörige Projekt.
Öffnen Sie diese in einem Modal statt als vollständige Seite, entweder zentriert oder als Slide-In von der Seite. Die URL ändert sich nicht, die Liste bleibt im Hintergrund, und das Zurückkehren ist das Schließen eines Panels statt eines Seitenladevorgangs. Bei einer Liste, die man abarbeitet, macht dieser Unterschied die gefühlte Geschwindigkeit der App aus.
Die zwei zusätzlichen Seiten, die man einplanen sollte
Ein Dashboard. Diagramme und Zähler. Manchmal ist es die Startseite, manchmal eine eigene Seite, wenn der Umfang groß genug ist.
Ein Formular auf einer eigenen Seite. Das ist ein Argument für die Wartbarkeit. Wenn an vier verschiedenen Stellen eine Firma erstellt werden kann und jede Stelle ein eigenes Konfigurationsformular besitzt, bedeutet das Hinzufügen eines Feldes, dass vier Formulare bearbeitet werden müssen, wobei man leicht eines vergisst. Erstellen Sie das Formular einmal auf einer eigenen Seite und lassen Sie jeden Button diese Seite in einem Modal öffnen. Ein Formular, das gewartet werden muss.
Ein ERP nach demselben Prinzip strukturieren
Die vier Familien funktionieren auch bei größeren Apps, sie werden dann nur gruppiert. Bei einem ERP habe ich die Navigation eher nach Abteilungen als nach Objekten organisiert: Lager, Vertrieb, Finanzen. Hinter jeder Abteilung liegen die gleichen Entity-Seiten.
Zwei Dinge habe ich dort anders gemacht und würde ich wieder so tun. Einige Seiten fassen zwei Objekte zusammen, sodass der Vertrieb Aufträge und Kunden gemeinsam führt, da die Mitarbeiter im Vertrieb in beiden Bereichen arbeiten. Und die Homepage listet nicht alle Produkte auf, sondern nur solche mit weniger als 100 Einheiten auf Lager, unter einer Überschrift, die besagt, dass diese Aufmerksamkeit benötigen. Eine auf Handlungsbedarf gefilterte Liste schlägt auf einer Homepage jede vollständige Liste.
Die Datenbank richtig aufsetzen, dann folgen die Seiten
- 1App-Umfang definierenWas die App ermöglichen soll
- 2Nutzergruppen auflistenWer sich einloggt und was jede Gruppe benötigt
- 3Tabellen entwerfenEine pro echtem Objekt, korrekte Felder
- 4Seiten ableitenEine Entity-Seite pro Objekt, Details dahinter
Eine Tabelle pro echtem Objekt, mit den dazugehörigen Feldern. Eine Aufgabe hat eine Beschreibung, ein Fälligkeitsdatum, einen Verantwortlichen. Eine Firma hat einen Namen, eine Website, eine Branche. Wenn das falsch ist, kann auch kein Seitenlayout mehr retten.
KI ist in diesem Bereich wirklich gut. Beschreiben Sie das gewünschte CRM und Sie erhalten einen soliden ersten Datenbankentwurf. So starte ich mittlerweile die meisten Projekte.
Das Framework kennen, um es verlassen zu können
Der KI-Builder von Softr erstellt Apps genau in dieser Form. Das tun andere auch. Das wirft eine berechtigte Frage auf: Wenn das Tool das Muster bereits kennt, warum sollte man es dann noch lernen?
Weil die generierte Version ein Standard ist, und Standards sind der Durchschnitt aller Apps, nicht Ihre. Die Momente, die eine App gut machen, sind die Abweichungen: keine Interaktionsseite bauen, Details in einem Seitenpanel statt über eine Route öffnen, die Homepage-Liste auf das zu Filternd beschränken, was Aufmerksamkeit benötigt. Ein KI-Builder wird das nicht vorschlagen, da Ihr Prompt ihm nicht mitgeteilt hat, dass Ihre Leute den ganzen Tag eine Liste abarbeiten.
Ich stelle generell dasselbe bei Agenten fest, egal ob in Claude Code oder in einem App-Builder. Sie sind schnell darin, die Standardform zu produzieren. Ihr Beitrag besteht darin, zu wissen, welcher Teil der Standardform für Sie falsch ist. Das ergibt sich nur, wenn man die Sache oft genug von Hand gebaut hat, um eine eigene Meinung dazu zu haben.
Nutzen Sie also den Generator. Öffnen Sie dann das Ergebnis und ändern Sie die drei Dinge, die Sie anders gemacht hätten.