Wir gestalten native Apps, Cross-Platform-Produkte und Web-Anwendungen vom Problemrahmen bis zur implementierbaren Spezifikation. Nicht als Galerie perfekter Screens, sondern als System aus Aufgaben, Zuständen und klaren Entscheidungen.
UX Research · User Flows · UI-System · Prototyping · Developer Handoff
Product Cut · kompakt
Problem → Flow → Zustände → System → baubare Spezifikation
Wer muss was erledigen – und unter welchen Bedingungen?
Wir trennen den eigentlichen Nutzerauftrag von der ersten Featureliste. Rollen, Nutzungssituation, Geschäftslogik und technische Grenzen werden zu einem prüfbaren Problemrahmen.
Wer muss was erledigen – und unter welchen Bedingungen?
Professionelles App Design beginnt nicht mit Farben und endet nicht bei Figma. Es verbindet den Zweck des Produkts mit der Situation, in der ein Mensch es tatsächlich benutzt.
Dafür müssen Produktteams mehr wissen als „Welche Screens brauchen wir?“. Relevant ist, warum jemand die App öffnet, welche Information vor einer Entscheidung fehlt, welche Aktion riskant oder unumkehrbar ist und welches Feedback Sicherheit schafft. Auch Geschäftsregeln, Datenquellen, Rollenrechte, Gerätekontext und technische Abhängigkeiten formen das Interface.
Die Top-Ergebnisse für „App Design Agentur“ zeigen zu Recht Portfolios, Wireframes, Prototypen und Entwicklungsprozesse. Häufig unsichtbar bleibt jedoch die Arbeit zwischen diesen Bildern: Zustände, Abnahmekriterien und offene Entscheidungen. Genau dort entstehen später die teuersten Missverständnisse. Unser Product Cut macht diesen Teil früh sichtbar.
Was soll am Ende erledigt sein?
Wo, womit und unter welchem Druck passiert es?
Welche Information verändert den nächsten Schritt?
Wie bestätigt, begrenzt oder korrigiert das Produkt?
Woran erkennen Team und Nutzer, dass der Pfad trägt?
Personas, Interviews und Wettbewerbsanalysen erscheinen auf fast jeder Agenturseite. Sinnvoll werden sie erst, wenn klar ist, welche Unsicherheit sie reduzieren sollen. Bei einer neuen Produktidee fehlen andere Belege als bei einer App, die bereits täglich genutzt wird. Deshalb wählen wir keine feste Methodenliste, sondern beginnen mit der offenen Entscheidung.
Nutzungsdaten, Suchbegriffe in der App, Supportfälle, Store-Feedback, Abbruchstellen und beobachtete Aufgaben zeigen, wo Menschen heute tatsächlich hängen bleiben. Daten erklären das Verhalten nicht automatisch; qualitative Beobachtung hilft, das Warum einzugrenzen.
Gespräche mit späteren Nutzern und Fachexperten, reale Arbeitsabläufe, vorhandene Dokumente, regulatorische Grenzen und technische Machbarkeit ersetzen fehlende Produktdaten. Ein Wettbewerber zeigt gelernte Konventionen, aber nicht automatisch die richtige Lösung für den eigenen Kontext.
Research darf keine Gewissheit vorspielen. Kleine Stichproben können deutliche Verständnisprobleme zeigen, aber keine Marktgröße beweisen. Produktanalytics können Muster sichtbar machen, aber keine Motivation lesen. Erkenntnis, Annahme und offene Frage bleiben deshalb getrennt.
Was aus Daten, Beobachtung, Fachregeln oder technischem Bestand nachvollziehbar hervorgeht.
Was plausibel ist, aber vor einer großen Umsetzungsentscheidung geprüft werden sollte.
Was weder das Design noch der Prototyp beantworten kann und bewusst an Technik, Recht oder Markt zurückgeht.
Ein freigegebener Idealzustand beantwortet nur einen kleinen Teil der Produktfrage. Daten können fehlen, ein Netzwerk kann langsam sein, Rechte können eingeschränkt werden und Eingaben können unvollständig bleiben. Wenn diese Fälle erst in der Entwicklung auftauchen, entscheiden Entwickler unter Zeitdruck über Nutzerführung, Sprache und Fehlerbehebung.
Darum besitzt jeder wichtige Flow ein Zustandsmodell. Es beschreibt nicht nur, wie etwas aussieht, sondern was ausgelöst wurde, welche Rückmeldung folgt, ob Eingaben erhalten bleiben und welcher nächste Schritt möglich ist. Das folgende Beispiel ist bewusst vereinfacht und zeigt fünf unterschiedliche Antworten auf dieselbe Aufgabe.
Zeitraum und Dateiformat sind vorhanden. Die nächste Aktion ist eindeutig.
Illustratives Zustandsmodell · kein Kundeninterface
App-Design-Projekte laufen iterativ, aber nicht beliebig. Jede Phase braucht eine Entscheidung und ein überprüfbares Ergebnis. Wie viele Schleifen sinnvoll sind, hängt von Risiko und Reifegrad des Produkts ab – nicht von einer pauschalen Sprintzahl.
Wir klären Nutzerrollen, Nutzungssituationen, Geschäftsregeln, vorhandene Erkenntnisse und technische Grenzen. Bei einer bestehenden App kommen Supportfragen, Nutzungsdaten und bekannte Brüche hinzu. Das Ergebnis ist keine Persona-Sammlung, sondern eine priorisierte Frage: Welcher Teil des Produkts muss zuerst verständlich und testbar werden?
Output
Problemrahmen · Annahmen · Risiken
Aus Aufgaben werden Informationsfolgen und Entscheidungen. Wir reduzieren nicht pauschal auf möglichst wenige Schritte; ein zusätzlicher Schritt kann richtig sein, wenn er eine irreversible Aktion erklärt, Sicherheit schafft oder Fehler verhindert. Entscheidend ist, dass jeder Schritt eine nachvollziehbare Funktion besitzt.
Output
User Flow · Inhaltslogik · Abzweigungen
Wireframes und Prototypen machen Struktur, Reihenfolge und Interaktion prüfbar, bevor visuelle Details eine schwache Logik kaschieren. Testpersonen bearbeiten konkrete Aufgaben. Beobachtet werden Umwege, Rückfragen, Fehlinterpretationen und Abbrüche – nicht bloß die Antwort auf die Frage, ob etwas gefällt.
Output
Wireframes · Prototyp · Testfragen
Erst jetzt werden Typografie, Farbe, Hierarchie, Komponenten und Motion zu einem UI-System verbunden. Markenidentität bleibt sichtbar, aber Plattformmuster werden nicht aus Prinzip überschrieben. Wiederkehrende Bausteine erhalten Varianten und Regeln; Sonderfälle bleiben bewusst als Sonderfälle erkennbar.
Output
UI-Richtung · Komponenten · Tokens
Entwicklung bekommt mehr als Bildschirmbilder: Verhalten, Zustände, responsives beziehungsweise adaptives Verhalten, Assets und Akzeptanzkriterien. Im Design-QA vergleichen wir nicht Pixel um ihrer selbst willen, sondern prüfen, ob Hierarchie, Interaktion und Zugänglichkeit in der laufenden Anwendung erhalten bleiben.
Output
Spezifikation · Handoff · Design-QA
Native App, Cross-Platform-Anwendung und Web-App sind keine reinen Technologieetiketten. Sie verändern Navigation, Eingabegeräte, Fenstergrößen, Systemfeedback und Erwartungen. Eine geteilte Codebasis kann Aufwand reduzieren, hebt diese Designunterschiede aber nicht auf.
iOS / iPadOSPlattformmuster, Hierarchien und Rückwege mitdenken.
AndroidSystem-Back, Navigation und unterschiedliche Geräteformen berücksichtigen.
Web-AppURL, Verlauf, Deep Links und Browsernavigation erhalten.
iOS / iPadOSSafe Areas, Dynamic Type und iPhone-/iPad-Kontext spezifizieren.
AndroidFensterklassen, Foldables, Reflow und Mehrfenstermodus planen.
Web-AppResponsive Container, Zoom, kleine und große Viewports definieren.
iOS / iPadOSTouch; je nach Gerät auch Pointer und Tastatur.
AndroidTouch, Tastatur, Pointer und wechselnde Gerätehaltung.
Web-AppMaus, Touch, Tastatur und assistive Technologien gleichwertig.
iOS / iPadOSSystemnahe Controls, klare Zustände und optionale Haptik.
AndroidPlattformgerechte Zustände, Systemflächen und Back-Verhalten.
Web-AppFokus, Validierung, Ladeverhalten und Browsergrenzen sichtbar machen.
Zugänglichkeit beginnt im Flow: klare Sprache, vorhersehbare Reihenfolge, sichtbarer Fokus, Alternativen zu Gesten, robuste Fehlerbehandlung und Inhalte, die bei vergrößerter Schrift nicht zerfallen. Mindestgrößen sind ein wichtiger Check – aber kein Ersatz für das Gesamtsystem.
Drei Bezugssysteme · Einheiten nicht gleichsetzen
Success Criterion 2.5.8, Level AA: mindestens 24 × 24 CSS-Pixel oder eine der dokumentierten Ausnahmen, etwa ausreichender Abstand.
Apple nennt 44 × 44 pt als Standardgröße für komfortabel bedienbare Controls; die aktuelle Accessibility-Tabelle weist zusätzlich kleinere plattformspezifische Mindestwerte aus.
Android empfiehlt für interaktive UI-Elemente eine fokussierbare Touch-Fläche von mindestens 48 × 48 dp. Die sichtbare Grafik darf durch Padding kleiner sein.
Ein vollständiger Handoff erklärt nicht nur Maße und Farben. Er transportiert die Logik hinter einem Zustand: Was löst ihn aus? Welche Daten fehlen? Was darf ein Nutzer tun? Was passiert auf kleinen Fenstern, bei langer Übersetzung oder ohne Berechtigung?
Designer und Entwickler gehen die kritischen Flows gemeinsam durch. Offene Fragen bleiben sichtbar und werden nicht als scheinbar fertige Oberfläche getarnt. Nach der Implementierung folgt Design-QA im echten Produkt – mit realen Inhalten, Breakpoints, Fokusreihenfolge und Systemverhalten.
Rollen, Kernpfade, Abzweigungen und Erfolgsmomente
leer, lädt, Fehler, Erfolg, Rechte und Offline-Fälle
Komponenten, Varianten, Tokens und Inhaltsregeln
Breakpoints, Reflow, Safe Areas, Eingabe und Fokus
Icons, Bilder, Exportregeln und technische Formate
prüfbare Kriterien für Interaktion und Design-QA
bewusst ungeklärte Fach- und Technikentscheidungen
Illustrative Übergabestruktur · konkrete Artefakte folgen dem Projektumfang
Ein Prototyp kann Verständnis und Reihenfolge prüfen. Erst die implementierte App zeigt jedoch reale Ladezeiten, Geräteverhalten, assistive Nutzung, Backend-Grenzen und wiederkehrende Gewohnheiten. Deshalb sollte schon im Design geklärt werden, welche Fragen nach dem Release offenbleiben und welche Signale sie beantworten können.
Aufgabenerfolg, Abbrüche und Fehler werden nur dort erfasst, wo ein klarer Zweck und eine datenschutzgerechte Messung vereinbart sind. Supportanfragen, Store-Feedback und direkte Gespräche ergänzen das Verhaltenssignal.
Ein häufiger Rücksprung kann ein Navigationsproblem sein – oder ein sinnvoller Vergleich. Ein abgebrochener Prozess kann auf Sprache, Berechtigung, Preis, Performance oder eine bewusste Entscheidung zurückgehen. Metrik und Ursache werden nicht gleichgesetzt.
Änderungen werden nach Schwere, Häufigkeit, Nutzerwirkung und Geschäftsrisiko priorisiert. Ein kritischer Rechtefehler schlägt eine kosmetische Inkonsistenz; ein lautes Einzelreview ersetzt kein wiederkehrendes Muster.
App-Store-Optimierung, Wartung und technische Weiterentwicklung gehören nicht automatisch zum Designauftrag. Wenn sie benötigt werden, werden Verantwortlichkeit, Messzugang und Release-Rhythmus separat im Scope festgehalten. Android ordnet Datenschutz, Sicherheit und technische Qualität ausdrücklich der App-Qualität zu. Android App Quality
Der richtige Umfang richtet sich nach dem Risiko. Manchmal reicht ein konzentrierter Product Slice für den wichtigsten Flow. Manchmal verhindert ein Accessibility- und Zustandsreview mehr Probleme als eine neue Farbwelt. Und manchmal ist die Informationsarchitektur so widersprüchlich, dass lokale Reparaturen nur neue Ausnahmen erzeugen.
Eine riskante Aufgabe strukturieren, prototypisieren und für die Umsetzung spezifizieren.
Bestehende Flows, Zustände, Hierarchie und Zugänglichkeit gezielt prüfen.
Ein neues oder grundlegend verändertes Produkt vom Problemrahmen bis zum Handoff gestalten.
Eine App lohnt sich vor allem für wiederkehrende, interaktive oder gerätenahe Aufgaben. Wenn Information, Vertrauen und Anfrage im Mittelpunkt stehen, ist eine professionelle Website oft die klarere Lösung.
Für eine einzelne Kampagne kann eine fokussierte Landingpage ausreichen. Im Webdesign-Leistungsbereich ordnen wir die angrenzenden Formate ein.
Eine App Design Agentur übersetzt Produktziele und Nutzeraufgaben in Informationsarchitektur, User Flows, Wireframes, Interaktionen, UI-Komponenten, Prototypen und umsetzbare Spezifikationen. Der genaue Umfang hängt davon ab, ob eine Idee erst strukturiert, ein riskanter Kernpfad getestet oder eine bestehende Anwendung überarbeitet werden soll. Entwicklung, Betrieb und Vermarktung sind angrenzende Disziplinen und müssen im Angebot ausdrücklich enthalten sein, wenn sie Teil des Projekts werden sollen.
UX Design ordnet Aufgaben, Informationen, Zustände und Interaktionen über den gesamten Nutzungspfad. UI Design gestaltet die konkrete visuelle und interaktive Oberfläche: Typografie, Farbe, Abstände, Komponenten, Hierarchie und Feedback. Beides lässt sich organisatorisch trennen, im Produkt aber nicht unabhängig voneinander bewerten: Eine klare Logik kann durch eine schwache Oberfläche unverständlich werden, eine attraktive Oberfläche kann eine falsche Logik nicht reparieren.
Wir können die Produktoberfläche für diese Ausprägungen konzipieren. Die Designregeln sind jedoch nicht identisch. Native iOS- und Android-Apps orientieren sich an eigenen Plattformkonventionen; Cross-Platform-Technik teilt möglicherweise Code, aber nicht automatisch jede Interaktionsentscheidung. Web-Apps müssen zusätzlich Browser, URLs, responsive Viewports sowie Maus- und Tastaturbedienung berücksichtigen. Die technische Zielarchitektur wird deshalb vor dem finalen UI festgelegt.
Eine belastbare Dauer ergibt sich erst aus Scope und Reifegrad. Relevant sind unter anderem die Zahl der Rollen und Kernpfade, Plattformen, fachliche Regeln, vorhandene Research-Ergebnisse, Zustandsdichte, Testschleifen und der gewünschte Handoff. Ein fokussierter Flow-Review ist deutlich kleiner als die Konzeption eines neuen Produkts. Nach Sichtung des Materials grenzen wir deshalb zuerst Ergebnis, Abnahmen und offene Risiken ab.
Ein seriöser Preis lässt sich nicht aus der Zahl sichtbarer Screens ableiten. Ein einzelner Screen mit Rollenrechten, Offline-Verhalten und mehreren Fehlerfällen kann mehr Designarbeit enthalten als zehn lineare Inhaltsseiten. Für ein Angebot betrachten wir Produktfrage, Kernpfade, Plattformen, Systemtiefe, Research, Prototyping, Tests und Übergabebedarf. So wird sichtbar, welche Entscheidungen im Preis enthalten sind und welche nicht.
Nein. Wenn Navigationsmodell, Designsystem und zentrale Abläufe tragfähig sind, kann ein gezielter Eingriff sinnvoller sein: ein kritischer Flow, fehlende Zustände, ein Accessibility-Review oder die Konsolidierung der Komponenten. Ein vollständiger Neustart ist erst dann begründet, wenn lokale Korrekturen die strukturellen Ursachen nicht mehr lösen.
Je nach Scope gehören dazu Flow- und Zustandsmodelle, Komponenten mit Varianten, Tokens, Maße, Assets, Texte, responsive oder adaptive Regeln, Interaktionsverhalten und dokumentierte offene Fragen. Hinzu kommen ein gemeinsamer Walkthrough und Design-QA in der Implementierung. Eine Figma-Datei allein ist kein vollständiger Handoff.
Ein klickbarer Prototyp kann Informationsreihenfolge, Benennung, Navigation, Entscheidungswege und ausgewählte Interaktionen erfahrbar machen. Er eignet sich, um konkrete Aufgaben früh zu beobachten und Missverständnisse vor der Entwicklung aufzudecken. Er beweist jedoch weder technische Performance noch Backend-Logik, reale Geräteintegration oder die vollständige Zugänglichkeit des späteren Codes. Deshalb werden Testfrage und Grenzen des Prototyps vorab benannt.
Wir sichten vorhandene Konzepte, Screens, Nutzerfeedback oder technische Randbedingungen und grenzen ein, welche Produktfrage zuerst beantwortet werden sollte. Danach lässt sich ein sinnvoller Scope statt eines pauschalen Screen-Pakets anbieten.