UX/UI-Design für das Produkt, das du wirklich bauen wirst.
Kläre, wie Menschen die wichtigen Aufgaben erledigen, bevor Entwicklungszeit in Screens fließt. Wir skizzieren die Flows, testen klickbare Prototypen mit echten Nutzern und übergeben UI und Komponenten, die ein Entwicklungsteam ohne Raten umsetzen kann.
UX/UI-Design macht aus abgestimmten Produktanforderungen User Flows, klickbare Prototypen und eine umsetzbare Oberfläche. Der Auftrag umfasst die vereinbarten Aufgaben und Screens, Usability-Sessions mit echten Teilnehmenden und eine Übergabe, mit der dein Entwicklungsteam arbeiten kann.
Passt für
Teams, die eine Anwendung bauen oder neu bauen und deren zentrale Abläufe noch nicht gestaltet sind
Produkte, bei denen Nutzer im Onboarding, Setup oder in der Kernaufgabe abspringen
Eine andere Leistung passt besser
Anforderungen, Architektur und Baupreis sind noch offen
Eine Marketing- oder Content-Website statt einer Anwendung
Mit den Aufgaben beginnen, an denen das Produkt steht oder fällt
Wähle die wenigen Aufgaben, die ein Nutzer erledigen muss, damit sich das Produkt lohnt: registrieren, etwas einrichten, die Kernaufgabe abschließen, sich von einem Fehler erholen. Gestalte diese vollständig, bevor du irgendetwas anderes polierst. Sind Produktrichtung, Anforderungen oder Baupreis noch offen, klärst du das zuerst in der Software Discovery; diese Leistung setzt einen geklärten Umfang voraus. Eine öffentliche Marketing- oder Content-Website gehört zur Website-Entwicklung.
Was die Design-Arbeit liefert
Jedes Ergebnis soll eine Vermutung aus dem Build entfernen. Die Tiefe vereinbaren wir je Phase, statt standardmäßig jedes denkbare Dokument zu liefern.
User Flows und Zustände
Jede vereinbarte Aufgabe als Flow, inklusive leerer, ladender, fehlerhafter, berechtigungsabhängiger und halb abgeschlossener Zustände. Genau dort brechen die meisten Oberflächen.
Wireframes und klickbare Prototypen
Zuerst grobe Layouts, dann ein klickbarer Prototyp der Flows mit dem größten Risiko. Code entsteht erst, wenn du den Flow freigegeben hast.
UI-Design und Komponenten
Visuelles Design für die vereinbarten Screens, aufgebaut aus wiederverwendbaren Komponenten mit Varianten, Abstands- und Typo-Tokens. Ein Design-System wird daraus erst, wenn das Produkt eines braucht.
Eine entwicklungsreife Übergabe
Annotierte Screens, Interaktionshinweise, responsives Verhalten und Komponenten-Specs, gemeinsam mit deinem Entwicklungsteam durchgegangen, bevor es baut.
Flows mit echten Nutzern prüfen, nicht nur mit Stakeholdern
Ein Stakeholder-Review zeigt, ob das Design zum Briefing passt. Wenn du einer Handvoll Menschen aus deiner Zielgruppe bei einer Aufgabe zusiehst, siehst du, wo sie scheitert. Wir führen kurze moderierte Sessions am Prototyp durch, halten fest, was Menschen blockiert, und ändern das Design, bevor es gebaut wird. Du hilfst, Teilnehmende aus deinen Kunden oder deiner Zielgruppe zu gewinnen. Wir betreiben kein Research-Panel und kein Research-Lab, und im Angebot steht, wer jede Session leitet. Größere Studien, quantitative Forschung oder Rekrutierung über eine Agentur werden separat vereinbart. Barrierearme Muster gehören zum Design (Kontrast, Fokusreihenfolge, Beschriftungen, Zielgrößen); eine formale Prüfung des fertigen Produkts gegen WCAG 2.2 ist ein eigenes Accessibility Audit.
Illustrative Session: ein Formular, das die Registrierung blockiert
Illustrativ, kein Kundenergebnis. Ein Registrierungs-Flow fragt Firmendaten ab, bevor der Nutzer irgendetwas Nützliches gesehen hat. In der Prototyp-Session zögern Teilnehmende beim Firmenformular und fragen, wozu es nötig ist. Der überarbeitete Flow startet mit einer E-Mail-Adresse, zeigt das Produkt und fragt Firmendaten erst bei der ersten Aktion ab, die sie braucht. Das Session-Protokoll nennt Aufgabe, Prototyp-Version, das Verhalten der Teilnehmenden, die Änderung und was im gebauten Produkt noch geprüft werden muss. Es dokumentiert die Methode, keine gemessene Verbesserung.
In Phasen gestalten, mit einer Entscheidung nach jeder
Umfang und Angebot vereinbaren wir je Phase vor Beginn. Du kannst den Prototyp an dein eigenes Team geben oder mit der individuellen Softwareentwicklung direkt in den Build gehen.
Flows und Prototyp
Du erhältst Aufgaben-Flows, Wireframes, einen klickbaren Prototyp und Session-Notizen zu den riskantesten Aufgaben.
UI-Design und Übergabe
Du erhältst die vereinbarten Screens, Komponenten und annotierte Specs, gemeinsam mit deinem Entwicklungsteam geprüft.
Design-Begleitung im Build
Review-Rhythmus und Änderungsgrenzen vereinbaren wir separat. Design-Fragen aus dem Build beantworten wir anhand der vereinbarten Flows.
Die Design-Dateien und die Entscheidungen dahinter gehören dir
Die Design-Dateien liegen in deinem Workspace (meist Figma) oder werden bei der Übergabe übertragen, zusammen mit der Komponentenbibliothek und den Notizen, warum jeder Flow so aussieht, wie er aussieht. Wir gestalten mit Blick auf die Umsetzung, weil wir Software auch scopen und bauen. Braucht dein Umfang spezialisiertes Visual- oder Brand-Design, nennt das Angebot, wer es liefert. Markenidentität, Logos und Marketingkampagnen sind nicht Teil dieser Leistung.
// beweise
Produkt-UX in bestehender Engineering-Arbeit
Wir veröffentlichen kein Design-Portfolio. Diese Fälle zeigen UX-Entscheidungen innerhalb von Engineering-Aufträgen, keine eigenständigen Design-Projekte. Afoma: Social Login mit unsichtbarer Wallet-Erstellung, damit Marktplatz-Nutzer nie mit Krypto-Jargon in Berührung kamen, und Bestandsnutzer wechselten ohne erzwungenes Re-Onboarding zum neuen Login. Aniron: Onboarding, API-Keys und Guthabenstände im Developer-Portal verständlich auf Desktop und Mobile. Twinsoft AI: mehrere UI-Iterationen auf einem stabilisierten Produkt vor Enterprise-Pilotgesprächen.
▸Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.
Fragen vor dem Start
Wir starten mit den Aufgaben und den Belegen, die du schon hast: Support-Tickets, Analytics, Sales-Gespräche und frühere Tests. Moderierte Usability-Sessions am Prototyp gehören zum Standardumfang. Ist noch offen, ob Menschen das Produkt überhaupt brauchen, ist das Validierungsarbeit und wird vor dem Design geklärt.
Ja. Wir starten bei den aktuellen Screens und den Aufgaben, an denen Nutzer hängen bleiben, und gestalten zuerst diese Flows neu, statt alles neu anzustreichen.
Standardmäßig mit Figma für Flows, Prototypen und Komponenten. Arbeitet dein Team schon mit einem anderen Tool, klären wir das beim Scoping.
Wenn das Produkt eines braucht. Wir starten mit den Komponenten der vereinbarten Screens und machen daraus ein dokumentiertes System, sobald mehrere Teams oder Produkte sie teilen.
Barrierearme Muster sind Teil des Designs: Kontrast, Fokusreihenfolge, Beschriftungen, Fehlermeldungen und Zielgrößen. Eine formale Prüfung eines fertigen Produkts gegen WCAG 2.2 beauftragst du separat als Accessibility Audit.
Beschreibe das Produkt, wer es nutzt und welche Aufgaben am wichtigsten sind. Skizzen, Screenshots oder ein vorhandener Prototyp helfen; eine fertige Spezifikation brauchst du nicht.
