STRATEGIE2. Juli 2026

Komplexität: Wie ruiniere ich eine erfolgreiche App (nicht)? Finanz-Informatik-Praxis

Inga Hammy, Finanz Informatik, spricht über Komplexität: Wie ruiniere ich eine erfolgreiche App (nicht)? <q>FI
Inga Hammy, Finanz Informatik FI

Bei Banking-Apps skaliert nicht nur Traffic, sondern auch Komplexität. Wer neue Funktionen nur addiert, riskiert, in selbstgebauter Komplexität zu scheitern. Doch es geht auch anders.

von Inga Hammy und Patrick Fritz, Finanz Informatik

Wie bleibt eine Anwendung im Banking für Nutzerinnen und Nutzer verständlich, wenn sie immer mehr Funktionen, Zielgruppen, Bedienarten und regulatorische Anforderungen gleichzeitig abbilden muss? Vielen Anwendungen gelingt dieser Spagat nicht. Meistens geschieht das Scheitern dabei in Zeitlupe: Neue Features mit zusätzlichen Menüpunkten kommen hinzu, daraus ergeben sich neue Prozesswege und weitere Oberflächen. Was zunächst als Funktionsgewinn gedacht ist, führt zu wachsender Komplexität. Nutzer finden Funktionen schlechter, Prozesse sind unübersichtlich und unterschiedliche Bedienlogiken entstehen nebeneinander.

Irgendwann ist eine einst elegante App zu einem Labyrinth aus Menüs, Funktionen und Sonderfällen geworden. Spätestens an diesem Punkt suchen Nutzerinnen und Nutzer nicht mehr nach Funktionen, sondern nur noch nach dem Ausgang.“

Patrick Fritz, Finanz Informatik, spricht über Komplexität: Wie ruiniere ich eine erfolgreiche App (nicht)? <q>FI
Patrick Fritz, Finanz Informatik FI

Aber es geht auch anders. Die App Sparkasse ist ein Beispiel dafür, wie sich diese Herausforderung im Massenbetrieb lösen lässt. Hinter der App steht das Team der Finanz Informatik (FI), dem zentralen IT-Dienstleister und Digitalisierungspartner der Sparkassen-Finanzgruppe, und das FI-Tochterunternehmen Star Finanz. Mehr als 20 Millionen Nutzerinnen und Nutzer greifen regelmäßig auf sehr unterschiedliche Funktionen zu. Pro Monat verarbeitet die Anwendung beispielsweise mehr als 500 Millionen Umsatzabrufe und rund 50 Millionen Überweisungen.

Es geht aber auch längst nicht mehr nur um den Blick aufs Konto.“

Hinzu kommen Anlagefunktionen, Immobilienprozesse, Servicefunktionen und weitere Finanzthemen innerhalb der Anwendung. Der Herausforderung wachsender Komplexität begegnet das Team dabei auf mehreren Ebenen.

Navigation skaliert schlechter als Suche

Viele Anwendungen wachsen über Menüpunkte. In kleinen Anwendungen mit spitzer Zielgruppe funktioniert das leidlich. In einer Banking-App mit Millionen Nutzern, heterogenen Zielgruppen und vielen – auch umfassenden Prozessen wird diese klassische Navigation jedoch schnell zum Engpass.

Die App Sparkasse setzt deshalb auf eine KI-gestützte, text- und sprachbasierte intelligente Suche.“

Inga Hammy, Finanz Informatik
Inga Hammy, Finanz Informatik <q>FIInga Hammy ist Head of Mul­tichan­nel De­sign UI/UX bei der Fi­nanz In­for­ma­tik (Website). Seit mehr als 15 Jah­ren ent­wi­ckelt sie Kon­zep­te für di­gi­ta­le An­wen­dun­gen und Nut­zer­inter­ak­tio­nen. Ih­re Schwer­punk­te lie­gen in den Be­rei­chen User Ex­pe­ri­ence, De­sign­sys­te­me, di­gi­ta­le Bar­rie­re­frei­heit und nutz­er­zen­trier­te Pro­dukt­ent­wick­lung. Im Fo­kus ih­rer Ar­beit ste­hen die Ge­stal­tung und Eva­lua­ti­on kom­ple­xer di­gi­ta­ler Pro­zes­se so­wie die Ent­wick­lung kon­sis­ten­ter Nut­zer­füh­rung über ver­schie­de­ne Ka­nä­le hinweg.
Der technische Kern dahinter ist nicht die bloße Volltextsuche, sondern die Interpretation vielfältiger Nutzerintentionen. Wer „Überweisung“, „Geld senden“ oder „Rechnung bezahlen“ eingibt, meint in der Regel fachlich denselben Prozess. Eine Suche, die nur Schlagworte abgleicht, reicht hier oft nicht aus, um zum Gewünschten zu gelangen.
Für Banking-Anwendungen ist eine solche intelligente Suche mehr als Komfort. Sie wird zur Steuerungsschicht über komplexe Prozesslandschaften und reduziert die Abhängigkeit von tiefen Navigationsbäumen. Zugleich hilft sie, Funktionen auffindbar zu halten, ohne die Oberfläche mit immer mehr Einstiegen zu überladen.

