Artikel

Über B2B-Anwendungen und interne Tools, die zwei Arten von Software, deren Nutzer:innen nicht weglaufen können. Und warum das eure offene Flanke ist.

Einen Satz höre ich in Projekten regelmäßig, meist von jemandem mit Budgetverantwortung und meist mit einem leicht entschuldigenden Lächeln:

„Das ist halt B2B.“

Gemeint ist: Hier muss es weder schön noch schnell sein. Hier muss man sich eben einarbeiten. Hier gelten andere Maßstäbe.

Das stimmt sogar, es gelten andere Maßstäbe. Nur nicht die, die ihr meint.

Im Consumer-Bereich entscheiden die Nutzer:innen. Ist die App schlecht, ist sie weg. Im B2B entscheidet der Einkauf, und die Nutzer:innen bekommen das Ergebnis zugewiesen. Sie können nicht kündigen und nicht wechseln. Nicht mal meckern geht, ohne dass es nach Arbeitsverweigerung klingt. Also halten sie es aus, und dafür bekommen sie am Monatsende Geld.

Viele B2B-Produkte leben deshalb vom Schmerzensgeld und nicht von ihrer Qualität.

Dasselbe gilt für die zweite Art Software ohne Ausweg, die ihr selbst baut: das Backend für die Sachbearbeitung, das Admin-Panel, das Reporting-Tool, das interne Buchungssystem, das seit 2014 „übergangsweise“ läuft. Ob eingekauft oder selbst gebaut, ist technisch ein Unterschied. Wirtschaftlich ist es derselbe Fall: Nutzer:innen ohne Exit.

Software, deren Nutzer:innen nicht gehen können, bekommt kein ehrliches Feedback. Die Leute gewöhnen sich einfach daran. Das ist etwas völlig anderes, wird in Statusmeetings aber gern verwechselt.

1. Warum „B2B-Benchmark“ die faulste Ausrede der Branche ist

Wer B2B-Oberflächen kritisiert, bekommt reflexhaft immer dieselbe Antwort: Vergleich uns doch mal mit dem Wettbewerb, dann sehen wir gar nicht schlecht aus.

Nur taugt der Wettbewerb nicht als Maßstab. Er sitzt im selben Keller wie ihr.

Wenn alle Anbieter einer Branche seit fünfzehn Jahren dieselben überladenen Screens bauen, sagt der Branchendurchschnitt nichts über Qualität. Er ist ein kollektives Alibi. „Besser als SAP“ ist ungefähr so ambitioniert wie „schneller als die Deutsche Bahn“.

Der echte Maßstab liegt woanders. Eure Nutzer:innen arbeiten ja nicht nur als Sachbearbeiter:innen, Disponent:innen oder Einkäufer:innen. Abends buchen sie in vier Sekunden ein Bahnticket, überweisen mit zwei Klicks Geld und starten einen Film mit null Klicks. Diese Erfahrung schalten sie um neun Uhr morgens nicht ab. Sie sitzen vor eurem Screen und wissen, dass es anders geht. Im Fachjargon heißt das seit fünfzehn Jahren Consumerization of IT. Gemeint ist die Erwartung, die eure Nutzer:innen jeden Morgen mitbringen und an eurem Login abgeben müssen.

Der Satz „für B2B ist das gut“ heißt in der Praxis: Wir haben unsere Nutzer:innen erfolgreich daran gewöhnt, weniger zu erwarten. Eine Haltung ist das nicht, eher ein Zustand.

Und eine niedrige Latte hat es nun mal an sich, dass man sehr leicht drüberkommt.

2. Die Rechnung, die niemand aufmacht

Bei Produkten für Kund:innen rechnen alle: Conversion, Cost per Order, Abbrüche im Warenkorb. Bei interner Software rechnet niemand. Dabei ist die Rechnung hier viel einfacher, weil die Nutzer:innen auf eurer Gehaltsliste stehen.

Ein paar Zahlen, damit die Größenordnung klar wird:

