Altair Capital
Ein Investor-Dashboard mit räumlicher Daten-Visualisierung und ruhiger Motion, das Lighthouse-100 hält, ohne den Stack zu überfordern.
Herausforderung
Altair Capital wollte ein Investor-Dashboard, das in Investor-Pitches genauso wie auf dem MacBook eines Portfoliomanagers Charakter zeigt — ohne den nüchternen Datenfokus zu untergraben. Das Risiko: jede WebGL-Spielerei lenkt von Zahlen ab, jede konservative Lösung wirkt wie irgendein Bloomberg-Klon.
Ansatz
Wir trennten räumliche Daten-Visualisierung (3D-Karte der Holdings, Zeit-Skalierung über Z-Achse) strikt vom UI-Layer. Motion ist ausschließlich an Daten-Wechsel gebunden, nicht an Hover-States. Das Branding bleibt auf dem 3D-Element, das UI bleibt absolut still.
Die 3D-Karte ist da, wenn jemand fragt, und still, wenn gearbeitet wird. Das ist die ganze Idee: Charakter ohne Ablenkung.
Prozess
≈ 3.5w / Phase · Σ 14 Wochen- Phase 01≈ 3.5w
Daten-Audit: ausgiebiges Sparring mit Altair Quant-Team. Welche Charts beweisen Edge, welche sind UI-Theater?
- Phase 02≈ 3.5w
WebGL-Prototyp: 3D-Holdings-Karte mit Time-Scrubber. Iteriert bis Daten in 5s lesbar sind.
- Phase 03≈ 3.5w
UI-System: Klare Typografie, alles statisch, alle Daten-Wechsel sind die einzige Animation.
- Phase 04≈ 3.5w
Performance-Pass: Custom shader-Caching, Code-Splitting pro Route, Lighthouse-100 Desktop erreicht.
Ergebnis
Das Konzept zielt auf ein Dashboard, das im Investor-Pitch Eindruck macht und im Alltag nicht stört.
Anspruch an die Umsetzung: Lighthouse-100 auf dem Desktop, Daten in unter fünf Sekunden lesbar, die 3D-Karte als ruhiger Beweis statt als Effekt.
Was wir geliefert haben.
Kein „wir waren dran“-Bericht. Konkrete Artefakte, die am Ende der Engagement im Repository, im CMS und auf der produktiven Domain stehen.
Brand · Design
- Type-Stack (Söhne + Tiempos)
- Component-Library
- Pitch-Deck Template
Engineering
- Next.js 15 App-Router Frontend
- Custom WebGL Holdings-Karte (Three.js)
- D3 Time-Scrubber + Custom Shader
Operations
- CI/CD Pipeline
- Lighthouse-100 Monitoring
- 30/60/90 Post-Launch-Sprint
Konzept-Studie — Zielwerte, keine verifizierten Live-Daten.
Performance
Lighthouse-100 Desktop als Vorgabe, nicht als nachträgliches Optimierungsziel
Lesbarkeit
Jede Holding in unter fünf Sekunden erfassbar — sonst ist die Visualisierung gescheitert
Ruhe
Bewegung ausschließlich an Daten-Wechsel gebunden, keine Hover-Spielerei
Regulatorisch
Annahme: Reporting-Compliance — jede Visualisierung muss auditierbar und auf Quelldaten zurückführbar sein.
Performance
Lighthouse-100 Desktop als Vorgabe vor dem ersten Build-Tag, nicht als spätere Politur.
Daten-Disziplin
Kein Chart ohne Aussage. Was nur dekoriert, fliegt raus.
Stack
Annahme: bestehende Quant-Backend-API bleibt unangetastet, nur das Frontend wird gebaut.
WebGL-Holdings-Karte mit echtem 3D-Z-Achsen-Zeitskala — räumliche Daten als räumliche Daten.
Stacked-Bar-Charts à la Bloomberg — funktional, aber identisch mit jeder anderen Investor-Plattform.
Motion ausschliesslich an Daten-Wechsel gebunden, keine Hover-Animationen.
Sticky-Header mit scroll-aware Opacity — würde die Daten-Linien optisch zerschneiden.
Sans (Söhne) für UI-Layer + Tiempos für Headlines.
Generic Inter über die ganze Site — würde die Marke gegen Bloomberg-Klone nicht differenzieren.
So wäre der Plan nach dem Launch: 30 Tage Politur, dann ein Quartals-Rhythmus für neue Asset-Klassen und Datenquellen. Das Reporting bleibt beim Team, das es betreut — wir kommen für gezielte Erweiterungen zurück, nicht für die tägliche Pflege.