Eine App, aber nicht alle sehen alles

Um die Komplexität einer Anwendung mit 20 Millionen aktiven Nutzenden beherrschbar zu halten, verfolgt die App Sparkasse eine One-App-Strategie. Technisch bedeutet das aber nicht, alle Funktionen für alle Nutzerinnen und Nutzer permanent sichtbar zu machen. Entscheidend ist, Inhalte und Prozesse stärker an Zielgruppe und Situation auszurichten.

Die Themenwelten Immobilien oder Anlegen sind Beispiele dafür, wie sich Funktionen innerhalb einer gemeinsamen Anwendung bündeln lassen, ohne die Oberfläche für alle Nutzer gleich aufzublähen.“

Wer beispielsweise Fragen rund um das Thema Anlegen hat, findet passende Antworten, die anderen nicht angezeigt werden. So existiert die Komplexität im System, wird aber für Nutzerinnen und Nutzer nur in Teilen sichtbar und zwar wenn sie diese Funktionen benötigen.

Accessibility ist kein Randthema der Oberfläche

Mit 20 Millionen Nutzern steigt auch die Heterogenität der Nutzung. Eine Banking-App muss für Jugendliche, langjährige Onlinebanking-Nutzer, Menschen mit wenig digitaler Routine aber auch für Nutzer mit Hilfstechnologien funktionieren. Dazu kommen unterschiedliche Hilfstechnologien: Touch, Screenreader, Tastatursteuerung, Spracheingabe, Braillezeilen oder Joysticks. Damit wird Barrierefreiheit zu einer technischen Qualitätsfrage.

Barrieren entstehen beispielsweise nicht nur, wenn ein Kontrast zu schwach ist.“

Patrick Fritz, Finanz Informatik
Patrick Fritz, Finanz Informatik <q>FIPatrick Fritz ist Ex­per­te Mo­bi­le Ban­king Apps bei der Fi­nanz In­for­ma­tik (Website). Sei­ne be­ruf­li­chen Schwer­punk­te lie­gen in den Be­rei­chen Mo­bi­le Ban­king, di­gi­ta­le Ka­nä­le, Stra­te­gie­ent­wick­lung und Nut­zer­füh­rung in re­gu­lier­ten Fi­nanz­um­ge­bun­gen. Dar­über hin­aus war er vor­her in ver­schie­de­nen Di­gi­ta­li­sie­rungs- und In­no­va­ti­ons­funk­tio­nen in­ner­halb der Spar­kas­sen-Fi­nanz­grup­pe tä­tig. Als Do­zent ver­mit­telt er zu­dem Wis­sen zu Trans­for­ma­ti­on, agi­len Ar­beits­wei­sen und di­gi­ta­len Ge­schäfts­mo­del­len im Finanzsektor.
Sie entstehen auch, wenn Komponenten nicht nach Standards umgesetzt sind und Assistenztechnologien deshalb nicht zuverlässig funktionieren. Sie entstehen etwa, wenn Informationen ausschließlich über Farben transportiert werden, die Menschen mit Rot-Grün-Schwäche ausschließen. Und sie entstehen an Prozessstellen, die formal korrekt wirken, aber praktisch nicht nutzbar sind.
Ein Beispiel: In einem Registrierungsprozess sollte eine Kartennummer eingegeben werden, die ausschließlich auf der physischen Karte sichtbar war. Für blinde Nutzer war der Prozess ohne Hilfe einer weiteren Person oder ohne Scannen der Karte – was die Sicherheitsbemühungen unterlaufen würde – nicht eigenständig durchführbar. Eine formale Prüfung anhand der Web Content Accessibility Guidelines, also der internationalen Richtlinien für digitale Barrierefreiheit, macht eine solche Hürde nicht sichtbar, ein Test mit betroffenen Nutzern jedoch schon.