Die Harvard Business Review hat mit Forscher:innen zwanzig Teams aus drei Fortune-500-Unternehmen fünf Wochen lang beobachtet. Das Ergebnis: Die Leute wechselten rund 1.200 Mal am Tag zwischen Anwendungen und Fenstern. Allein die Zeit, um sich danach wieder zurechtzufinden, summierte sich auf etwa vier Stunden pro Woche. Das sind rund neun Prozent der Jahresarbeitszeit. Der Beitrag dazu bei HBR

Qatalog und das Ellis Idea Lab der Cornell University kommen in ihrer Befragung auf 9,5 Minuten, bis jemand nach einem Toolwechsel wieder produktiv arbeitet. Dazu kommt knapp eine Stunde pro Arbeitstag, die allein für die Suche nach Informationen in verschiedenen Systemen draufgeht. Zusammenfassung bei CIO Dive

Asanas Anatomy of Work geht noch weiter: Rund 60 Prozent der Arbeitszeit gehen für „work about work“ drauf, also für die Suche nach dem Status, das Zusammentragen von Informationen und das Springen zwischen Tools. Für die Arbeit, für die man die Leute eingestellt hat, bleiben 40 Prozent.

Rechnet das mal grob für euch durch:

Nehmen wir 200 Mitarbeiter:innen. Alle verlieren durch eine schlecht gestaltete Kernanwendung 15 Minuten pro Tag, und gemessen an den Zahlen oben ist das konservativ. Im Unternehmen sind das 50 Stunden pro Tag, bei 220 Arbeitstagen 11.000 Stunden. Bei 60 Euro Vollkosten pro Stunde macht das 660.000 Euro im Jahr.

Und das jedes Jahr aufs Neue. In keiner Präsentation taucht es auf, weil verlorene Zeit keine Kostenstelle hat.

Dagegen steht ein UX-Projekt, das euch je nach Umfang einen niedrigen fünfstelligen Betrag kostet. Seine Wirkung könnt ihr sogar messen: Bearbeitungszeit pro Vorgang, Fehlerquote, Zahl der Rückfragen im Second-Level-Support, Dauer der Einarbeitung neuer Mitarbeiter:innen.

Das ist übrigens der bequemste Business Case in unserem Fach. Er kommt ohne Marktforschung aus. Alle Daten habt ihr schon im Haus. Ihr habt sie nur noch nie jemandem gezeigt, der etwas damit anfangen kann.

3. Interne Tools: der blinde Fleck mit System

Warum sieht die interne Anwendung aus wie 2009, während die Kampagnenseite für dasselbe Produkt im Award-Buch steht?

Weil interne Software niemandem gehört, dessen Bonus davon abhängt.

Externe Produkte haben einen Product Owner, ein Marketingbudget, KPIs und einen Vorstand, der auf die Zahlen schaut. Interne Tools haben ein Fachkonzept. Die Anforderungen kommen aus der Fachabteilung, die Umsetzung aus der IT. Das Design macht niemand. Ohne Conversion gibt es keine Diskussion, nur Tickets.

Die typischen Symptome, und ich wette, ihr erkennt mindestens drei davon:

• Ein Screen mit 60 Feldern, weil man ihn „aus dem Altsystem übernommen“ hat.
• Fehlermeldungen, die eine Nummer nennen und sonst nichts.
• Fachbegriffe aus dem Datenmodell in der Oberfläche, weil es einfacher war, das Feld genauso zu nennen wie die Spalte.
• Ein Excel-Sheet, das parallel zum offiziellen System geführt wird, weil das offizielle System den echten Workflow nicht abbildet.
• Eine Schulung, die es nur gibt, weil sich das Interface nicht selbst erklärt. Mit Schulungen bezahlt ihr teuer für Designarbeit, die nie gemacht wurde.
• Neue Kolleg:innen, die nach zwei Wochen immer noch fragen müssen.

