Problemstellung

Der initiale Auftrag bestand darin, die bestehende digitale Retaillösung für Endnutzer durch eine zeitgemäße App zu ersetzen, die nicht nur visuell einen deutlichen Schritt nach vorne macht. Die Neuentwicklung sollte vollständig eigenständig betrieben werden, um die Abhängigkeit von externen Dienstleistern zu reduzieren, die Datensicherheit der eigenen Kundendaten sicherzustellen und eine belastbare Grundlage für zukünftige Erweiterungen zu schaffen. Diese Emanzipation ging mit der Modernisierung zentraler Teile der IT-Landschaft einher.

Auch die User Experience, die bislang als wenig überzeugend wahrgenommen wurde, sollte grundlegend überarbeitet werden. Ziel war eine moderne Retail-App, die sich mit einer soliden, zukunftsfähigen Architektur im Markt behaupten kann, neue Kund:innen gewinnt und sich als zentrales Instrument der digitalen Kundenbindung für famila und Markant etabliert. Schnell wurde klar: Dafür braucht es eine saubere Ausgangsbasis. Das Team startete daher bei Null und brachte seine volle technische und gestalterische Expertise in die Neuentwicklung ein.

Fachlich getriebene Lösungsfindung

Domain-Driven Design (DDD) ist ein Ansatz zur modellbasierten Softwareentwicklung, der sich besonders bei komplexen Geschäftsanwendungen bewährt. Im Kern steht die enge Zusammenarbeit von Fachbereich und IT, um Domänen, Prozesse und Begriffe gemeinsam zu schärfen und belastbar abzubilden. So werden fachliche Szenarien systematisch in konkrete Use Cases übersetzt, die sowohl Nutzerinteraktionen als auch Integrationen mit angebundenen Fachsystemen beschreiben.

Im Projekt dienten diese Use Cases als gemeinsame Arbeitsgrundlage für Design und Entwicklung. Sie machten Anforderungen früh greifbar, halfen bei der Priorisierung des MVP und ermöglichten es, Geschäftslogik in klaren, verständlichen Szenarien zu formulieren. Methoden wie eine „Ubiquitous Language“ als gemeinsame Begriffswelt und die Aufteilung in „Bounded Contexts“ unterstützten dabei, Komplexität zu strukturieren, Verantwortlichkeiten zu trennen und Entscheidungen nachvollziehbar zu machen.

Die im DDD-Prozess entstehenden Use Cases sind damit nicht nur Spezifikation für die Umsetzung, sondern ein verbindendes Kommunikationsmittel zwischen Fachbereichen, Design und Engineering. Sie reduzieren Missverständnisse, schaffen Alignment über Teams hinweg und stellen sicher, dass die Lösung reale fachliche Anforderungen zuverlässig abbildet.

Reale Nutzungserfahrungen als Grundlage

Nahezu jede große Supermarktkette bietet heute eine App an, die den Einkauf einfacher, schneller und zugänglicher macht. Für viele Menschen ist das Einkaufen mit digitalen Helfern längst Teil des Alltags. Diese realen Nutzungserfahrungen bildeten eine wichtige Grundlage für unseren UX-Prozess.

Trotz unterschiedlicher Gewohnheiten im Team zeigten sich klare Muster im Umgang mit Retail-Apps – vor, während und nach dem Einkauf. Aufbauend auf diesen Beobachtungen und den definierten Use Cases wurden detaillierte User Flows definiert, die die Use Cases aus Nutzersicht repräsentieren. Sie dienten als Basis für Wireframes und das gesamte Interaktionskonzept.

Interaktionskonzept

Auf Basis eines initialen Market Research identifizierten wir etablierte, vertraute Bedienmuster, an die wir bewusst anknüpfen wollten. Das Design-Team setzte deshalb auf eine zentrale Main Navigation Bar, über die die wichtigsten Funktionen jederzeit erreichbar sind. Der Checkout wurde dabei klar als wichtigste Interaktion definiert – schließlich wird hier der zentrale Mehrwert der App im Alltag eingelöst. Entsprechend ist diese Funktion im Interface am prominentesten platziert.

Die einzigen Elemente, die Main Navigation und Checkout-Button überlagern, sind Modale, die Nutzer gezielt zu einer Interaktion auffordern. Dieses Muster bindet Aufmerksamkeit dort, wo sie benötigt wird, ohne die Orientierung im restlichen Interface zu verlieren. Unterstützt wird das Konzept durch das Abdunkeln der Hintergrundinhalte sowie einen subtilen Tiefeneffekt, bei dem sich der Hintergrund leicht zurücknimmt und so den Fokus auf das Modal verstärkt. In Kombination mit präzise eingesetzten Mikroanimationen entsteht ein eigenständiges Bediengefühl, das sich angenehm von vielen Retail-Apps abhebt – und Nutzer*innen hilft, auch in dynamischen Situationen den Fokus zu behalten.

