Was macht ein UX Designer in der freien Wirtschaft wirklich? Ein Realitätscheck

Ich muss dich enttäuschen - oder vielleicht auch erleuchten. Die Realität in der freien Wirtschaft, besonders wenn du für Schwergewichte wie Mercedes-Benz, Hilti oder Schaeffler arbeitest, sieht anders aus. Sie ist härter, technischer und deutlich weniger "bunt". Aber sie ist auch verdammt viel spannender.

Ich bin Alex Friedl, UX Professional und Full Stack Developer. Ich bewege mich seit über einem Jahrzehnt an der Schnittstelle zwischen Design und Code. Ich habe komplexe Systeme für die Automobilindustrie entworfen, Biotech-Portale optimiert und erlebt, wie Software in der Fabrikhalle wirklich genutzt wird. In diesem Artikel räume ich mit Mythen auf und zeige dir, was UX Design in der Praxis bedeutet - abseits von Dribbble-Shots und Lehrbuch-Theorie.

Der Mythos vs. Die Realität: Du bist ein Jongleur

Wenn mich jemand fragt, was ich den ganzen Tag mache, könnte ich sagen: "Ich mache Software hübsch." Das wäre gelogen. Die Wahrheit ist: Ich bin ein Jongleur für Informationen.

In der freien Wirtschaft, speziell im B2B-Sektor und in der Industrie 4.0, arbeitest du selten an der nächsten hippem Lifestyle-App. Du arbeitest an Systemen, die funktionieren müssen.

• Bei Mercedes-Benz ging es um PLS- und MES-Systeme für 166.000 Mitarbeiter.
• Bei Schaeffler ging es um intelligente Supply-Chain-Simulationen und Produktionssteuerung.

Hier geht es nicht primär um Ästhetik. Es geht darum, Informationsflüsse zu bändigen. Du stehst in der Mitte von verschiedenen Kräften:

1. Die Nutzer: Die oft gestresst sind und ihre Arbeit erledigen wollen.
2. Die Technik: Die Grenzen hat (Legacy Code, Framework-Limits).
3. Das Business: Das Budgetvorgaben und Deadlines diktiert.

Deine Aufgabe ist es nicht, Kunst zu erschaffen. Deine Aufgabe ist es, diese Bälle in der Luft zu halten, ohne dass einer runterfällt. Du musst Barrieren erkennen und Lösungen finden, die technisch machbar, wirtschaftlich sinnvoll und für den Menschen bedienbar sind.

---

Kapitel 1: Warum du für diesen Job kein Studium brauchst

Eine der häufigsten Fragen, die ich höre (und die wir auch im Podcast besprochen haben), ist: "Was muss ich studieren, um UX Designer zu werden?"

Meine ehrliche, vielleicht unpopuläre Antwort: Gar nichts.

Ich selbst habe zwar einen Hintergrund in Informatik und als Mediengestalter, aber das echte UX-Wissen? Das habe ich mir "Learning by doing" angeeignet. Ein Studium bereitet dich oft auf eine ideale Welt vor, die es da draußen nicht gibt. Die Disziplinen im UX sind so vielfältig - von Research über Interaction Design bis hin zu technischer Implementierung -, dass kein Studiengang der Welt alles abdecken kann.

Die "Netten Menschen im Internet"

Das Wissen liegt auf der Straße - oder besser gesagt: im Netz. Es gibt so viele "nette Menschen, die ihr Wissen im Internet veröffentlichen".

• Tutorials & Case Studies: Lies dir durch, wie andere Probleme gelöst haben.
• Community: Tausche dich aus.
• Praxis: Bau etwas. Egal was.

Das Wichtigste ist die Neugier. Du musst bereit sein, dich in Probleme zu verbeißen. Ein Zertifikat an der Wand hilft dir nicht, wenn du vor einem komplexen Dashboard für eine Labor-Software stehst und der Nutzer nicht versteht, wie er eine Probe anlegt. Da hilft nur Erfahrung, gesundes Menschenverstand und die Fähigkeit, sich selbst Wissen anzueignen.

Merke: Passion schlägt Papier. In meinen Projekten als Freelancer hat mich noch nie jemand nach meinem Notendurchschnitt gefragt. Sie wollten sehen: Kann Alex das Problem lösen? Hat er verstanden, worum es geht?

---

Kapitel 2: Arbeit am und mit dem Nutzer (Die harte Schule)

Viele Designer verlieben sich in ihre eigenen Entwürfe. Das ist der tödliche Fehler Nummer eins. In der freien Wirtschaft bist du nicht der Nutzer. Du bist der Dienstleister für den Nutzer.

Raus aus dem Elfenbeinturm

Bei Schaeffler habe ich gelernt, was "Human-Centered Design" wirklich bedeutet. Es bedeutet nicht, im Büro zu sitzen und Annahmen zu treffen. Es bedeutet:

• On-Site Observations: Geh dorthin, wo die Software genutzt wird. In die Fabrikhalle. An das Fließband. In das Labor.
• Der Kontext entscheidet: Eine Software mag auf deinem 27-Zoll-Monitor im klimatisierten Büro toll aussehen. Aber funktioniert sie auch auf einem Tablet, das von einem Mitarbeiter mit Handschuhen in einer lauten Umgebung bedient wird?

Die Kunst der neutralen Frage

Wenn du mit Nutzern sprichst, ist dein größter Feind deine eigene Voreingenommenheit.

• Falsch: "Findest du nicht auch, dass dieser Button hier super platziert ist?" (Das ist Suggestion).
• Richtig: "Was würdest du tun, um den nächsten Schritt einzuleiten?"

Du musst lernen, neutrale Fragen zu stellen und objektiv zu beobachten. Nutzer wollen dir oft gefallen. Sie sagen: "Ja, das sieht schön aus." Aber in Wahrheit wissen sie nicht, wie sie es bedienen sollen. Im Podcast sprach ich über den Fünf-Sekunden-Test. Zeige einem Nutzer dein Design für fünf Sekunden. Nimm es weg. Frag ihn: "Worum ging es auf der Seite?" Wenn er es nicht sagen kann, ist dein Design gescheitert. Egal wie "hübsch" es war.

Kritikfähigkeit: Leg dein Ego an der Tür ab

Das ist vielleicht der härteste Teil des Jobs. Du arbeitest wochenlang an einem Konzept, erstellst Wireframes und High-Fidelity Prototypen in Figma. Du bist stolz. Dann testest du es - und der Nutzer scheitert. Ein schlechter Designer verteidigt sein Design: "Der Nutzer hat es nur nicht richtig versucht." Ein guter UX Designer in der Wirtschaft sagt: "Okay, das Design hat versagt. Warum? Lass uns das fixen."

Bei Hilti oder Merck zählen am Ende harte KPIs. Konnte der Nutzer sich einloggen? Wurden die Support-Anfragen reduziert? Bei einem Projekt für Merck konnten wir durch UX-Optimierung die Support-Anfragen um 40% senken. Das ist der Wert von UX - nicht, ob der Schatten unter dem Button 2px oder 4px groß ist.

---

Kapitel 3: Technik und Design Systeme - Warum "Pixel schubsen" nicht reicht

Hier trennt sich die Spreu vom Weizen. Es gibt viele UX Designer, die tolle Bilder in Figma malen können. Aber in der freien Wirtschaft müssen diese Bilder zu Code werden. Und genau hier liegt meine Stärke als Full Stack Developer & UX Professional.

Anforderungen vs. Designer Gusto

Du wirst oft erleben, dass deine visionären Design-Ideen an der technischen Realität zerschellen.

• "Können wir das animieren, wenn sich das Menü öffnet?" - Der Entwickler sagt: "Klar, kostet aber 3 Tage extra und zieht die Performance auf den alten Industrie-Tablets runter."
• "Können wir hier eine komplett neue Navigation bauen?" - Der Product Owner sagt: "Nein, wir nutzen das Standard-Framework, das gibt das nicht her."

Es ist essenziell, dass du die technischen Limits kennenlernst. Wenn du verstehst, wie HTML, CSS und JavaScript (oder Frameworks wie Angular und React) funktionieren, wirst du ein besserer Designer. Du entwirfst Lösungen, die baubar sind.

Das Machtinstrument: Design Systeme

In großen Konzernen wie Zeppelin oder Bosch erfindest du das Rad nicht neu. Du arbeitest mit Design Systemen. Ich habe mehrfach White-Label UI Libraries und Komponenten-Kataloge aufgebaut, oft basierend auf Storybook.

• Konsistenz ist King: Ein Button muss auf Seite 1 genauso aussehen und funktionieren wie auf Seite 500.
• Effizienz: Entwickler sollen nicht jedes Mal CSS schreiben müssen. Sie nehmen die fertige Komponente aus der Library.
• Deine Aufgabe: Du musst verstehen, welche UI-Patterns in der Welt anerkannt sind. Wie funktioniert ein Dropdown? Wie verhält sich ein modales Fenster? Halte dich an etablierte Regeln (wie Material Design), damit Nutzer sich sofort zurechtfinden.

Wenn du als UX Designer verstehst, wie man eine Headless Component in React baut oder wie man Barrierefreiheit (WCAG) direkt im Code sicherstellt, bist du für das Unternehmen unbezahlbar. Du bist dann nicht mehr derjenige, der "Bilder malt", sondern derjenige, der das Produkt baut.

---

Kapitel 4: UX im Business-Kontext - Der Kampf um den ROI

Kommen wir zum Elefanten im Raum: Geld. In der freien Wirtschaft ist UX kein Selbstzweck. Niemand bezahlt dich, nur damit die Software nett aussieht. Du wirst bezahlt, damit das Unternehmen effizienter wird, mehr verkauft oder Kosten spart.

"Muss das sein?" - Die Frage aller Fragen

Du wirst oft in Meetings sitzen, wo du eine tolle UX-Lösung präsentierst, und ein Manager fragt: "Muss das sein? Ist es das wert, was es kostet?" Das ist keine Bosheit. Das ist wirtschaftliches Denken.

• Ist dieses Feature ein Showstopper? (D.h. ohne das Feature kann das Produkt nicht genutzt werden).
• Oder ist es "Nice to have"?
• Geht es auch in einer einfacheren Form mit geringerer UX, aber dafür in halber Entwicklungszeit?

Als UX Designer musst du lernen, diese Abwägungen zu treffen. Du musst verstehen, wann du kämpfen musst (wenn die Usability so schlecht ist, dass Fehler passieren) und wann du Kompromisse eingehen kannst.

UX Messen: Die Suche nach dem Beweis

UX zu messen ist schwer bis unmöglich - so zumindest das Klischee. Aber du solltest es IMMER versuchen. In meinen Projekten suche ich immer nach Anhaltspunkten:

• Task Completion Rate: Wie viele Nutzer schaffen den Vorgang "Probe anlegen" im LIMS-System ohne Hilfe?
• Time on Task: Wie lange brauchen sie dafür?
• Support-Tickets: Siehe das Beispiel bei Merck (Reduzierung um 40%).
• Adoption Rate: Nutzen die Leute das neue Feature überhaupt?

Wenn du UX mit Zahlen belegen kannst, hören dir auch die Geschäftsführer zu. Dann bist du kein "Designer" mehr, sondern ein strategischer Partner.

---

Kapitel 5: Der Prozess - Theorie vs. Agile Realität

Im Studium oder in Bootcamps lernst du den heiligen Gral des UX-Prozesses: den Double Diamond. Entdecken, Definieren, Entwickeln, Liefern. Alles schön sauber getrennt.

Willkommen in der Realität. In der freien Wirtschaft, besonders in agilen Umgebungen, ist der Double Diamond oft eher ein "Double Scribble". Warum? Weil Zeit Geld ist.

Das Überleben in Sprints

In meinen Projekten bei MediaMarkt oder Schaeffler arbeiteten wir oft in strikten Scrum-Sprints. Ein Sprint dauert meist zwei Wochen.

• Die Theorie: Du machst erst wochenlang Research, dann Wireframes, dann Tests, dann Design.
• Die Praxis: "Wir brauchen das Feature in Sprint 3." Du hast keine drei Wochen für Research. Du hast drei Tage.

Du musst lernen, pragmatisch zu sein. Du musst Schritte überspringen können, ohne die Qualität zu opfern.

• Statt einer riesigen Studie machst du Guerrilla-Testing (wie den "Coffee Test" bei Schaeffler). Geh in die Kaffeeküche, schnapp dir einen Kollegen, zeig ihm den Entwurf.
• Du arbeitest nicht vor den Entwicklern, sondern mit ihnen. Während du noch am Feinschliff des UIs arbeitest, bauen sie schon das Gerüst. Das erfordert ständige Kommunikation.

Als Deputy Product Owner bei Schaeffler habe ich gelernt: Du musst das Backlog priorisieren. Nicht alles, was wünschenswert ist, ist machbar. Du musst lernen, "Nein" zu sagen oder "Später", um den Release-Termin nicht zu gefährden. Das ist echtes UX Management.

---

Kapitel 6: Soft Skills - Deine wahre Superkraft

Ich habe es im Podcast gesagt und ich sage es hier wieder: Soft Skills schlagen Hard Skills. Jeder kann lernen, Figma zu bedienen. Aber nicht jeder kann mit frustrierten Stakeholdern umgehen oder Entwickler motivieren.

Der Übersetzer

Du bist das Bindeglied. Du sprichst zwei Sprachen:

1. Business: KPIs, Conversion Rates, Deadlines.
2. Tech: Komponenten, API-Calls, Refactoring.

Wenn du diese beiden Welten nicht verstehst, wirst du zerrieben. Du musst dem Manager erklären, warum das Refactoring der Code-Base wichtig für die UX ist (schnellere Ladezeiten). Und du musst dem Entwickler erklären, warum der "kleine" UI-Change wichtig für das Business ist (höhere Conversion).

Echtes Interesse und Empathie

Empathie ist ein Buzzword, aber es ist essenziell. Du musst echtes Interesse an anderen Menschen haben.

• Wie fühlt sich der Lagerarbeiter, der deine Software 8 Stunden am Tag nutzt?
• Wie fühlt sich der Entwickler, der unter Zeitdruck steht?

Wenn du nicht verstehst, was dein Team und deine Nutzer bewegt, wirst du Lösungen bauen, die keiner will oder keiner bauen kann.

Umgang mit Zweifeln

Es gibt Tage, da fühlst du dich nutzlos. Du bist "nicht direkt am Geschehen", schreibst keinen Produktiv-Code, verkaufst nichts direkt. Zweifel gehören dazu. Die Kunst ist, sie zu nutzen. Hinterfrage deine Arbeit kritisch, aber lass dich nicht lähmen. Dein Wert liegt darin, dass du das "Warum" und das "Wie" definierst, bevor das "Was" gebaut wird. Das spart dem Unternehmen Millionen an Fehlentwicklungen.

---

Kapitel 7: Einblicke in den Maschinenraum - Konkrete Fälle

Genug der Theorie. Lass uns zwei Beispiele aus meiner Praxis anschauen, die zeigen, wie vielfältig der Job wirklich ist.

Case 1: Schaeffler - Die intelligente Supply Chain

Das Problem: Wie simuliert man Lieferketten-Alternativen für ein Unternehmen mit 120.000 Mitarbeitern? Es gab keine Standard-Software dafür. Die Lösung: Wir bauten ein Tool ("ISS" - Intelligently Simulate Supply Chain Alternatives), das komplexe Daten auf einer Karte visualisiert. Meine Rolle: Hier war ich nicht nur Designer. Ich war UX Lead und Frontend-Entwickler.

• Ich musste verstehen, wie Logistik-Planer denken.
• Ich musste eine Oberfläche in Angular bauen, die performant tausende Datenpunkte auf einer Karte darstellt.
• Das Ergebnis war nicht nur "hübsch", es war ein Werkzeug, das Entscheidungen im Millionenwert ermöglichte. Hier traf Business-Logik auf Interface-Design.

Case 2: Merck - Biometrischer Login

Das Problem: Nutzer vergaßen ihre Passwörter für das Credential Portal ständig. Das Resultat: Die Support-Hotline glühte. Die Lösung: Einführung eines passwortlosen Logins (Biometrie). Der Erfolg: Durch strategisches Redesign und Fokus auf Usability konnten wir die Support-Anfragen um 40% senken. Das ist ein harter Business-Value. UX hat hier direkt Kosten gespart. Das Argument "UX kostet nur Geld" wurde hier eindrucksvoll widerlegt.

---

Fazit: Jongleur, Architekt, Mensch

Was macht ein UX Designer in der freien Wirtschaft also wirklich?

Er malt keine Bilder. Er löst Probleme.

• Er versteht den Code, um Machbares zu entwerfen.
• Er versteht das Business, um Wirtschaftliches zu bauen.
• Er versteht den Menschen, um Nutzbares zu erschaffen.

Dieser Job ist anstrengend. Du wirst gegen Windmühlen kämpfen (Budgets, Legacy-Code, Meinungen). Aber wenn du dann in die Fabrik gehst und siehst, wie jemand deine Software nutzt und sagt: "Hey, das ist ja viel einfacher als vorher" - dann weißt du, warum du es machst.

Du brauchst kein Studium. Du brauchst Neugier, Frustrationstoleranz und den Willen, Dinge wirklich zu verstehen.

Wenn du bereit bist, diesen Weg zu gehen - oder Unterstützung bei deinem Projekt brauchst, bei dem UX nicht nur "Deko", sondern Kernbestandteil sein soll: Lass uns reden.