Der letzte Punkt ist der teuerste, und niemand rechnet ihn der Software zu. Dauert eure Einarbeitung sechs Wochen, weil die Anwendung unlogisch ist, bezahlt ihr diese sechs Wochen bei jeder einzelnen Neueinstellung. Und zwar für immer, bei steigender Fluktuation sogar öfter. Das sieht aus wie eine Personalfrage, ist aber ein Designfehler im Abo.

Und dann gibt es noch die stille Kündigung des Systems: Shadow IT. Wenn Leute anfangen, ihre Arbeit in privaten Tabellen, WhatsApp-Gruppen und selbst gebauten Tools zu organisieren, liegt das nicht an fehlender Disziplin. Es ist ein Usability-Report. Bei euch kommt er nur als Compliance-Verstoß an und nicht als Anforderung.

4. Kurzer Blick ins Recht, der zu selten fällt

Falls die Rechnung zur Produktivität nicht zieht: In Deutschland ist ergonomische Software am Arbeitsplatz eine Pflicht des Arbeitgebers und keine freundliche Geste.

Die Arbeitsstättenverordnung sagt im Anhang unter Nummer 6: Wer Bildschirmarbeitsplätze betreibt, muss als Arbeitgeber dafür sorgen, dass der Arbeitsplatz der Arbeitsaufgabe angemessen gestaltet ist und geeignete Softwaresysteme bereitstehen. Dort heißt es unter anderem auch: Die Software muss sich an Kenntnisse und Erfahrungen der Beschäftigten anpassen lassen, sie muss Angaben über die jeweiligen Dialogabläufe machen, und sie muss Fehler beschreiben sowie deren Beseitigung mit begrenztem Arbeitsaufwand erlauben. Gesetzestext bei gesetze-im-internet.de

Lest den letzten Halbsatz noch mal: „Fehlerbeseitigung mit begrenztem Arbeitsaufwand.“ Das ist im Kern eine Designanforderung. Und sie steht seit Jahrzehnten im Gesetz, zuerst in der Bildschirmarbeitsverordnung und seit 2016 in der ArbStättV.

Konkret beschreibt das die ISO 9241-110 mit den Interaktionsprinzipien für Dialogsysteme. In der Fassung von 2020 sind das Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Erwartungskonformität, Erlernbarkeit, Steuerbarkeit, Robustheit gegen Nutzungsfehler und Benutzerbindung. Das ist eine Norm, auf die sich Betriebsräte und Gewerbeaufsicht berufen können, und keine Designer-Lyrik.

Dazu kommt die Gefährdungsbeurteilung nach § 5 Arbeitsschutzgesetz. Sie umfasst ausdrücklich auch die Gestaltung von Arbeitsverfahren und -abläufen und psychische Belastungen bei der Arbeit. Eine Anwendung, gegen die Menschen acht Stunden am Tag anarbeiten, fällt in diese Kategorie. Dort taucht sie nur nie auf, weil niemand auf die Idee kommt, Software als Arbeitsmittel zu behandeln. Das ist sie aber.

Ich behaupte nicht, dass euch deswegen morgen jemand verklagt. Aber wenn ihr intern begründen müsst, warum Softwareergonomie kein Nice-to-have ist, habt ihr hier die kürzeste Begründung, die es gibt. Und sie steht im Arbeitsschutzrecht, nicht in einem Designblog.

5. Die offene Flanke: Es reicht, wenn sich jemand Mühe gibt

Jetzt kommt der Teil, der für Anbieter interessant ist und weniger für Anwender.

Wer B2B-Software verkauft, hält die niedrige Messlatte für einen Vorteil. Tatsächlich ist sie ein ungesichertes Tor.

Denn der Markt funktioniert inzwischen anders. Kaufentscheidungen im B2B fallen längst nicht mehr allein im Einkauf. Je nach Erhebung werden für eine typische Buying Group sechs bis zehn Beteiligte genannt, und die Endnutzer:innen sitzen inzwischen mit am Tisch. Ihr Kriterium ist immer dasselbe: Usability. In der Buyer-Behavior-Studie von G2 stehen einfache Implementierung, schneller ROI und Ease of Use ganz oben auf der Liste der Kaufkriterien. Und diese Zahl sollte euch wirklich interessieren: Nur rund 45 Prozent der Softwarekäufer:innen verlängern, ohne lange nachzudenken. Über die Hälfte prüft bei der Verlängerung aktiv Alternativen. G2 Software Buyer Behavior

