UI vs. UX richtig aufsetzen: Von User Story Mapping bis zum pixelperfekten Prototyp – Erkenntnisse aus „UI/UX“ mit Philipp Baldauf (Ahoi Kapptn!)

Warum dieser Talk für Entwicklerinnen und Entwickler relevant ist

In der Session „UI/UX“ von Philipp Baldauf (Ahoi Kapptn!) stand ein Thema im Fokus, das in Softwareprojekten oft unterschätzt wird: Wie UI- und UX-Design von Beginn an den gesamten Produktzyklus bestimmen – von der ersten Idee über Planung und Umsetzung bis zum Launch. Für Engineering-Teams ist das kein „nice to have“, sondern ein Produktivitätsfaktor: Ein klarer UI/UX-Plan reduziert Reibung, beschleunigt Sprints und macht Ergebnisqualität messbar sichtbar.

Baldauf bringt viel mobile Entwicklungserfahrung mit und arbeitet in seiner Agentur Ahoi Kapptn! entlang eines durchgehenden Prozesses: Konzept, Design, Implementierung und Launch. Sein Kernargument: Gute UI/UX-Entscheidungen früh treffen – und sie konsequent durch die Entwicklung tragen. Wir fassen die wichtigsten Punkte aus dem Talk zusammen und leiten daraus konkrete Schritte für Tech-Teams ab.

UI vs. UX: Die saubere Trennung als Grundlage

Gleich zu Beginn räumt Baldauf mit einer häufigen Verwechslung auf. Er betont, dass UI und UX zwar eng verzahnt sind, aber unterschiedliche Aufgaben erfüllen:

Diese Trennung ist nicht akademisch – sie ist für Planung, Verantwortlichkeiten und Akzeptanzkriterien entscheidend. Aus Engineering-Sicht bedeutet das:

• UI definiert die sichtbaren Bausteine (Layouts, Komponenten, Abstände, Typografie, Farben, Interaktionsflächen).
• UX legt fest, wie sich das System anfühlt (Flow, Zustände, Rückmeldungen, Animationen, Fehler- und Leerlaufzustände, Kontrollgefühl).

Baldaufs zentrale Empfehlung: UI und UX gehören von Anfang an in die Produktdefinition, nicht als spätere Veredelung. Genau hier setzt sein Prozess an.

Start mit User Story Mapping: Funktion, Flows und Releases klarziehen

Bei Ahoi Kapptn! beginnt jedes Projekt mit einem User Story Mapping Workshop. Ziel: „Was soll die App am Ende des Tages können? Wie interagieren Nutzerinnen und Nutzer?“ Aus technischer Sicht bringt dieser Schritt eine klare Struktur:

• User Stories und Flows werden explizit gemacht – Interaktionen, Zustände, Übergänge.
• Der Gesamtumfang wird sichtbar – inklusive aller anfänglichen Feature-Wünsche.
• Der Umfang wird in Releases geschnitten – MVP, Version 1, Version 2, Version 3.

Dieses Slicing ist mehr als Roadmapping: Es sorgt dafür, dass das Team eine „gute Gesamtexperience“ in jeder Ausbaustufe sicherstellt. Für Engineering bedeutet das realistische Sprintplanung, früh testbare Inkremente und weniger Rework.

Warum sich dieser Schritt lohnt

• Gemeinsames Verständnis: Stakeholder, Design und Engineering sprechen früh dieselbe Sprache.
• Vereinbarte Priorisierung: MVP ist nicht die Billigversion, sondern die kleinste wertstiftende Experience.
• Technische Anschlussfähigkeit: Backlog und Architektur können auf reale Flows statt abstrakte Ideen zugeschnitten werden.

Design als Bauplan: Erst UI/UX, dann Code

Baldauf nutzt eine treffende Analogie: Wie beim Hausbau kommt vor dem ersten Ziegel der Bauplan. In der Praxis heißt das: Ahoi Kapptn! liefert die UI/UX-Designkomponente zuerst – als detailliertes Mockup in Tools wie Figma oder Sketch.

Warum das für Entwicklerinnen und Entwickler wichtig ist:

• Fehler werden früh sichtbar, wenn Änderungen noch billig sind.
• Kundenseite kann Erwartungen justieren („Ich habe mir das anders vorgestellt“) – ohne Code umzuschreiben.
• Das Mockup ist ein gemeinsamer Touchpoint – alle sehen dasselbe Zielbild.
• Designer können Interaktionen/Animationen spezifizieren; die Umsetzung wird konkret und überprüfbar.

