Homepage
Eine pro Nutzergruppe. Top-Aktionen und Dinge, die Aufmerksamkeit erfordern.
Utility
Login, Registrierung, Passwort zurücksetzen, 404. Notwendig, aber nicht Teil Ihres Designs.
Entity
Eine pro Objekt in Ihrer Datenbank. Listet Datensätze auf, erstellt neue.
Detail
Ein vollständiger Datensatz, dessen Aktionen und die damit verknüpften Datensätze.
## 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 Startseite** (Gruppen ü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 Gruppe** (Gruppen haben unterschiedliche Bedürfnisse)
- Jede Seite wirkt maßgeschneidert
- Keine Bedingungslogik zu verfolgen
- Gemeinsame Änderungen müssen doppelt gemacht werden
_Die 50%-Grenze ist eine Gewohnheit, kein exaktes Maß. Hier beginnt eine bedingte Seite für die Person, die sie später warten muss, meist unleserlich zu 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.
**Nicht jede Tabelle verdient eine eigene Seite**
In diesem CRM gibt es eine Interaktionstabelle, aber keine Interaktionsseite. Eine Interaktion ergibt nur im Zusammenhang mit einem Kontakt Sinn, daher erscheint sie auf der Detailseite des Kontakts und nirgendwo anders. Eine Seite pro Tabelle ist der Ausgangspunkt, nicht die feste Regel. Fragen Sie sich, ob jemals jemand eine Liste aller Interaktionen öffnen würde.
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.
**Navigation von einer Entity-Seite zur Detailseite eines Datensatzes und von dort zur Detailseite eines verknüpften Datensatzes, wobei jeder in einem Seitenpanel über der Liste öffnet.**
Kontakte
Entity-Seite, die vollständige Liste
Ein Kontakt, in einem Seitenpanel
Felder, dann Bearbeiten und Löschen, dann das verknüpfte Unternehmen und vergangene Interaktionen
Dieses Unternehmen, in einem Seitenpanel
Eigene Felder, Kontakte, Deals
Ö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
1. **App-Umfang definieren**. Was die App ermöglichen soll
2. **Nutzergruppen auflisten**. Wer sich einloggt und was jede Gruppe benötigt
3. **Tabellen entwerfen**. Eine pro echtem Objekt, korrekte Felder
4. **Seiten ableiten**. Eine Entity-Seite pro Objekt, Details dahinter
_Schritt drei ist der zeitintensivste Teil. Sobald die Objekte stimmen, ist die Erstellung der Seiten fast mechanisch. Deshalb äußert sich eine schlechte Tabellenstruktur in einer verwirrenden App._
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.