Diese 4 Anzeichen zeigen dir gute UX-Arbeit, bevor du sie beauftragst

Ein Portfolio sieht fast immer gut aus. Die Screens sind sauber, die Cases klingen rund. Trotzdem weißt du nach dem ersten Gespräch oft nicht, ob diese Person deinem gewachsenen Produkt wirklich helfen kann oder ob sie nur ein modernes Design drüberlegt. Woran du das erkennst, steht nicht im Portfolio. Es zeigt sich im Gespräch und in den ersten Tagen einer Zusammenarbeit.

Wer einen UX-Designer sucht, hat selten eine eigene UX-Abteilung, die mitbeurteilt. Die Entscheidung fällt über ein Portfolio, ein bis zwei Gespräche und ein Bauchgefühl. Ob deine Entscheidung die Richtige war, merkst du meist nicht sofort. Du merkst es nach ein paar Wochen. Das Geld ist ausgegeben, die Screens sind neu gestaltet, aber das ursprüngliche Problem ist noch immer vorhanden. Der Support beantwortet dieselben Fragen wie vorher. Neue Nutzer brauchen genauso lange, bis sie zurechtkommen. Du stehst praktisch wieder am Anfang.

Diesen Fehler vermeidest du, wenn du auf die richtigen Dinge achtest. Vier Punkte entscheiden und keiner davon steht in einem Portfolio. Genau auf diese vier gehe ich in diesem Artikel ein.

Artikelübersicht

Das Problem kommt vor den Screens

Achte im ersten Gespräch darauf, womit die Person startet. Geht es sofort um Layout, Komponenten und Design, denkt die Person nur daran, deine Oberfläche hübscher zu machen. Kommen hingegen zuerst konkrete Fragen, wo dein Produkt klemmt, wer deine Nutzer sind und was sie nicht verstehen, beginnt die Person direkt beim Problem.

Dieser Unterschied entscheidet, was du am Ende bekommst. Denn wer nur an die Designrichtung denkt und mit dem Layout beginnt, liefert am Ende auch nur ein modernes Design. Wer mit dem Problem beginnt, gezielte Fragen stellt und mit dir in den Austausch geht, sortiert erst die Struktur. Das Design kommt erst wenn dieser Schritt vollständig verstanden ist und ein Weg gefunden wurde, dass Problem zu beheben.

Bei gewachsener Software ist ersteres ein teurer Fehler. Ein neues Design auf einer unklaren Struktur sieht für ein paar Wochen frischer aus. Das Problem bleibt jedoch bestehen. Neue Nutzer brauchen weiterhin zu lange, um eine Aktion auszuführen und im schlimmsten Fall erhält der Support noch immer die Fragen, die die Überarbeitung lösen sollte.

Der Preis steht, bevor du fragen musst

Das erste Anzeichen zeigt sich im Gespräch. Das zweite, sobald es um Geld geht. Frag daher früh nach dem Preis und achte darauf, wie schnell eine klare Antwort kommt. Wer seine Arbeit kennt, kann sie eingrenzen. Du hörst dann, was für welches Geld geliefert wird und was nicht, oft bevor du die Frage zu Ende gestellt hast.

„Das kommt ganz darauf an“ ist als erster Satz in Ordnung. Bleibt es dabei, wird es zum Warnzeichen. Manchmal fehlt dem Designer die Erfahrung, um den Aufwand einzuschätzen. Manchmal bleibt der Umfang mit Absicht offen, damit die Rechnung später Raum hat zu wachsen.

Wichtiger als die Zahl selbst ist, wie der Umfang auf dich zugeschnitten ist. Ein einziges großes Paket über mehrere Monate verlangt von dir, das ganze Risiko vorab zu tragen. Ein klar abgegrenzter erster Schritt mit eigenem Ergebnis lässt dich nach diesem Schritt entscheiden, ob du weitermachst oder nicht.

Bei mir läuft das zum Beispiel so: Zum Einstieg biete ich einen kleinen UX-Audit an. Darin geht es um konkrete Verbesserungen an einem Flow in deiner Anwendung. Der Rahmen ist bewusst begrenzt, das Ergebnis bringt dir trotzdem einen handfesten Nutzen. Du siehst in kurzer Zeit, wie ich arbeite und was ich abliefere. Danach hast du konkrete Ergebnisse in der Hand, mit denen dein Team weiterarbeiten kann.