Jede Vertragsverlängerung ist also ein kleiner Pitch, und ihr verliert ihn gegen jeden, der dasselbe kann und sich besser bedienen lässt. Weil eure Nutzer:innen ihren Frust seit Jahren aufstauen, braucht dieser Wettbewerber keinen langen Atem. Ihm reichen ein Testkonto und eine Demo, die im Meeting funktioniert.

Dazu kommen öffentliche Bewertungen. Früher blieb die Meinung der Nutzer:innen im Unternehmen. Heute steht sie auf Review-Portalen, und der Einkauf liest dort mit. Eure Nutzer:innen können euch nicht kündigen, aber sie können euch bewerten. Das ist mittlerweile fast dasselbe.

Und für die andere Seite, die interne: McKinsey hat für den Report Business Value of Design fünf Jahre lang 300 börsennotierte Unternehmen untersucht. Die Firmen im obersten Viertel des Design-Index kamen auf 32 Prozentpunkte mehr Umsatzwachstum und 56 Prozentpunkte mehr Wachstum bei der Aktionärsrendite als ihre Wettbewerber. Interessanter als die Zahl ist die Verteilung: Zwischen dem zweiten, dritten und vierten Quartil gab es kaum Unterschiede. Der Markt belohnt die, die deutlich rausstechen. Mittelmaß mit etwas Design belohnt er nicht. Zur Studie

Heißt für euch: Ein bisschen weniger hässlich bringt nichts. Der Sprung lohnt sich erst, wenn er auffällt.

6. Was ihr konkret machen könnt, ohne ein Transformationsprogramm auszurufen

Ich bin kein Freund von Zwölf-Monats-Roadmaps für Probleme, die man in vier Wochen anfassen kann. Deshalb konkret:

1. Setzt euch daneben. Keine Interviews, keine Umfragen. Setzt euch zwei Tage lang neben die Leute und schaut zu, wie sie echte Vorgänge bearbeiten. Ihr werdet Dinge sehen, die in keinem Ticket stehen: Zettel neben der Tastatur, Excel-Parallelwelten, auswendig gelernte Klickpfade. Ehrlicher wird eine Anforderungsanalyse nicht, und sie kostet fast nichts.

2. Messt die Top-5-Vorgänge. Was macht das Team am häufigsten? Wie lange dauert es, wie oft geht es schief? Danach priorisiert ihr, und zwar nach Häufigkeit mal Dauer. Wie laut sich jemand beschwert, zählt dabei nicht. Der 30-Sekunden-Vorgang, der 400 Mal am Tag läuft, schlägt jedes Feature, das im Lastenheft ganz oben steht.

3. Nehmt Felder raus. Das ist dieselbe Übung wie bei Formularen für Kund:innen, nur mit noch dickeren Altlasten. Fragt bei jedem Feld: Wer braucht das, wofür, und was passiert ohne? Und „das war schon immer so“ ist keine Antwort.

4. Setzt Smart Defaults. Vorbelegt sind der häufigste Wert, die gerade angemeldete Person und das heutige Datum. Das klingt banal, spart aber pro Vorgang Sekunden und pro Jahr Wochen.

5. Gebt der Sache einen Owner. Interne Tools scheitern meistens an der Zuständigkeit, selten am Können. Solange niemand das Mandat hat, einer Fachabteilung ein Feld wegzunehmen, passiert nichts.

6. Macht die Zahl sichtbar. Zeigt die Bearbeitungszeit pro Vorgang vorher und nachher, auf einer Folie. Diese eine Folie entscheidet darüber, ob es beim nächsten Mal wieder Budget gibt.

Warum ihr mir das glauben könnt

Ich bin Tobias Adam, Freelance UX/UI Designer in Hamburg. Seit 2016 arbeite ich als UX Designer in der digitalen Produktentwicklung.

