UX/UI-Design-Dienstleistungen
Interface-Design, das in Produktion geht — nicht in eine Kundenpräsentation. Wir gestalten und entwickeln gemeinsam, was bedeutet, dass zwischen der Figma-Datei und der fertig deployten Komponente nichts verloren geht. Design-Systeme, SaaS-Dashboards und Marketing-Interfaces, gebaut von einem Team, das versteht, wie jeder Pixel umgesetzt wird.
Jeder in UX investierte Dollar bringt geschätzt 100 Dollar zurück — ein ROI von etwa 9.900 % (Forrester Research). Ein gut umgesetztes User Interface kann die Konversionsrate um bis zu 200 % steigern; optimiertes UX-Design darüber hinaus kann den Wert auf 400 % treiben (UXCam, 2025). Das finanzielle Argument für Design ist alles andere als subtil. Die operative Herausforderung besteht darin, es ohne die kostspielige Übersetzungsschicht zwischen dem, was ein Designer entworfen hat, und dem, was ein Entwickler gebaut hat, zu liefern.
Das Problem mit den meisten Design-Aufträgen#
Wenn Design und Entwicklung getrennte Gespräche sind#
Das Standard-Agenturmodell trennt Design und Entwicklung in getrennte Phasen und oft auch in getrennte Teams. Eine Design-Agentur liefert Figma-Dateien. Eine Entwicklungsagentur erhält sie. Diese Lücke ist der Punkt, an dem die Produktqualität leidet.
Designer treffen in Figma Entscheidungen, die sauber und korrekt aussehen, aber versteckte Implementierungskosten mit sich bringen: Komponenten, die variablen Textlängen nicht Rechnung tragen, Interaktionen, die eigene Animationsbibliotheken erfordern, Layouts, die bei ungewöhnlichen Viewport-Breiten brechen. Wenn der Designer während der Entwicklung nicht verfügbar ist, improvisiert der Entwickler. Das ausgelieferte Produkt ist eine weniger originalgetreue Version dessen, was entworfen wurde.
Was bei der Übergabe verloren geht#
Zuerst verschwindet die Zustandsbehandlung: leere Zustände, Ladezustände, Fehlerzustände. Dann das responsive Verhalten unterhalb der gestalteten Breakpoints. Dann die Interaktionsdetails, die im Prototyp implizit waren, aber nie dokumentiert wurden. Dann die Begründung hinter Abstands- und Typografie-Entscheidungen. Wenn ein Design-System nicht Teil des Lieferumfangs ist, lassen sich einzelne Screens nicht mehr korrekt zusammenfügen, sobald ein Entwickler eigenständig einen neuen erstellt.
Warum 91 % der Entwickler sagen, dass der Übergabeprozess verbessert werden könnte#
91 % der Entwickler und 92 % der Designer geben an, dass der Design-to-Development-Übergabeprozess verbessert werden könnte (CollabSoft Designer Survey, 2025). Die häufigsten Ursachen: unklare Spezifikationen, unvollständige Dokumentation interaktiver Zustände und Designdateien, die nicht unter Berücksichtigung technischer Einschränkungen erstellt wurden. Mangelhafte Designkommunikation verursacht bis zu 30 % der Entwicklungsverzögerungen (GeekyAnts, 2025).
Die Kluft zwischen Design und Entwicklung ist ein strukturelles Problem, kein persönliches. Die Lösung besteht darin, Implementierungswissen vom ersten Tag an mit einzubeziehen.
Was wir tatsächlich liefern#
Produkt-Interfaces#
Applikations-Interfaces für Web- und Mobile-Produkte, die die gesamte Designfläche eines funktionierenden digitalen Produkts abdecken. Informationsarchitektur, Navigationsmuster, Komponentendesign, Interaktionsmodelle und jeder Zustand, dem ein Nutzer begegnen kann: Onboarding, leere Zustände, Fehlerzustände, Laden, Erfolg, Grenzfälle.
Wir gestalten für das Produkt, das tatsächlich gebaut wird. Das bedeutet, innerhalb dessen zu arbeiten, was der Engineering-Zeitplan tragen kann, explizit festzulegen, was im aktuellen Release erscheint und was später kommt, und Komponenten zu bauen, die das Entwicklungsteam erweitern kann, ohne sie neu schreiben zu müssen.
SaaS-Dashboards und Admin-UX#
Datenintensive Interfaces erfordern ein anderes Denken als Marketingseiten. Ein SaaS-Dashboard muss viele Informationen auf kompaktem Raum darstellen und trotzdem für Power-User funktionieren, die seit drei Stunden damit arbeiten. Wir gestalten Dashboards auf Basis realer Datenmodelle, nicht Platzhalter-Diagramme — das bedeutet, die Layouts halten auch dann stand, wenn Ihre Daten in Dichte und Umfang variieren.
Admin-Interfaces erhalten dieselbe Aufmerksamkeit: Berechtigungshierarchien, Massenaktionen, filterbare Tabellen und Konfigurations-UX, die ein Betreiber ohne Dokumentation bedienen kann.
Landingpages und Marketing-Design#
Konversionsoptimierte Marketingseiten mit klarer Informationshierarchie und einem einzigen primären CTA. Wir arbeiten vom Text nach außen: Design dient der Botschaft. Für Teams, die Growth-Experimente durchführen, halten wir die Struktur sauber genug, um ohne komplettes Redesign dagegen testen zu können.
Design-Systeme#
Eine wiederverwendbare Komponentenbibliothek, dokumentierte Design-Tokens und eine Figma-Struktur, die mit dem Produktionscode synchron bleibt. Jede nachfolgende Design- und Engineering-Entscheidung geht schneller, sobald ein System existiert. Siehe den Abschnitt weiter unten für Details.
Wie wir arbeiten: Design, das ausgeliefert wird#
Discovery und User Research#
Wir beginnen mit der Zielgruppe und dem Anwendungsfall. Wer nutzt dieses Produkt, was möchten sie erreichen, wo bleiben sie hängen? Bei neuen Produkten bedeutet das Stakeholder-Interviews und kompetitive Interface-Analyse. Bei bestehenden Produkten bedeutet es die Auswertung von Analytics, Support-Tickets und Nutzerfeedback.
Die Discovery-Phase endet mit einem klaren Briefing: die primären Jobs-to-be-Done der Nutzer, die Informationshierarchie, die das Interface unterstützen muss, und die Rahmenbedingungen (technisch, zeitlich, markenspezifisch), die jede nachfolgende Designentscheidung prägen.
Wireframes und Informationsarchitektur#
Wir legen die Layoutlogik in der Wireframe-Phase fest, bevor das visuelle Design beginnt. Navigationsstruktur, Seitenhierarchie, Datengruppierung: All das wird geklärt, wenn eine Änderung Stunden kostet, nicht Tage.
Wir besprechen Wireframes gemeinsam mit dem Kunden und der Engineering-Leitung. Routing-Implikationen, Datenmodell-Einschränkungen und aufwendige Interaktionen werden hier sichtbar — nicht während eines Entwicklungssprints.
High-Fidelity-Design in Figma#
Jeder Screen wird aus einer gemeinsamen Komponentenbibliothek aufgebaut. Das Design skaliert auf neue Screens, ohne die Konsistenz zu brechen, und die Übergabedatei ist für Entwickler ohne Einführung navigierbar.
Farbe, Typografie, Abstände und Icon-Systeme werden als Design-Tokens definiert, bevor einzelne Screens erstellt werden. Das hält visuelle Entscheidungen nachvollziehbar und macht die Generierung eines Design-Systems am Ende des Auftrags unkompliziert.
Prototyp und Feedback-Zyklen#
Wir erstellen interaktive Prototypen in Figma, um Abläufe zu validieren, bevor die Entwicklung beginnt. Prototypen decken die primären User Journeys, wichtige Fehlerzustände und jede Interaktion ab, die ein Designrisiko birgt.
Feedback-Sitzungen haben eine Struktur: spezifische Fragen, spezifische Screens, spezifische Ergebnisse, die wir aus dem Review benötigen. Offene „Sieht das gut aus?"-Sitzungen werden durch aufgabenbasierte Walkthroughs ersetzt.
Übergabe oder vollständige Implementierung#
Wenn Sie Designdateien an Ihr eigenes Team übergeben lassen möchten, liefern wir eine vollständig annotierte Figma-Datei mit interaktiven Zuständen, Abstandsdokumentation und einer Komponentenbibliothek — plus eine Walkthrough-Sitzung und Verfügbarkeit während des ersten Entwicklungssprints.
Wenn Sie Design und Entwicklung in einem Auftrag wünschen, gehen wir direkt von validierten Designs in unsere eigene Implementierung über. Der Designer und der Entwickler haben dasselbe Verständnis des Produkts, weil sie im selben Team arbeiten — in manchen Fällen sind es sogar dieselbe Person. Keine Übersetzungsschicht. Genau das eliminiert die 30 % der Entwicklungsverzögerungen, die durch unklare Designanforderungen entstehen.
Design-Systeme: der sich kumulierende Vermögenswert#
Was ein Design-System ist und was es Ihnen bringt#
Ein Design-System ist eine dokumentierte Bibliothek aus Komponenten, Mustern und Designentscheidungen, auf die sowohl Design als auch Engineering zurückgreifen. Es ist die Single Source of Truth dafür, wie ein Button aussieht, wie sich ein Formular verhält, was Abstandseinheiten bedeuten und wie sich die Farbpalette erweitern lässt.
Die erste Komponentenbibliothek braucht Zeit zum Aufbau. Danach geht jeder Screen, jedes Feature und jedes Produktupdate schneller, weil die Entscheidungen bereits getroffen und die Komponenten bereits vorhanden sind. Teams mit ausgereiften Design-Systemen liefern neue Arbeit in einem Bruchteil der Zeit im Vergleich zu denen, die jeden Sprint von Grund auf neu aufbauen. Das System amortisiert sich etwa ab dem vierten oder fünften Screen.
Tokens, Komponenten und Dokumentation#
Ein produktionsreifes Design-System umfasst:
- Design-Tokens: benannte Werte für Farbe, Typografie, Abstände, Radius, Schatten und Motion. Diese existieren in Figma als Variablen und im Code als CSS Custom Properties oder Theme-Objekt.
- Basiskomponenten: Buttons, Inputs, Badges, Icons, Tooltips. Jeweils mit allen Varianten und Zuständen dokumentiert.
- Zusammengesetzte Komponenten: Formulargruppen, Datentabellen, Navigationsmuster, modale Dialoge, Benachrichtigungssysteme.
- Musterdokumentation: Wann welche Komponente einzusetzen ist, wie Grenzfälle behandelt werden, Hinweise zur Barrierefreiheit.
Wie wir für Tailwind und Komponentenbibliotheken bauen#
Unsere Design-Systeme sind auf Tailwind CSS und React-Komponentenbibliotheken abgestimmt. Token-Werte werden direkt auf die Tailwind-Konfiguration abgebildet. Komponenten werden mit demselben Klassensystem gestaltet, das die Entwickler nutzen — es gibt also keine Diskrepanz zwischen den Abständen in Figma und den Abständen in der Produktion.
Für Teams mit einer bestehenden Komponentenbibliothek (shadcn/ui, Radix, MUI) arbeiten wir innerhalb dieser Rahmenbedingungen und erweitern nur dort, wo es notwendig ist.
Wenn Design und Entwicklung dasselbe Team sind#
Warum das Modell ohne Übergabe bessere Ergebnisse liefert#
Wenn die Personen, die das Design erstellen, selbst Produktionssoftware ausgeliefert haben, verkürzt sich die Feedbackschleife von Wochen auf Stunden. Ein Designer, der die Architektur von React-Komponenten versteht, trifft andere Entscheidungen als einer, der das nicht tut. Aufwendige Interaktionen werden bereits in der Designphase vereinfacht. Komponenten, die visuell ähnlich, aber architektonisch unterschiedlich sind, werden vereinheitlicht, bevor eine einzige Zeile Code geschrieben wird.
Unser CTO begann seine Karriere im UX/UI-Design, wechselte dann in Full-Stack-Engineering, Enterprise-Systeme und Consumer-Produktentwicklung. Er hat die Entscheidung getroffen, eine Interaktion zu vereinfachen, weil er wusste, was die Implementierung kosten würde. Dieses praktische Gespür zeigt sich nicht in einer Figma-Datei, die von jemandem geliefert wird, der nicht im Codebase arbeiten wird.
Wie das mit Web- und SaaS-Entwicklung zusammenhängt#
Design und Entwicklung werden als separate Dienstleistungen angeboten, weil nicht jeder Kunde beides benötigt. Manche haben bereits ein Design-System; manche haben bereits Entwickler. Wenn ein Projekt beides braucht, ist die gemeinsame Durchführung deutlich besser für das Ergebnis. Die Seite Web- und SaaS-Entwicklung beschreibt, wie der Full-Stack-Build neben diesem Designprozess funktioniert.
Der Full-Stack-Produktlebenszyklus, den wir ausgeliefert haben#
Wir haben komplette Produktzyklen ausgeliefert: von den Anforderungen über das Design über das Engineering bis zur Veröffentlichung im App Store oder in der Produktionsumgebung. Ein Interface mit direktem Wissen darüber zu gestalten, wie es implementiert wird — einschließlich der Komponentenhierarchie, des State-Management-Ansatzes und des API-Vertrags — produziert Arbeit, die straffer und wartbarer ist als alles, was isoliert entworfen wurde.
Besuchen Sie die Seite Technologien für das vollständige Bild dessen, womit wir arbeiten, und unsere Projekte für ein konkretes Beispiel eines Produkts, das wir vom Konzept bis zur Produktion gestaltet und ausgeliefert haben.
FAQ#
Was ist in UX/UI-Design-Dienstleistungen enthalten?
Ein vollständiger Auftrag umfasst typischerweise Discovery und User Research, Informationsarchitektur und Wireframing, High-Fidelity-Visual-Design in Figma, einen interaktiven Prototyp und entweder eine Übergabedatei oder direkte Implementierung. Der Umfang variiert: Manche Kunden benötigen den vollständigen Prozess; andere haben ein validiertes Produkt und brauchen nur visuelles Design. Wir passen den Umfang jedes Auftrags an das an, was das Projekt tatsächlich erfordert.
Was kostet professionelles UX/UI-Design?
Aufträge reichen von 8.000 $ für eine fokussierte Marketing-Website bis 60.000 $+ für ein vollständiges Produktdesign mit Design-System. Die Kosten hängen von Umfang, Anzahl der Screens, Komplexität der interaktiven Zustände und davon ab, ob ein Design-System enthalten ist. Wir erstellen ein Festpreis-Angebot nach einem Discovery-Gespräch.
Welche Tools nutzen Ihre Designer?
Figma für alles: Wireframes, High-Fidelity-Design, Prototypen, Komponentenbibliotheken und Übergabedokumentation. Für Design-to-Code-Workflows nutzen wir Figmas Developer Mode und verbinden uns, wo anwendbar, direkt mit unseren Tailwind-basierten Komponentensystemen. Wir verwenden keine Tools, die generierten Code produzieren.
Was ist ein Design-System und brauche ich eines?
Ein Design-System ist eine gemeinsam genutzte Bibliothek aus Komponenten, Tokens und dokumentierten Mustern, auf die sowohl Designer als auch Entwickler zurückgreifen. Sie brauchen wahrscheinlich eines, wenn Sie ein Produkt mit mehr als 15–20 Screens bauen, mehr als eine Person am Design oder Codebase arbeitet oder Sie planen, im Laufe der Zeit Screens hinzuzufügen. Ohne eines sind Design-Drift und Implementierungsinkonsistenz ab einer gewissen Größe nahezu unvermeidlich.
Wie lange dauert ein UX/UI-Design-Projekt?
Eine fokussierte Marketing-Website oder Landingpage dauert 1–3 Wochen. Ein Produkt-Interface-Projekt dauert 4–8 Wochen. Ein vollständiges Produktdesign mit Design-System und Prototyping kann 8–12 Wochen dauern. Die Zeitlinie wird durch den Umfang, die Anzahl der Feedback-Zyklen und die Geschwindigkeit bestimmt, mit der Stakeholder Reviews abschließen können.
Wir haben bereits ein Design. Können Sie es in Code umsetzen?
Ja. Wir prüfen die Dateien zunächst auf technische Machbarkeit, weisen auf alles hin, was während des Builds Probleme verursachen wird (unklare Zustände, fehlende mobile Breakpoints, Komponentenlücken), und bauen dann direkt darauf auf. Die Prüfung ist Teil des Auftrags, keine separate Gebühr.
Haben Sie ein Projekt im Sinn? Kontaktieren Sie unser Team oder fordern Sie ein technisches Audit an, wenn Sie mit einem bestehenden Produkt starten, das ein Design-Review benötigt.
