Design eines Team-Workspace-Dashboards

Design eines Team-Workspace-Dashboards

Das Team-Workspace-Dashboard von OpenDesign präsentiert einen Acme-Studio-Workspace als Desktop-Arbeitsfläche. Die linke Navigation trennt die Bereiche Workspace, Private und Connections, während die Hauptseite dem Pfad „Acme Studio / Workspace / Team Dashboard“ folgt. Diese Struktur zeigt, wo sich die Leserin oder der Leser befindet, bevor der Dashboard-Inhalt beginnt.

Die Überschrift lautet „Team Dashboard“, gefolgt von „Last edited by Sarah Chen“ und „Last refreshed just now“. Die Steuerelemente zur Aktualisierung liegen im selben horizontalen Band wie diese Metadaten: „Auto · on“ und „Refresh from Notion“. So sind Aktualität und Aktualisierungsabsicht nahe am Seitentitel sichtbar, auch wenn die Komposition diesen Steuerelementen weniger visuelles Gewicht gibt als dem Dashboard selbst.

Das Design nutzt eine zentrierte Seite mit einer maximalen Breite von 1100px innerhalb eines Layouts mit fester Seitenleiste. Diese Proportion lässt die Navigation für den Wechsel zwischen Workspaces verfügbar und reserviert die größere Fläche für gruppierte operative Informationen. Der Kompromiss ist die Dichte: Die Seite kann mehrere Module gleichzeitig zeigen, doch längere Aufgabennamen und Aktivitätsmeldungen müssen in den verfügbaren Spalten umbrechen.

Signale für Teamoperationen

Das Dashboard eignet sich für einen täglichen Team-Check-in, bei dem Nutzende eine kompakte Sicht auf Arbeitsvolumen und Ausnahmen brauchen. Der erste Übersichtsblock enthält vier wörtliche Felder: „Total tasks 142“, „Done this week 23“, „Active members 11 / 14“ und „Docs awaiting review 7“. Jedes Feld hat eine andere semantische Form, daher ist die Zeile als Satz unterschiedlicher Signale nützlicher denn als einzelner Wert.

Die Pfeile liefern Vergleichskontext für drei der Felder: Die Gesamtzahl der Aufgaben liegt 6 über der Vorwoche, erledigte Arbeit liegt 4 darüber, und zur Prüfung ausstehende Dokumente liegen 2 darunter. „Active members 11 / 14 · Stable“ verwendet statt eines Wochenvergleichs einen Nenner und einen qualitativen Zustand. Diese Abweichung ist eine wichtige Designentscheidung: Sie bewahrt die Definition der Mitgliederkapazität, statt jede Kennzahl in dasselbe Vergleichsformat zu zwingen.

Die sichtbaren Werte sind ausdrücklich als Beispieldaten gekennzeichnet. Sie zeigen, wie ein befülltes Dashboard wirken könnte, belegen aber weder die Leistung von Acme Studio noch einen angebundenen Produktiv-Workspace. Für das Design heißt das: Die Oberfläche kann Informationsbeziehungen klar demonstrieren, während reale Kennzahlendefinitionen und Datenherkunft einer späteren Implementierung überlassen bleiben.

Vom Trend zum Active Sprint

In der Seitenmitte wechselt die Seite von der Zusammenfassung zur Erklärung. Das Wochendiagramm trägt den Titel „Tasks created · last 7 days“, zeigt „98 total“ und ordnet die horizontalen Labels als Wed, Thu, Fri, Sat, Sun, Mon und Tue. Die Linie steigt bis Freitag, fällt am Samstag, erreicht am Montag ihren höchsten sichtbaren Punkt und sinkt am Dienstag. So lässt sich ein aktuelles Muster erkennen, statt nur eine Gesamtzahl zu sehen.

Neben dem Diagramm listet „Recent activity“ benannte Aktionen mit relativen Zeiten auf, darunter Sarah Chen, die „Q3 Roadmap planning“ vor 3 min auf In progress verschiebt, und Mike Park, der vor 11 min „Fix mobile nav overflow on iOS“ kommentiert. Das wiederkehrende Muster aus Person, Aktion, Objekt und Zeit unterstützt schnelles Überfliegen. Der Kompromiss: Aktivitätszeilen in natürlicher Sprache können unvorhersehbar umbrechen, wenn Namen oder Objekttitel länger werden.

Danach folgt der Bereich Tasks · Active sprint. Die Begleitzeile lautet Linked database · filtered by Status ≠ Done · sorted by Updated time. Die erfassten Anfangszeilen enthalten keine Done-Einträge, und der lokale Renderer sortiert sie nach seinen Beispiel-Zeitstempeln der Aktualisierung. Er entfernt jedoch keine Zeilen, die durch eine spätere simulierte Aktualisierung als Done markiert wurden; das Filterlabel ist daher kein vollständig implementiertes Verhalten.

Die Spalten sind Name, Status, Assignee, Due und Priority. Im erfassten Anfangszustand ist Fix mobile nav overflow on iOS Blocked mit High-Priorität, während Pricing experiment readout To do mit Low-Priorität ist. Diese Paarungen unterscheiden Zustand von Dringlichkeit. Aufgabennamen werden mit Auslassungspunkten gekürzt statt umgebrochen; unterhalb von 980px blendet die Vorlage die Seitenleiste sowie die Felder Due und Priority aus, wodurch diese Details weniger sichtbar sind.

Sichtbares Design und Funktionsgrenzen

Die Vorlage implementiert eine lokale Simulation mit Beispieldaten, keinen angebundenen Notion-Workspace. Die anfänglichen KPI-Werte und das Wochendiagramm entsprechen dem erfassten Zustand. Ein Timer für die Aktualisierung beim Öffnen, eine manuelle Schaltfläche Refresh from Notion und eine 30-Sekunden-Schleife für die automatische Aktualisierung verändern lokale Fixture-Werte, Aufgabenzustände und Aktivitätseinträge. Die Vorlage enthält keine Connector-Anfrage, keinen authentifizierten Workspace-Zugriff und keine dauerhafte Speicherung.

Auto · on lässt sich ausschalten, relative Zeitstempel werden lokal aktualisiert, und die Oberfläche behält nach einer Aktualisierung ihr Badge Sample data. Die Fußzeile nennt Notion API und composio.notion, doch diese Labels belegen keine echte Integration. Das anfängliche Toast-Markup lautet Synced — 3 changes from Notion; der laufende Refresh-Handler ersetzt es durch eine Meldung zu Beispieldaten, daher ist der Anfangstext kein Beleg für ein Synchronisierungsergebnis.

Die lokale Simulation zeigt auch, wo Darstellung und Datenregeln auseinanderlaufen können: Eine Zeile kann Done werden, ohne aus dem angekündigten Active-Sprint-Filter entfernt zu werden, und feste Wochenvergleichslabels werden bei Änderungen der KPI-Werte nicht neu berechnet. Eine echte Adaption bräuchte eindeutige Kennzahlendefinitionen, Filterung und Vergleichsberechnungen, bevor diese Anzeigen für Teamentscheidungen genutzt werden.