Eine gemeinsame visuelle Sprache für zwei Marken

Parallel zum UX-Prozess entwickelten wir in enger Zusammenarbeit mit dem Marketing-Team von Bartels-Langness eine visuelle Sprache, die für famila und Markant gleichermaßen funktioniert und beide Marken in einem konsistenten digitalen Erlebnis zusammenführt. Differenzierungen wurden bewusst subtil gehalten – etwa in der Farbpalette, bei Primärfarben oder Eckenradien. So konnten wir die jeweiligen Brand Guidelines konsequent einhalten, ohne Kompromisse bei der Gestaltung eines modernen digitalen Produkts einzugehen.

Um Konsistenz im Design und eine reibungslose Übergabe in die Entwicklung sicherzustellen, entstand ein umfassendes Design System, inklusive UI-Komponenten, visueller Assets beider Brands und klarer Richtlinien zur korrekten Verwendung. Dazu gehören auch nahbar gestaltete Illustrationen, die Inhalte unterstützen und zugleich zentrale Abläufe und Interaktionsmomente verständlich kommunizieren.

Ergänzt wurde das System durch ein mehrstufiges Design-Token-Konzept, das schnelle und skalierbare Anpassungen ermöglicht. Sowohl für das Theming als auch für plattformübergreifende Updates. Damit wurde das Design System zur Single Source of Truth und zugleich zu einem zentralen Beschleuniger für Umsetzung, Qualitätssicherung und zukünftige Weiterentwicklung.

Um das Token-Setup fehlerfrei und effizient in die technische Realisierung zu übernehmen, wurden Plugins für Figma und Nx Workspace entwickelt, mit deren Hilfe die Figma-Variablen automatisiert in Code und Ressourcen transformiert werden.

Schnelles Feedback und nahtlose Integration durch kontinuierliches Testing

Von Beginn an setzten wir auf kontinuierliches Testing, um die Qualität in jeder Projektphase abzusichern. In der ersten Phase nutzten wir Figma-Prototypen und frühe Entwicklungsstände und unterzogen sie regelmäßigen UX- und UI-Reviews. So entstanden kurze Feedback-Schleifen, die Entscheidungen früh validierten und Risiken im weiteren Verlauf reduzierten. Dieser iterative Prozess war ein wesentlicher Faktor dafür, dass wir bereits zum MVP-Milestone ein hochwertiges, belastbares Produkt ausliefern konnten.

In der zweiten Projektphase folgte ein Hands-on-Testing mit einer fortgeschrittenen App-Version auf Teststages – im Zusammenspiel mit simulierten Kassensystemen inklusive Handscannern von famila und Markant. Die Tests liefen strikt nach einem standardisierten Testframework: gut dokumentiert, reproduzierbar und an eine vollständig definierte Customer Journey angelehnt, gegliedert in vor, während und nach dem Einkauf. So konnten wir die Integration in bestehende Systeme vor Ort gezielt absichern und eine nahtlose Nutzererfahrung sowie vollständige Betriebskompatibilität im Markt gewährleisten. Gleichzeitig ermöglichten kurze Release-Zyklen, Fehler früh zu identifizieren und konsequent zu beheben.

Kurz nach dem Release wurde zudem ein erster Test mit einer erweiterten Nutzergruppe von rund 200 Personen durchgeführt. Das Feedback wurde systematisch gesammelt, ausgewertet und in konkrete Optimierungen des Working Product überführt.

Technisches Lösungsdesign

Die neue App-Generation für famila und Markant sollte nicht nur funktional überzeugen, sondern vor allem als technisches Fundament für einen eigenständig betriebenen, langfristig erweiterbaren Produktkosmos dienen. Entsprechend lag der Fokus auf einer Architektur, die Unabhängigkeit ermöglicht, Integrationen zuverlässig beherrscht und zukünftige Feature-Ausbaustufen strukturell vorbereitet.

Unser technischer Ansatz folgte dabei klaren Leitplanken: use-case-zentrierte Entwicklung, ein konsequent domain-getriebener Blick auf Fachlichkeit und Daten sowie ein agiles Vorgehen zur frühen Validierung von Entscheidungen.

Serverseitige Architektur: Microservices, CQRS und Clean Architecture

Microservices