Gelernt habe ich das Handwerk in Agenturen, unter anderem bei Jung von Matt und deepblue networks. Dort liegen Anspruch, Konzernrealität und Deadline gleichzeitig auf dem Tisch. Gearbeitet habe ich unter anderem für BMW, Audi, FIFA, Union Investment, Vodafone, OBI und die Deutsche Messe. Projekte mit meiner Beteiligung erhielten 20+ Auszeichnungen, darunter Webby, ADC, Lovie und Deutscher Digital Award.

Die Awards gab es für die sichtbaren Sachen. Am meisten gelernt habe ich bei den unsichtbaren: Antragsstrecken, Onboardings, Fachanwendungen, Registrierungen. Zum Beispiel bei der Depoteröffnung von VisualVest im Union-Investment-Umfeld. Dort mussten regulatorische Pflichtangaben und ein bedienbarer Flow gleichzeitig funktionieren. Oder bei einem digitalen Zukunftsplaner, der noch nicht veröffentlicht ist. Da ging es um die Frage, wie viel ein System den Nutzer:innen abnehmen darf, bevor es sie bevormundet.

Solche Projekte gewinnen keinen Award. Trotzdem entscheidet sich an ihnen, ob eine Firma effizient arbeitet oder nicht.

Heute arbeite ich freiberuflich und mit HC Merkle zusammen als intro.team. Wir sind zwei Freelancer für die Phase, in der aus einer Idee ein testbares Produkt wird, mit Konzept, UX, UI, Prototyp und Nutzertests. Wir arbeiten in kurzen Zyklen, senior besetzt und ohne Agenturapparat.

Die Kurzfassung

1. An Software ohne Exit gewöhnen sich die Leute, ehrliches Feedback bekommt sie nicht. Verwechselt Gewöhnung nicht mit Zufriedenheit.
2. „Für B2B ist das gut“ ist kein Benchmark. Eure Nutzer:innen vergleichen euch mit dem, was sie abends benutzen.
3. Interne Tools sind derselbe Fall wie eingekaufte Software. Ihre Nutzer:innen können nicht wechseln.
4. Rechnet die verlorene Zeit aus. 15 Minuten pro Tag mal Headcount mal Vollkosten. Die Zahl reicht als Antrag.
5. Mit Schulungen bezahlt ihr für fehlendes Design. Mit Second-Level-Tickets genauso.
6. Shadow IT ist ein Usability-Report, auch wenn sie als Compliance-Problem ankommt.
7. Softwareergonomie am Arbeitsplatz ist Arbeitsschutzrecht, keine Geschmackssache.
8. Die niedrige Messlatte lädt die Konkurrenz ein. Über die Hälfte eurer Kund:innen prüft bei der Verlängerung Alternativen.
9. Halbe Sprünge zahlen sich nicht aus. Der Markt belohnt die, die deutlich rausstechen.
10. Fangt bei den fünf häufigsten Vorgängen an. Nicht bei der Roadmap.

Software, deren Nutzer:innen nicht weglaufen können, wirkt wie ein sicherer Markt. Dort hat nur noch niemand angegriffen.

Im ersten Teil dieser Reihe ging es um Formulare, Feldanzahl und Smart Defaults. Also um dieselbe Frage bei Nutzer:innen, die sehr wohl weglaufen können.

Quellen und Weiterlesen

• Harvard Business Review: How Much Time and Energy Do We Waste Toggling Between Applications? (2022) – hbr.org
• Qatalog & Cornell University, Ellis Idea Lab: Studie zum App-Switching – ciodive.com
• Asana: Anatomy of Work Index – asana.com
• G2: Software Buyer Behavior Report – learn.g2.com
• McKinsey & Company: The Business Value of Design (2018) – mckinsey.com
• Arbeitsstättenverordnung, Anhang Nr. 6 (Bildschirmarbeitsplätze, Softwareanforderungen) – gesetze-im-internet.de
• DIN EN ISO 9241-110:2020-10: Interaktionsprinzipien – dinmedia.de