Fundara: finanzielle Klarheit und Kontrolle

Der Ursprung

Das Unternehmen wuchs schneller als die Werkzeuge, die es zusammenhielten. Die Rechnungen lagen an einem Ort, die Liquiditätsplanung an einem anderen, die Kreditverpflichtungen wieder ganz woanders. Niemand hatte jederzeit ein klares Bild der gesamten Finanzlage, ohne es stundenlang von Grund auf zusammenzutragen, und das passierte jede einzelne Woche.

Der Auftrag klang einfach: alles an einen Ort bringen. Das eigentliche Problem dahinter war Vertrauen. Wer schon einmal unter unordentlichen Daten gelitten hat, braucht nicht nur bessere Software. Diese Person muss einen Bildschirm öffnen und dem, was dort steht, sofort glauben, ohne es zuerst mit einer Tabelle abzugleichen.

Dort begann die eigentliche Designarbeit.

Die Herausforderung

Finanzsoftware steht und fällt mit Vertrauen. Glaubt jemand der Zahl auf dem Bildschirm nicht, spielt alles andere am Design keine Rolle. Die Aufgabe war also nicht nur, das Produkt benutzbar zu machen, sondern auf einen Blick vertrauenswürdig, auch für Menschen ohne Finanzausbildung.

Drei Dinge mussten gleichzeitig stimmen. Komplexe, umfangreiche Daten mussten einfach lesbar sein, ohne ihre Komplexität zu verschweigen. Die Struktur musste mitwachsen, mit neuen Kontoarten, neuen Berichten und neuen Teammitgliedern, ohne jedes Mal ein Redesign. Und das Produkt musste am ersten Tag genauso funktionieren wie nach einem Jahr im Einsatz, wenn die Tabellen verschwunden sind und es die einzige verlässliche Quelle ist.

Zuerst die Informationsarchitektur

Bevor ich einen einzigen Screen anfasste, teilte ich das Produkt in zwei klare Bereiche: Management (Dashboard, Konten, Transaktionen) für die tägliche Arbeit und Reporting (Finanzübersicht, Transaktionsverlauf, Kreditentwicklung) für Entscheidungen, die einen längeren Blick brauchen. Diese Struktur testete ich mit Card Sorting und Usability-Sitzungen, bevor ich weiterbaute, denn ein Fehler hier hätte sich durch jeden späteren Screen gezogen.

Die neue Struktur hat sich bewährt. In den Tests fanden die Teilnehmenden wichtige Berichte rund 40% schneller als in der alten, flacheren Struktur.

Die Komponenten gestalten, die das Vertrauen tragen

Einige wenige Entscheidungen leisteten den grössten Teil der Arbeit.

Übersichtskarten. Jede zeigt eine einzige Zahl, die zählt, Umsatzwachstum, Einzahlungen, Auszahlungen, und den Vergleich gleich dazu. Niemand muss tiefer klicken, um zu wissen, ob heute ein guter Tag ist.

Visuelle Auswertungen. Ring- und Flächendiagramme ersetzen Tabellen überall dort, wo die Frage lautet, wie etwas aussieht, nicht wie hoch der genaue Wert ist. Tabellen bleiben für alles, was Präzision braucht.

Datentabellen mit Status. Farbige Badges und einheitliche Tabellenmuster machen lange Konto- und Transaktionslisten überfliegbar, ohne dass man jede Zeile lesen muss.

Kreditentwicklung in einfacher Sprache. Ich verwendete «Zahlungsverlauf» statt des technischeren Begriffs, den der Kunde intern ursprünglich nutzte, weil es dem entsprach, wie die eigenen Nutzenden in den Interviews darüber sprachen. Ein kleines Wort, aber ein echter Unterschied darin, wie schnell Menschen dem Screen vertrauten.

Barrierefreiheit als Standard, nicht als Audit. Screenreader-Ebenen, Kontrast und Tastaturbedienung waren von der ersten Komponente an eingebaut und wurden nicht nachträglich ergänzt.

Das Design System: bewusst von Hand gebaut