Kurz: Ein gutes Mockup ist kein „nice visual“, sondern ein funktionaler Spezifikationsersatz, der Kontext, Verhalten und Details transportiert.

Umsetzung im Scrum-Prozess: Zweiwöchentliche Sprints mit voller Transparenz

Die Implementierung erfolgt in zweiwöchigen Sprints. Aufgaben (Tickets) werden über Fachbereiche koordiniert, Kundinnen und Kunden sind aktiv eingebunden – inklusive direkter Kommunikation mit Entwicklerinnen und Entwicklern in Sprint-Meetings und via Planungstools.

Aus Engineering-Perspektive schafft das:

• Klarheit über Akzeptanzkriterien (Mockup + Story definieren „done“).
• Schnelle Feedbackschleifen (kundenseitige Entscheidungen landen rechtzeitig im Sprint).
• Sichtbare Fortschritte (Prototyp/Mockup als Referenz für Demos).

Diese Transparenz ist nicht nur Kundenservice, sie reduziert auch das Risiko von Überraschungen am Ende eines Sprints.

UI-Mockups als verbindliche Referenz: Präzision statt Annahmen

Baldauf zeigt als Beispiel eine Anfangsversion der Rotax-Maxdome-App. Wichtiger als der konkrete Use Case ist der Mechanismus: Ein UI-Mockup gibt Entwicklern und Kundinnen eine „sehr genaue Vorstellung“, wie die App aussehen muss. Moderne Design-Tools liefern dafür die entscheidenden Merkmale:

• Pixelgenaue Spezifikation: Abstände, Größen, Ausrichtung – bis hin zu Details wie „vier Pixel Abstand“.
• Exportfunktionen: Designer können Code direkt aus dem Tool exportieren (wo passend) – lästiges Nachbauen von UI-Strukturen reduziert sich.
• Asset-Download: Grafiken/Icons sind zentral abrufbar – keine Schleifen über das Design-Team erforderlich.

Das Ergebnis: „Pixelperfekte UI“ wird zur realistischen Erwartung, nicht zur Hoffnung. Gleichzeitig schlägt das Tool eine Brücke – auch wenn nicht jede Entwicklerin das „größte Designer-Auge“ hat, sind Anforderungen klar ablesbar.

Human Interface Guidelines: Konsistenz, Direktheit, Kontrolle

Baldauf verweist auf die Human Interface Guidelines (Apple) und nennt zentrale Prinzipien, die für iOS gelten – analog gibt es Richtlinien bei Google. Seine Kurzfassung der iOS-Leitlinien ist ein kompaktes Pflichtenheft für UI/UX-Entscheidungen:

• Ästhetische Integrität: Die Funktionalität der App muss sinnvoll in der Oberfläche gespiegelt werden.
• Konsistenz: Nicht nur innerhalb der eigenen App – auch im Kontext des Betriebssystems.
• Direkte Manipulation: Nutzerinnen sollen Inhalte unmittelbar verändern können (z. B. Gesten wie Drehen in Foto-Apps).
• Direktes Feedback: Aktionen müssen spürbar beantwortet werden.
• Sinnvolle Metaphern: Vertraute Konzepte aus realer oder digitaler Welt helfen beim Verständnis.
• Kontrolle: Nutzerinnen müssen jederzeit die Kontrolle behalten – und sich auch so fühlen.

Für Engineering bedeutet das: Diese Prinzipien werden zu nicht verhandelbaren Design Constraints. Wer sie zu Beginn verankert, spart später Zeit bei Code-Kommentierung, QA-Diskussionen und Rework.

Accessibility von Anfang an: Mehr als Screen Reader

Baldauf widmet dem Thema Barrierefreiheit einen eigenen Abschnitt – mit einem wichtigen Hinweis: Accessibility darf im UI/UX-Prozess nicht zu kurz kommen. Dabei geht es nicht nur um die Unterstützung der Screen Reader der Betriebssysteme. Wesentlich früher wirksam sind:

• Skalierbare Schriftgrößen: Unterschiedliche Skalierungsfaktoren müssen im Design einkalkuliert werden.
• Farbkombinationen mit ausreichendem Kontrast: Mit Plugins wie Stark lässt sich ein Kontrastscore berechnen – so erkennt man bereits im Design, ob Farbkombinationen problematisch sind.
• Farbschemata, die typische Sehschwächen berücksichtigen: Ahoi Kapptn! stimmt Paletten z. B. auf Rot-Grün-Schwäche ab.