Das Risiko bleibt überschaubar. Du verbrennst kein Budget, sondern investierst einen kleinen Betrag und kannst danach klar einschätzen, ob die Zusammenarbeit etwas bringt. Steht die Person zu dem, was sie verspricht, oder redet sie nur.

Die Arbeit endet nicht mit einer „schönen“ Datei

Bis hierhin hast du nur geredet. Das nächste Anzeichen zeigt sich erst, wenn wirklich gearbeitet wird. Eine fertige Designdatei ist kein fertiges Produkt. Dazwischen liegt die Übergabe an die Entwicklung, und genau hier entscheidet sich, ob aus dem Entwurf das wird, was du im Gespräch gesehen hast. Frag deshalb früh, wie die Zusammenarbeit mit deinen Entwicklern aussehen soll. Die Antwort verrät dir mehr über die Erfahrung einer Person als jedes Portfolio.

Wer Erfahrung hat, redet von Anfang an auch über Sonderfälle oder Fehlermeldungen, die in einem durchschnittlichen Entwurf gern fehlen:

  • Eine Liste ist im Design immer gefüllt, im echten Produkt ist sie manchmal leer
  • Ein Textfeld zeigt im Entwurf den perfekten Satz, im Alltag steht dort ein Name mit dreißig Zeichen oder eine Fehlermeldung
  • Eine Verbindung ist beim Nutzer manchmal langsam oder bricht ab

 

Wer nur die Standardfälle zeigt, hat die halbe Arbeit gemacht und überlässt deinen Entwicklern die andere Hälfte.

Was dann passiert, sehe ich in fast jedem Projekt mit gewachsener Software. Die offenen Stellen landen als Rückfragen in deinem Team oder als schnelle Behelfslösung im Code. Jeder Entwickler löst sie ein bisschen anders. Nach ein paar Monaten hast du für dasselbe Problem drei verschiedene Lösungen im Produkt und keine davon stand je in einem Entwurf. Genau so entsteht die Reibung, die du eigentlich loswerden wolltest.

Damit aus einem Design eine funktionierende Software wird, müssen deine Entwickler wissen, was bei jedem Klick passiert, was der Nutzer bei einem Fehler sieht und wie der Bildschirm aussieht, wenn noch keine Daten da sind.

Frag deshalb nicht nur, was am Ende geliefert wird. Frag, was deine Entwickler bekommen, um damit zu arbeiten. Eine erfahrene Person liefert diese Antworten von sich aus mit. Sie übergibt das Design so, dass dein Team direkt loslegen kann.

Bekommst du nur ein schönes Design und sonst nichts, müssen deine Entwickler die offenen Fragen selbst klären. Sie raten oder fragen nach. Das kostet Zeit und es passiert meist dann, wenn der Designer schon bezahlt ist und am nächsten Projekt sitzt. Am Ende erledigt dein Team die Arbeit, die eigentlich zur Übergabe gehört hätte.

Wer alles liefert, hat nichts verstanden

Das vierte Anzeichen zeigt sich, wenn du im Gespräch eigene Wünsche einbringst. Achte dann darauf, ob die Person alles abnickt oder ob sie analysiert und sortiert.

Hier ist der Grund, warum diese Reaktion so viel über die Arbeitsweise einer Person verrät. In gewachsener Software war jeder einzelne Wunsch einmal sinnvoll. Genau deshalb ist dein Produkt über die Jahre so unübersichtlich geworden. Für jede Funktion gab es irgendwann einen guten Grund, sie einzubauen. Wer jetzt zu jedem neuen Wunsch Ja sagt, setzt diese Entwicklung fort. Am Ende hast du wieder ein Produkt, in dem alles steckt und niemand mehr durchblickt.

Eine erfahrene Person bremst dich an dieser Stelle. Sie hört sich deine Wünsche an und ordnet sie nach ihrer Wirkung. Sie sagt dir, was zuerst dran ist, was warten kann und was dem eigentlichen Ziel sogar im Weg steht.