Wir haben uns bewusst für den Einsatz von Microservices in Kombination mit Domain-Driven Design entschieden, da diese Architektur die notwendige Modularität, Flexibilität und Skalierbarkeit für unsere Anforderungen bietet. Insbesondere in komplexen und dynamisch wachsenden Geschäftsanwendungen ermöglicht sie eine klare fachliche und technische Trennung der Verantwortlichkeiten. Diese bewusste Aufteilung erlaubt es uns, einzelne Domänen unabhängig weiterzuentwickeln, gezielt zu skalieren und robust zu betreiben. Gleichzeitig fördert der Microservice-Ansatz eine enge und effektive Zusammenarbeit zwischen Entwicklung und Betrieb und stärkt die Agilität sowie die Resilienz des Gesamtsystems.

CQRS (Command Query Responsibility Segregation)

Der Einsatz von CQRS ist eine gezielte Entscheidung, um die Komplexität fachlicher Prozesse beherrschbar zu halten und eine klare Trennung zwischen schreibenden und lesenden Zugriffen zu etablieren. Im DDD-Kontext erlaubt uns CQRS, Änderungen am Systemzustand strikt an der Fachlogik auszurichten, während Lesezugriffe unabhängig davon optimiert werden können. Dadurch schaffen wir eine Architektur, in der sich die Teams bewusst auf die korrekte Umsetzung der Domain-Logik konzentrieren können, ohne Abstriche bei Performance, Verständlichkeit oder Wartbarkeit der Abfragemodelle machen zu müssen.

Clean Architecture

Wir setzen Clean Architecture gezielt ein, um eine langfristig wartbare, erweiterbare und technologisch unabhängige Systemstruktur sicherzustellen. Die klare Trennung von Geschäftslogik und technischen Belangen ist für uns ein zentraler Entscheidungsfaktor, da sie es ermöglicht, fachliche Anforderungen unabhängig von Infrastruktur- oder Framework-Entscheidungen umzusetzen.

Im Zusammenspiel mit DDD nutzen wir Clean Architecture bewusst, um Bounded Contexts klar zu schneiden und sauber zu isolieren. Innerhalb jedes Bounded Contexts stellen wir sicher, dass die Domänenlogik im Zentrum steht und nicht von Persistenz, APIs oder UI-Aspekten abhängig ist. Diese Architekturentscheidung unterstützt uns dabei, fachliche Modelle stabil zu halten und gleichzeitig technische Details flexibel austauschen oder weiterentwickeln zu können.

Clientseitige Architektur: Model View Presenter und CQS

Für die clientseitige Umsetzung wurde ein Ansatz gewählt, der schnelle Weiterentwicklung, einen konsistenten Markenauftritt und den Zugang zu nativen Funktionen effizient miteinander verbindet. Auf Basis der Abwägung von PWA-, nativen und hybriden Optionen fiel die Entscheidung zugunsten einer hybriden Lösung, um mit einer gemeinsamen Codebasis plattformübergreifend zu liefern und zugleich die App-Store-Distribution sowie native APIs zuverlässig zu nutzen.

Die von uns als clientseitiges Architekturmuster gewählte Kombination von Model-View-Presenter (MVP) und Command Query Separation (CQS) stellt im Kontext von Domain-Driven Design (DDD) eine starke Grundlage für die Gestaltung von benutzerfreundlichen und wartbaren Anwendungen dar. Beide Konzepte bieten eine klare Trennung von Verantwortlichkeiten und verbessern sowohl die Lesbarkeit als auch die Wartbarkeit von Software, insbesondere in komplexen und sich häufig verändernden Geschäftsdomänen.

Technologisch wurde dafür ein moderner Frontend-Stack mit React, TypeScript, SCSS sowie einem strukturierten Workspace-Ansatz in einem Monorepo aufgebaut. Für State-Management kommen etablierte Patterns und Zustand als State-Machine zum Einsatz. Die Integration nativer APIs und das Bundling wurde mittels Capacitor realisiert. Damit entstand ein clientseitiges Fundament, das sowohl für die markenspezifischen Themes als auch für zukünftige Feature-Module sauber skalieren kann.

Fazit und Ausblick

Der Release des Produkts in seiner aktuellen Version bildet einen soliden Grundstein für die weitere Zusammenarbeit mit Bela-IT und Bela-Marketing. Auch nach Abschluss der ersten Projektphase bleiben wir ein zentraler Partner von Bartels-Langness.

Wir unterstützen insbesondere in der Weiterentwicklung des Produkts und der Strategie, orientiert an der unternehmerischen Vision, die wir gemeinsam mit dem Kunden definiert haben und kontinuierlich weiter schärfen.

Mit Blick auf die fortlaufenden Veränderungen der Systemlandschaft und die Dynamik beim Übergang in einen selbstverwalteten Betrieb begleiten wir das Anforderungsmanagement beratend. So stellen wir sicher, dass Erweiterungen, Integrationen und Betriebsschritte möglichst reibungsfrei umgesetzt werden können.

Nächstes Projekt