Diese Punkte sind konkret, überprüfbar und im Mockup implementierbar. Für Entwicklerinnen und Entwickler sind sie zugleich Leitplanken: Schriftgrößen nicht fix verdrahten, Komponenten responsiv bauen, Kontraste beibehalten, visuelles Feedback nicht ausschließlich farblich codieren.

Wie der Prototyp Brücken baut: Kundenerlebnis und Umsetzungshilfe

Der UX-Prototyp ist für Baldauf ein Kernelement – „aus zweierlei Hinsicht“:

1) Früher Touchpoint für Kundinnen und Kunden: Bevor Code entsteht, lässt sich das „Anfühlen“ der App erleben. Erwartungsmanagement wird greifbar.

2) Exakte Übergabe vom Design an die Entwicklung: Designer können festhalten, wie Animationen gedacht sind, wie Zustände wechseln, wie Feedback aussieht – und das Engineering kann es konkret umsetzen.

In der Praxis entstehen dadurch weniger Diskussionen über Interpretationen – die Interaktion ist erlebbar, nicht nur beschrieben.

Engineering-Checkliste: So setzt ihr Baldaufs Prozess um

Aus der Session „UI/UX“ von Philipp Baldauf (Ahoi Kapptn!) lässt sich eine klare To-do-Liste ableiten, die Engineering- und Produktteams direkt anwenden können:

1) User Story Mapping früh ansetzen

• Nutzerziele, Flows und Interaktionen end-to-end visualisieren.
• Umfang sichtbar machen – ohne zu früh zu designen oder zu bauen.

2) Releases bewusst schneiden

• MVP definieren, das eine vollständige Experience liefert.
• Weiterentwicklungen als Version 1/2/3 mit klaren Schwerpunkten planen.

3) UI/UX-Design vor der Implementierung liefern

• Figma oder Sketch als State-of-the-Art-Tool verwenden.
• Designänderungen mit Kundenseite in der Mockup-Phase klären.

4) Prototypen als Spezifikation nutzen

• Flows, Zustände, Animationen im Prototyp erfahrbar machen.
• Prototyp als Referenz für Sprint-Demos und QA verwenden.

5) Human Interface Guidelines einhalten

• Konsistenz und Bedienmuster der Plattform beachten.
• Direkte Manipulation, Feedback und Kontrollgefühl standardmäßig umsetzen.

6) Accessibility im Design verankern

• Schriftgrößen skalierbar auslegen, Kontraste mit Stark prüfen.
• Farbschemata bereits im Mockup auf Sehschwächen testen.

7) Pixelperfektion praktikabel machen

• Abstände, Größen und Typo aus dem Design exakt übernehmen.
• Code- und Asset-Export aus dem Design-Tool nutzen, wo sinnvoll.

8) Scrum mit Kundentransparenz leben

• Zweiwöchige Sprints, klare Tickets, regelmäßige Sprint-Meetings.
• Direkte Kommunikation zwischen Engineering und Kundenseite fördern.

Details, die in der Umsetzung den Unterschied machen

Baldauf nennt einige konkrete Praxishebel, die gerade in Engineering-Teams Wirkung zeigen:

• Messbare UI-Details: Ein „vier Pixel Abstand“ ist kein Detail, sondern Teil der Experience – Tools machen es ablesbar und überprüfbar.
• Asset-Management im Tool statt E-Mail-Pingpong: Weniger Schleifen mit dem Design-Team spart Zeit und Kontextwechsel.
• Code-Export gezielt einsetzen: Wo Strukturen wiederkehrend sind, hilft der Export, Boilerplate zu vermeiden und Konsistenz zu erhöhen.
• Design als Kommunikationsmittel für Motion: Animationen, Statuswechsel und Feedback sind Teil der Spezifikation – nicht Post-Processing in der App.

Diese Punkte reduzieren Reibung in Sprints und senken das Risiko von „Interpretationslücken“ zwischen Design und Entwicklung.

Qualitätssicherung entlang des Mockups: Was „done“ bedeutet

Ein wiederkehrendes Thema im Talk ist die Klarheit über Erwartungen. Das Mockup übernimmt dabei eine QA-Funktion:

• „Done“ heißt, dass das Ergebnis so aussieht und sich so anfühlt wie im Prototyp spezifiziert.
• Feedbackschleifen berufen sich auf die Referenz – nicht auf Bauchgefühl.
• Regressionen in UI/UX sind erkennbar, weil sie sich am Prototyp messen lassen.