Auf diesen Teil des Projekts bin ich am stolzesten, und ihn kann ich am genauesten zeigen, weil er ganz von mir stammt: die Architektur, die Benennung, die Logik.

Ich baute das System auf einer strikten dreistufigen Token-Hierarchie auf. Primitive Tokens sind Rohwerte ohne zugewiesene Bedeutung, etwa --blue-600 oder --space-m. Semantische Quell-Tokens geben denselben Primitiven eine Aufgabe für ein bestimmtes Theme: --semantic-light-text-default zeigt auf ein bestimmtes Grau, aber nur im hellen Modus. Alias-Tokens sind die sauberen, endgültigen Tokens, die im CSS der Komponenten tatsächlich verwendet werden, etwa --text-default, und die nie wissen müssen, welches Theme aktiv ist.

Der Dark Mode funktioniert, weil die Alias-Tokens einmal bei :root gegen die helle semantische Ebene definiert sind und eine einzige Überschreibung mit html[data-theme="dark"] festlegt, worauf dieselben Alias-Tokens zeigen. Jede Komponente schreibt genau einmal color: var(--text-default) und erhält beide Themes ohne Mehraufwand.

In einem zweiten Durchgang verfeinerte ich die Benennung selbst, von langen, beschreibenden Token-Namen hin zu einem kürzeren, entwicklerfreundlichen Standard wie --space-l, --radius-m oder --font-weight-bold, nachdem ich geprüft hatte, dass das System von Anfang bis Ende funktioniert.

Sobald dieses Fundament stand, waren neue Screens keine Arbeit mehr von null an. Eine neue Kontoart oder ein neuer Bericht brauchte keine neuen Farben, keine neuen Abstandsentscheidungen und keine neu erfundene Komponente. Es genügte, die vorhandenen Tokens auf ein neues Layout anzuwenden. Molecules und Templates entstanden aus bewährten Teilen, statt zweimal gestaltet zu werden. Das ist der echte Test für ein Design System: nicht, wie es am ersten Tag aussieht, sondern wie schnell der zehnte Screen im Vergleich zum ersten steht.

Ergebnis

Wichtige Berichte waren nach der neuen Navigation rund 40% schneller auffindbar, direkt in Usability-Tests gemessen. Der Zeitaufwand für das regelmässige Monatsreporting sank nach dem Launch um rund 35%. Die KI-gestützte Kategorisierung von Transaktionen wurde von aktiven Nutzenden stark und dauerhaft angenommen. Und unter all dem sorgte die Token-Architektur dafür, dass neue Arbeit nicht mehr bei null begann. Jede neue Kontoart, jeder neue Bericht, jeder neue Screen griff auf dieselben primitiven, semantischen und Alias-Ebenen zurück. Das System machte das Produkt nicht nur einheitlich. Es beendete das Rätselraten und machte das Bauen mit jedem weiteren Screen schneller und verkürzte die Zeit für ein neues Template oder Molecule um rund 61%.

• ~40% Schneller zum richtigen Bericht Nach der neuen Navigation
• ~35% Weniger Zeit für das Monatsreporting Nach dem Launch
• ~61% Schnellerer Bau von Templates und Molecules Sobald das Design System stand

Was ich gelernt habe

Ein skalierbares Finanzprodukt überlebt nicht ohne ein echtes Design System, und damit meine ich kein UI-Kit, sondern ein System. Tokens, Komponenten und eine Benennungslogik, die die nächste Entwicklerin oder der nächste Entwickler übernehmen kann, ohne mich zu fragen, was etwas bedeutet. Das zahlt sich in dem Moment aus, in dem jemand den zweiten Screen baut statt den ersten.

Die schwierigere Lektion war eine Einschränkung, die ich bei eigenen Projekten nie hatte: etwas zu bauen, an das ich voll glaube, und zu wissen, dass ich die Geschichte ohne das eine Detail erzählen muss, das sie sofort überprüfbar machen würde, den Namen des Kunden. Die Arbeit musste durch ihre fachliche Qualität für sich stehen, weil sie sich nicht auf ein Logo stützen konnte.