Diese Sätze klingen so:

  1. „Das bauen wir, aber nicht zuerst.“
  2. „Den Wunsch verstehe ich. Er macht das Problem aber größer, nicht kleiner.“
  3. „Bevor wir das Umsetzen, sollten wir wissen, ob deine Nutzer es überhaupt brauchen.“

 

Im ersten Moment ist das unbequem. Du willst eine Lösung und bekommst Widerspruch. Dieser Widerspruch ist aber das eigentliche Anzeichen. Wer dir widerspricht, hat sich mit deinem Produkt beschäftigt und denkt an das Ergebnis. Wer alles abnickt, will das Gespräch angenehm halten und den Auftrag nicht gefährden.

Am Ende bleibt sonst die wichtigste Aufgabe bei dir liegen. Denn die Entscheidung, was zuerst gelöst wird und was nicht, ist bei gewachsener Software die eigentliche Arbeit. Genau die sollte die Person übernehmen, die du dafür bezahlst.

Worauf es am Ende ankommt

Keines der vier Anzeichen steht in einem Portfolio. Sie zeigen sich erst, wenn du mit jemandem sprichst und zusammenarbeitest. Das erste im Gespräch, wenn du hörst, ob die Person beim Problem oder bei der Oberfläche beginnt. Das zweite beim Preis, wenn sie den Umfang klar eingrenzt statt auszuweichen. Das dritte bei der Übergabe an deine Entwickler, wo sich zeigt, ob jemand das Produkt zu Ende denkt. Das vierte in dem Moment, in dem dir jemand widerspricht, statt jeden Wunsch abzunicken.

Die gute Nachricht: Du musst dafür kein UX-Wissen mitbringen. Du musst die Arbeit nicht selbst beurteilen können. Du musst nur die richtigen Fragen stellen und darauf achten, woran die Antworten hängen. Frag, wo dein Produkt aus Sicht der Person klemmt. Frag, was sie für welches Geld liefert. Frag, wie die Übergabe an deine Entwickler abläuft. Und bring einen Wunsch ein, von dem du selbst nicht sicher bist, ob er klug ist. Die Reaktionen sagen dir mehr als jede Referenz.

Ein letzter Gedanke zur Einordnung. Diese vier Anzeichen sind kein Punktesystem, bei dem vier von vier die perfekte Wahl bedeuten. Sie sind ein Muster. Wenn jemand beim Problem beginnt, den Preis eingrenzt, die Übergabe mitdenkt und dir auch mal widerspricht, dann hast du es mit jemandem zu tun, der gewachsene Software wirklich verstanden hat. Solche Leute sind selten, und sie sind ihren Preis wert.

Wenn du den Anfang trotzdem klein halten willst, musst du nicht gleich ein großes Projekt vergeben.

Ein kurzer UX-Audit reicht als erster Schritt. Du nimmst einen echten Ausschnitt deines Produkts, etwa einen Flow, an dem sich Nutzer regelmäßig verschlucken, und lässt ihn dir ansehen. Du bekommst konkrete Verbesserungen und siehst gleichzeitig, wie die Person arbeitet. Das Risiko bleibt klein, der Nutzen ist sofort da, und du weißt danach, ob eine größere Zusammenarbeit Sinn ergibt.

Jetzt UX-Review beauftragen

Manuela Aksu Ich bin Manuela, freiberufliche UX/UI-Designerin aus München. Seit 2013 bin ich selbständig und arbeite an gewachsenen B2B-Webanwendungen und bringe sie zurück in eine klare Struktur. Hier im Blog schreibe ich über Reibung in Software und über die Annahmen in der Produktarbeit, die immer wieder in die Irre führen. Außerdem gebe ich Einblicke, wie ich an diese Themen herangehe.

Kommentar absenden

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Notizen aus der Praxis

Einmal pro Woche schreibe ich über ein Reibungssymptom aus meiner Arbeit an B2B-SaaS und wie es sich lösen lässt. Kurz, konkret, ohne Umschweife. Für Product Owner, CTOs und Gründer, die ihr Produkt klarer machen wollen.

Alle wichtigen Infos, was mit deinen Daten passiert, erhältst du ausführlich auf dieser Seite.

Bitte aktualisiere deine Cookie-Einstellungen, um meinen Kalender zu öffnen. Mit der Aktivierung werden Cookies von Calendly und verknüpften Diensten gespeichert.
Speichern und Kalender öffnen