Für Teams, die aus rein featurebezogener Sicht planen, ist das ein wichtiger Perspektivwechsel: Qualität ist nicht nur funktional, sondern visuell und haptisch – und sie ist definierbar.

Warum frühe Entscheidungen Zeit sparen: Der ökonomische Effekt

Baldaufs Argumentation ist pragmatisch: Änderungen im Design-Tool sind billig, Änderungen im Code sind teuer. Ein sauberer UI/UX-Entwurf vor der Implementierung verringert die Zahl der späten Korrekturrunden. Dazu kommen Effizienzgewinne durch:

• Weniger Rückfragen (Spezifikation ist sichtbar und interaktiv erlebbar).
• Geringere Kontextwechsel (Assets und Code-Snippets stehen parat).
• Schnellere Kundeneinbindung (Transparenz in Sprints, klare Demos am Prototyp).

Das ist gelebte Risikoreduktion – und der Grund, warum Baldauf betont, dass Entwicklerinnen und Entwickler diesen Prozess lieben.

Was wir aus „UI/UX“ für den Alltag mitnehmen

Aus dem Talk mit Philipp Baldauf (Ahoi Kapptn!) bleiben drei Grundsätze:

1) UI/UX ist der erste Schritt – nicht der letzte.

2) Prototypen sind Spezifikationen, keine Mockups „für die Galerie“.

3) Konsistenz, Feedback und Kontrolle sind keine Add-ons, sondern Kern der Experience.

Wenn Teams diese Prinzipien ernst nehmen, werden Projekte planbarer – und Produkte nutzbarer. Die Brücke zwischen Kundenseite, Design und Engineering trägt dann tatsächlich die Last des Alltags: Releases, Sprints, Änderungen und Launches.

Praktische nächste Schritte für Teams

Wer die Impulse aus der Session direkt umsetzen will, kann mit einem kompakten Ablauf starten:

• Kick-off mit User Story Mapping: Flows, Ziele, Interaktionen sichtbar machen.
• Grobschnitt in MVP und Folgeversionen: Prioritäten, die eine vollständige Experience ermöglichen.
• High-Fidelity-Mockup und Prototyp: Figma/Sketch als Arbeitsgrundlage, inklusive Bewegungsmustern.
• Review gegen Human Interface Guidelines: Konsistenz, direkte Manipulation, Feedback, Kontrolle.
• Accessibility-Check: Schrift-Skalierung, Kontraste mit Stark, Farbschwächen berücksichtigen.
• Sprintplanung mit Referenz: Tickets referenzieren Mockup/Prototyp, klare Akzeptanzkriterien.
• Demos am Prototyp: Kundenseite erlebt Fortschritt so, wie er später im Produkt ankommt.

Dieser Ablauf spiegelt den in „UI/UX“ beschriebenen Prozess wider und lässt sich in bestehende Scrum-Setups integrieren.

Fazit

„UI/UX“ von Philipp Baldauf zeigt, wie konsequentes UI/UX-Design zum Beschleuniger für Engineering wird. Der Ablauf – User Story Mapping, klare Release-Schnitte, erst Design dann Code, Prototyp als Referenz, Sprints mit Transparenz, HIG-Compliance und frühe Accessibility – sorgt für messbar bessere Ergebnisse. Aus Sicht von DevJobs.at ist das der praktikable Weg, um Qualität von Anfang an in die Architektur einzubauen, statt sie am Ende zu „hinzupolieren“.

Die Botschaft ist einfach und wirkungsvoll: Wer das Erlebnis mitdenkt, baut bessere Software – effizienter, vorhersehbarer und nutzerfreundlicher. Genau das haben wir aus „UI/UX“ mit Philipp Baldauf (Ahoi Kapptn!) mitgenommen.

• 

  

  App Clips

  Philipp Jahoda von Ahoi Kapptn! präsentiert in seinem devjobs.at TechTalk die Grundidee der iOS App Clips und gibt ein Beispiel einer Implimentierung.

  Jetzt ansehen

• 

  

  Philipp Jahoda, CTO von AhoiKapptn!

  Der CTO von AhoiKapptn! Philipp Jahoda gibt im Interview Einblicke über das Team, wie der Recruiting Prozess abläuft und wie das Unternehmen die technologischen Herausforderungen meistert.

  Jetzt ansehen