Komponentenstandards schlagen nachträgliche Korrektur

Bei Anwendungen darf Accessibility nicht am Ende eines Projekts geprüft werden. Dann sind viele Probleme bereits in Komponenten, Prozesslogik oder Bedienmustern verankert. Deshalb gilt es, Anforderungen an digitale Barrierefreiheit direkt in Komponentenstandards zu integrieren.

Das FI-Team etwa prüft bestehende Komponenten und passt diese bei Bedarf an, neue Komponenten hingegen werden von Beginn an barrierefrei konzipiert und entwickelt.“

Designsysteme, ein verbindlicher Styleguide und standardisierte Komponenten sorgen gemeinsam dafür, dass neue Funktionen nicht jedes Mal neue Bedienlogiken erzeugen.

User Journeys sind wichtiger als einzelne Screens

Die Konsequenz: Einzelne Masken können korrekt umgesetzt sein und trotzdem im Prozess scheitern. Kritisch sind vor allen Dingen Übergänge zwischen Funktionen, Webviews, Systemen und Bedienkonzepten. Genau dort entstehen häufig neue Hürden.

Isolierte Oberflächentests reichen deshalb nicht aus. Es braucht Tests entlang vollständiger User Journeys.“

Dazu gehören Screenreader-Tests, Tests mit Tastatursteuerung, Tests mit betroffenen Nutzergruppen (wie beschrieben) und Szenarien unter realistischen Bedingungen. Denn auch situative Einschränkungen zählen dazu. Schließlich kommt Barrierefreiheit allen Nutzergruppen zugute. Wer etwa unterwegs in der Bahn unter Zeitdruck eine Überweisung freigeben möchte, profitiert genauso von klaren Navigationen, konsistenten Abläufen und verständlichen Rückmeldungen. Auch Funktionen wie etwa der Inkognitomodus zeigen, dass Accessibility nicht nur dauerhafte Einschränkungen adressiert. Durch das Ausblenden sensibler Informationen werden visuelle Reize reduziert und die Privatsphäre geschützt. Das erleichtert eine fokussierte und selbstbestimmte Nutzung in ganz unterschiedlichen Alltagssituationen.

Feedback ist Teil der technischen Nutzbarkeit

Bei mobilen Banking-Prozessen beeinflussen auch Ladezeiten und Rückmeldungen die Nutzbarkeit. Deshalb reicht es nicht, dass ein Prozess lediglich fachlich korrekt ausgeführt wird.

Nutzerinnen und Nutzer müssen jederzeit erkennen können, ob ein Prozess läuft, abgeschlossen wurde oder eine Eingabe erforderlich ist.“

Ein rein visuelles Ladezeichen reicht dafür nicht immer aus. Screenreader etwa benötigen gleichwertige Rückmeldungen über entsprechende Accessibility-Mechanismen. Damit wird Feedbackdesign Teil der technischen Qualität.

Fazit: Der eigentliche Test ist Beherrschbarkeit

Die zentrale Frage von Banking-Anwendungen lautet nicht mehr, ob sich weitere Funktionen integrieren lassen. Das ist in der Regel immer möglich.

Entscheidend ist, ob die Anwendung trotz wachsender Funktionstiefe verständlich, konsistent und testbar bleibt.“

Anhand der App Sparkasse, die in unabhängigen Tests, etwa von Handelsblatt und Capital als Seriensieger unterwegs ist und Benchmark für die Branche ist, lässt sich zeigen, welche Themen dabei zusammenlaufen: intelligente Suche, One-App-Strategie, Komponentenstandards, vollständige User Journeys und Accessibility als Bestandteil von Entwicklung und Betrieb.
Komplexität verschwindet nicht. Sie muss technisch so organisiert werden, dass sie nicht beim Kunden beziehungsweise an der Nutzeroberfläche eskaliert. Inga Hammy und Patrick Fritz, Finanz Informatik

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert