Vom Start weg isch d’Arbeit als es mehrjährigs Programm mit klarer Governance konzipiert worde und nöd als e Sammlig vo einzelne Initiativä. De Chund het es Kernteam vo sechs Persone us Betrieb, Digital Product, Engineering und Finance ernannt. Sie hend tägliche Fragä koordiniert, dr Zuegang zu de Statione organisiert und d’lokale Manager ausgrichtet.

Über dem Team het sich e Steuerigskommission vo fünf Führungspersone zu festgelegte Meilensteine troffe. Die Grupp het d’Research-Erkenntnis überprüeft, Entscheidige zur architektonische Usrichtig troffe und Abwägige zwüsche betrieblicher Effizienz, regulatorischer Compliance und langfristiger Technologie-Strategie glöst. Ihre Mitwirkig het sichergstellt, dass Entscheidige zu POS-Flows, Outdoor-Terminals und In-Vehicle-Integration nöd als rein lokale Anpassige behandelt worde sind.

S’Programm isch i klar strukturierte Streams mit definierter Abfolg ufgteilt worde. D’Neugestaltig vo de POS-Workflows het sechs Monet dauert und isch d’Grundlag für d’weitere Schrit gsi. De Stream für d’Outdoor-Zahlterminal het sich über sieben Monet erstreckt und uf de Erkenntnis us de POS-Änderige ufbaut. D’CarPlay-Applikation isch i zwei Monet gestaltet worde, nachdem d’Integrationsannahme überprüeft worde sind. Anderi Aktivitäte wie Journey Mapping, d’Definition vom Mobile-Konzept und d’Konsolidierig vom Design System sind über alli Streams hinweg gloffe.

Die Struktur het vorhersehbare Touchpoints für Reviews gschaffe und em Chund ermöglicht, d’Entwicklungsressource besser z’plane. Si het au drbi gholfe sicherzstelle, dass Entscheidige für en Kanal nöd durch Entscheidige in eme andere Kanal widersproche worde sind. In dr Praxis isch das entscheidend für e Multi-Channel-User-Experience, wo sich steuere laht statt nur notdürftig z’flicke.

S’Programm het mit Feldarbeit a sieben Statione im Raum Züri dur Sandbox Experiments agfange. Innerhalb vo ere Wuche het s’Team 40 Stund strukturieri Beobachtigä gmacht und 532 Transaktione über verschideni Tageszyte und Verkehrsbelastige dokumentiert. S’Ziel isch gsi z’versta, wie d’Arbeit tatsächlich usgführt wird und wo digitali System helfe oder hindre.

D’Forscher hend 36 Kassiererinne und Kassierer im laufende Betrieb beobachtet. Si hend sich druf konzentriert, wie oft s’Personal zwüsche Tank- und Shop-Modus wechslet, wie sie Rabatt- oder Loyalty-Logik navigiere und wo sie sich uf s’Gedächtnis statt uf Bildschirmhinweis verlasse. Die Arbeit isch dur 24 Interviews mit Kassiererinne und Kassierer, Schichtleiter und Lernende ergänzt worde. D’Forschig isch uf Dütsch durgführt worde, was e direkti Kommunikation und e präzisi Erfassig vo fachspezifischer Terminologie ermöglicht het.

D’Transaktione sind nach Typ und Komplexität codiert worde. S’Team het Muster identifiziert, wo s’Personal regelmässig Felder übersprunge het, Date neu iigäh het zum Fehler z’korrigiere oder uf Systemantwortä gwartet het, während d’Schlange länger worde sind. Die Muster hend später als Evidenz für architektonischi Änderige dient.

De Ansatz het Interviews, Kontextbeobachtig und quantitativi Codierig kombiniert. S’Ziel isch nöd gsi, nur Gschichtä z’sammle, sondern es strukturierte Datenset für User Research im Retail-Betrieb z’erarbeite. Das het e fundierte Basis für evidence based UX im Retail gschaffe, wo transparent mit Betrieb und Engineering-Stakeholder het chöne diskutiärt werde.

Mit em komplette Research-Korpus het s’Team Journey-Modell entwickelt, wo sowohl s’Verhalte vo Chunde wie au vom Personal über alli Kanäl hinweg beschriebe. De Fokus isch nöd uf Marketing-Journeys glege, sondern uf betrieblich relevante Abläuf, wo mit em Annähern a d’Station afange und mit em abgeschlossene Zahligsprozess und dr Loyalty-Zuteilig endä.

Für d’Chunde het s’Mapping festghalte, wie Fahrer e Station ussueche, wie sie sich em Forecourt nähere, wie sie e Zapfsäule wähle und wie sie Tanke mit Shop-Chäuf kombiniere. Für s’Personal het s’Mapping dokumentiert, wie sie mit Schlangäbildig, Mischtransaktione, Usnahme wie abglehnte Karte und em Schichtabschluss umgah.

Jede Journey isch i klar abgrenzti Schrit mit de zugehörige Trigger, Systemzueschtänd und Umweltbedingige unterteilt worde. So het s’Team chöne gseh, wo d’Logik vo de digitale System vo dr Logik vo dr Arbeit abwiicht. Zum Bispil hend gwüssi Abläuf erfordert, dass Kassiererinne und Kassierer bi Transaktionstypä, wo unter Spitzebelastig häufig vorkömed, mehrmals zwüsche Bildschirme wechsled.

D’Modell hend au d’Übergäng zwüsche de Kanäl beschriebe. E Fahrer chann über d’In-Vehicle-Navigation aacho, sich am Outdoor-Terminal autorisiere und denn in Shop ine gah, um e kombinierte Chauf abzschliesse. S’Personal het über alli die Schrit hinweg konsistenti Information brucht. Mit dr klare Definition vo dene Strukture het s’Team d’Grundlag für s’Redesign vom POS-System vorbereitet und sicherstellt, dass Änderige i eim Kanal kei neui Inkonsistenze i eme andere verursache.

De POS-Stream het sich uf d’Kassasystem konzentriert, wil die d’höchsti betriebliche Belastig hend. Uf Basis vo de Journey-Modell het s’Team d’Transaktionstypä katalogisiert und nach Häufigkeit und Komplexität gruppiert. Das het separate Pfad für nur Tanke, kombiniert Tanke und Shop, Gutschein-Einlösige, Loyalty-Vorgäng und Usnahmebehandlig beinhaltet.

Sechzehn alternative POS-Architekture sind mit option space mapping modelliert worde. Jede Option het neu organisiert, wie Aktione gruppiert sind und wie Information im Bezug uf d’Ablauf vo Aufgabe präsentiert werde. S’Ziel isch gsi, unnötigi Navigation z’verringere, Moduswechsel z’limitiere und d’Fehlerbehandlig konsistenter z’mache. S’Team het jede Option mit em beobachtete Datenset vo 532 Transaktione vergliche, um z’seh, wie oft e bestimmti Struktur d’häufige Pfad berührt.

Sechs Konzäpt sind für Prototyping usgwählt worde. Die Prototypä sind uf Wireframe-Ebene umgsetzt worde, uf Bildschirme, wo s’Layout vo 1920 x 1080 Pixel vo de echte Kassasystem widerspiegelt hend. Neunundzwänzg Test-Sessions über verschiedeni Streams hend e strukturierte Evaluation vo dene Prototypä mit Kassiererinne, Kassierer und Supervisor beinhaltet. S’Feedback het sich uf Gschwindigkeit, d’Klarheit vo de Aufgabenreihenfolg und d’Übereinstimmig mit de Abrechnigsroutine konzentriert.

D’resultierend Lösig het nöd uf Neuheit gsetzt. Si het d’Abläuf so neu organisiert, dass häufigi Vorgäng mit weniger Schrit und weniger mentale Übergäng erledigt werde chönd, während d’Beschränkige vo de bestehende Hardware dur constraint respecting berücksichtigt worde sind. Genau da zeigt sich, wo Point of Sale UX für Retail Operations UX am wichtigste isch – und nöd bi isolierte Interface-Spielerei.

D’Testarbeit het mehri konkrete Erkenntnis gliferet, wo erklärt hend, warum früehere Konfiguratione unter Spitzebelastig Müeh gha hend. Kassiererinne und Kassierer hend persönlichi Abchürzige entwickelt, um Layout-Probleme z’kompensiere. Die Abchürzige hend für erfahrens Personal funktioniert, hend aber d’Iarbeitig vo neue Mitarbeitende erschwert. Beobachteti Fehlerkorrektur-Abläuf hend zeigt, dass chliini Inkonsistenze i de Feldreihenfolg bi lange Schlangä unverhältnismässig grossi Verzögerige verursacht hend.

Während de Tests hend Kassiererinne und Kassierer positiv reagiert, wenn d’Abläuf dr interne Logik vo ihrer Arbeit gfolgt sind statt dr Struktur vo de Legacy-Software. Si hend Verbesserige betont, wo s’System dem entsproche het, wie sie s’Zämmefüehre vo Tanke, Shop-Artiklä und Loyalty-Aktione denke. Supervisor hend hervorghebt, dass besser vorhersagbare Abläuf i hektische Zyte d’Kontrolle erleichtere, wil weniger Spezialfäll Interventione erfordere.

S’Team het das Feedback gnutzt, um d’final Architektur mit tension-driven reasoning wyter z’verfeinere. Anpassige sind bi dr Gruppierig vo Aktione, dr Platzierig vo wichtige Informatione und dr Behandlig vo seltene Usnahme, wo bi falscher Handhabig hohe betriebliche Chöste verursache, gmacht worde. Die Entscheidige sind so dokumentiert worde, dass sie mit Engineering i präzise Begriff chönd diskutiärt werde.

Dur dä Prozess het s’POS-Redesign es verlässlechs Modell für Kassiererinne und Kassierer etabliert und e Referenz für verwandti Kanäl gschaffe. Es het au dr Steuerigskommission vom Chund konkret zeigt, wie strukturieri Entscheid us Feld-Evidenz i System-Änderige uf Ebene vo Retail Operations UX übergöh chönd.

Über beidi, d’Indoor-Kasse und d’Outdoor-Terminal, het s’Projekt innerhalb vo de Grenze vo de bestehende Hardware müesse schaffe. De Chund het kei Geräte ersetzt, drum het d’Designarbeit nöd uf Upgrades wie grössere Bildschirme oder schnälleri Prozessor chöne abstütze. Das het Embedded-System-UX zu ere explizite Frag gmacht und nöd nume zu ere Randnotiz.

D’Bildschirm-Uflösige vo 1920 x 1080 Pixel für d’Kasse und 1024 x 768 Pixel für d’Outdoor-Gerät sind als fixi Parameter behandelt worde. S’Team het d’typische Antwortzyte für Kernoperatione gmesse und spezifischi Abläuf entdeckt, wo System-Latenz s’Interaktionsverhalte beeinflusst het. Zum Bispil hend Verzögerige zwüsche Autorisierig und Bestätigig dazu gführt, dass Kassiererinne und Kassierer Workarounds gstartet hend, wo d’Schulig und d’Dokumentation komplizierter gmacht hend.

D’Design-Entscheid hend druf abzielt, d’Abhängigkeit vo Abläuf z’minimiere, wo empfindlich uf Latenz reagiere. Wo Bildschirme meh umfangriichi Information bruucht hend, het d’Struktur d’Klarheit vor d’Dichti gstellt. Für Embedded-Hardware isch das kei ästhetischi Vorliebe, sondern e Wäg, um unter Belastig nöd d’praktische Interaktionsgrenze z’überschriite.

Die Überlegige sind für d’Engineering-Teams dokumentiert worde, damit si nachvollzieh chönd, warum gwüssi Layouts oder Interaktionsmuster empfohle worde sind. S’Ziel isch gsi sicherzstelle, dass bi dr Umsetzig kei Muster wider iigführt werded, wo in dr Theorie effizient wirke, aber unter reale Betriebsbedingige Problem verursache.

Mit em Fortschritt vo de Streams het s’Team d’Muster i es einzigs Design System zämmegefasst, wo Kasse, Outdoor-Terminals, CarPlay und s’Mobile-Konzept abdeckt. S’System het Komponente-Definitione, Interaktionsregle und Nutzigs-Hinwiis enthalten, strukturiert nach Kanal und nach gmeinsame Muster. S’Ziel isch gsi, sowohl d’aktuell Umsetzig wie au d’zukünftig Wyterentwicklig z’unterstütze.

D’Dokumentation het klar gmacht, weli Element über alli Gerät hinweg gmeinsam sind und weli spezifisch für e bestimmti Plattform. Zum Bispil sind Button-Zueschtänd, grundlegend Typografie-Entscheid und gwüssi Muster vo dr Date-Darstellig konsistent blibe. Anderi Aspekt wie Layout-Grids und Interaktionsmodell hend sich an d’Einschränkige vo jeder Gerätekategorie und am jeweilige Nutzungskontext agpasst.

D’Entwickler hend Assets becho, wo zu ihrer bestehende Toolchain passt hend. S’Design-Team het a de regelmässige Implementierungs-Sitzige teilgnoh, um Verhalte z’kläre und Froge zu Edge Cases während Implementation Partnership z’beantworte. Das het s’Risiko reduziert, dass s’beabsichtigte und s’tatsächliche Verhalte vo einander abwiche, bsunders bi Fehlerbehandlig und Zuestandsübergäng.

S’Design System lässt sich am beste als es Design System für Retail-Applikatione beschriibe, wo über Embedded-Terminals und vernetzte Umgebige hinweg müesse funktioniere. S’Ziel isch nöd nume visuelles Branding, sondern wiederholbari Entscheidigsgrundlage, wo Produkt- und Engineering-Teams bi dr Wyterentwicklig oder Anpassig vom Ökosystem anwände chönd.

D’CarPlay-Applikation het e andere Teil vo dr Journey abdeckt. Si het d’Suche nach nööchlige Statione, d’Navigation zum Forecourt und d’Identifikation vo dr richtige Zapfsäule nach dr Aafahrt unterstütze müesse. Glichzytig het si d’Plattform-Regle zur Reduzierig vo Fahrerablenkig sowie d’lokaale Vorschrifte für s’Tanke müesse iihalte.

S’Team het Nutzigsszenarie definiert, wo Fahrer sich ere Station nähere, beim Iifahre in d’Forecourt Hinweis erhalte und d’Zapfsäule bestätige, bi dä si aahalte. D’Interaktionsabläuf sind kurz ghalte worde. Wo’s möglich gsi isch, het s’Design uf Sprachaktione und eifachi Bestätigige statt uf längeri Menü-Navigation gsetzt. Das widerspiegelt d’Disziplin, wo für Automotive UX Design nötig isch, und nöd Konsumente-Mobile-Muster.

D’Integrationsarbeit het sich uf e konsistenti Identifikation vo de Zapfsäule und uf e sichere Autorisierig konzentriert. D’Applikation het mit em bestehende Back End müesse kommuniziere, damit dr Status vo dr Zapfsäule und dr Zahligszueschtand mit dr Realität uf em Forecourt übereinstimmt. Testsessions mit Fahrer hend untersucht, wie klar d’App die Zueschtänd vermittelt und wie guet d’Logik de Erwartige entsprochen het.

D’resultierend Struktur het d’Basis für d’CarPlay-App-UX für dä Chund bildet. Si het sich im Prinzip an de Flows vo de Outdoor-Terminals und de Kasse orientiert, während si d’strengere Einschränkige vo In-Vehicle-Interfaces berücksichtigt het. Dä Kanal het denn anderi Teil vom Ökosystem beeinflusst, wenn Fahrer d’Station über s’Fahrzüg statt über unabhängigi Navigations-Tools aagfahre hend.