An diesem Tag war alles anders. Naja, nicht alles. Tatsächlich fast nichts. Aber fast nichts kann unglaublich dramatisch erscheinen, speziell wenn man ein geübter Beobachter ist.
Am Tag davor hatte unser User keine Probleme mit der Software-Anwendung. Während wir zuschauten, nutzte er sie stundenlang genau so, wie es der Intention der Entwickler entsprach.
Nun hatten wir alle Bedingungen des Vortags repliziert, doch die Art seiner Nutzung war komplett anders. Sein Verhalten hatte sich buchstäblich über Nacht verändert.
Bei unserem Studienteilnehmer handelte es sich um den Besitzer einer Autoreparatur-Werkstatt, die auf Auspuffe, Bremsen, Batterien und Reifen spezialisiert war. Die Anwendung, die er nutzte, war eine Kunden-Tracking-Software, die jedem Kunden über seinen Besuch hinweg folgte, die das Inventar verwaltete und die jeden Auftrag beschätzte und abrechnete. Sie machte praktisch alles.
Normalität: Freitag
Der Tag davor war ein Freitag gewesen. Was seinen Laden angeht, sind Freitage wie die meisten Werktage. Kunden kommen in einem gleichmäßigen Strom ins Geschäft. Manchmal gibt es am Morgen einen kleinen Andrang, aber die meisten Kunden haben Termine und sind bereits im System.
An diesem Freitag sahen wir dem Werkstattbesitzer beim Bearbeiten neuer Kunden zu. Er erfragte ihre Namen, die Marken, Modelle und Baujahre ihrer Autos und die Symptome ihrer Probleme. Sorgfältig und mit Bedacht gab er die richtigen Informationen ins System ein, das im Gegenzug eine ordentliche Schätzung der Arbeit ausgab.
Meistens entsprachen diese Schätzungen dem, was die Arbeit am Ende tatsächlich kostete. Ein Fakt, auf den der Besitzer stolz war. Und sehr oft lag die Schätzung niedriger als bei seinem direkten Konkurrenten, dessen Laden sich auf der anderen Straßenseite befand. Noch ein Fakt, der den Besitzer stolz machte.
Der Besitzer war kein besonders schneller Tipper. Und an diesem Freitag musste er das auch nicht sein. Es waren nie mehr als zwei Kunden gleichzeitig da. Er konnte all die Daten mit seinem Zwei-Finger-Suchsystem eingeben, wie er es meistens tat.
Zwischen den Kunden zeigte er uns, wie sehr er die Daten liebte, die das System trackte. Er konnte uns sagen, dass es saisonale Muster im Hinblick auf die benötigten Reparaturen gab. Auspuffe waren im Frühjahr angesagt, Reifen im Herbst, Batterien im Winter. Er konnte den Inventarbedarf vorhersagen und sicherstellen, dass er alles hatte.
Diese Anwendung machte sein Leben leichter, erzählte er uns stolz. Das sollte sie auch. Sie kostete eine Menge, wie er uns ebenfalls sagte.
Chaos: Samstag
Als wir am Samstag ankamen, gab es am Parkplatz bereits eine Schlange. Diese Leute waren neue Kunden, die gekommen waren, um neue Aufträge beschätzen zu lassen.
Hier ließ ihn die Anwendung im Stich. Statt die Daten in die Applikation einzutippen, nahm der Besitzer leere Formulare und füllte sie per Hand aus. Und statt die Informationen einzuholen, die die Anwendung brauchte, gab er sich bei jedem Kunden mit dem absoluten Minimum zufrieden.
Innerhalb von 20 Minuten hatte sich der Warteraum mit neuen Kunden gefüllt, alle auf der Suche nach einem Kostenvoranschlag. Um so schnell wie möglich zu sein, musste der Besitzer seine heißgeliebte Anwendung außen vor lassen. Wenn er diesen Leuten nicht half, würden sie über die Straße gehen und ihre Dinge dort erledigen. Das konnte er sich nicht leisten und ein Stück Software sollte ihm nicht im Weg stehen.
Am Samstag war die Software-Applikation, die er noch am Vortag gepriesen hatte, plötzlich sein Feind. Sie hielt ihn davon ab, seine Arbeit zu tun. Er nutzte Workarounds als Überbrückung.
Ins Service-Design hinein stolpern
Ohne Absicht waren wir in ein Service-Design-Problem hinein gestolpert. Zwischen Freitag und Samstag hatte sich die Anwendung nicht verändert. Der Nutzer war derselbe. Was sich geändert hatte, war der Kontext der Nutzung. Plötzlich war etwas, das einmal hilfreich gewesen war, zu einer Bremse geworden.
All das ist vor über 20 Jahren geschehen, und zu dieser Zeit hatten wir freilich noch nie von Service-Design gehört. (In jenen Tagen nutzten wir auch nie den Begriff "Nutzererlebnis". Es dauerte eine Dekade, bis das Schule machte.) Weil unsere Arbeit damals auf das Design von Software-Applikationen fokussiert war, war auch unsere Energie darauf fokussiert.
Aber wir konnten nicht ignorieren, dass unserem User Dinge passierten, die mit einem größeren Ganzen zusammenhingen. Und wir wussten nicht, was wir da tun konnten.
Heute würden wir es wissen. Was wir gesehen hatten, war ein klassisches Service-Design-Problem, und jetzt haben wir jede Menge Techniken und Tricks, um tolle Lösungen zu finden.
Heute finden sich viele User-Experience-Profis versehentlich bei der Arbeit im Service-Design wieder. Sie stolpern hinein, so wie uns das vor mehr als zwei Jahrzehnten ergangen war.
Service-Design ist eine Erweiterung des digitalen UX-Designs
Der Großteil unserer heutigen User-Experience-Arbeit dreht sich um irgendwelche digitalen Geräte. Sie hat mit Anwendungen oder Websites zu tun. Lösungen beinhalten das Herumbewegen von Bits auf einem Bildschirm.
Doch allerdings ist das nicht das Gesamterlebnis, das ein User hat. Unser Werkstattbesitzer tippte nicht nur Daten in einen Computer und produzierte Auswertungen. Für ihn ist das digitale Erlebnis nur ein Teil der gesamten Kundenservice-Erfahrung.
Wenn wir wirklich bessere Nutzererlebnisse erschaffen wollen, müssen wir wissen, wie wir bessere nicht-digitale Nutzererlebnisse erschaffen. Wir brauchen Werkzeuge und Techniken, um das zu tun, so wie die, die wir uns für unsere digitalen Nutzererlebnisse gefügig gemacht haben.
Im zweiten Teil des Artikels erörtert der Autor, inwiefern sich die Arbeit im Bereich des Service-Designs vom klassischen Ansatz des digitalen UX-Designs unterscheidet und welche Methoden dabei zielführend sind.
Dieser Artikel wurde im Original am 26. August 2014 unter dem Titel Service Design: Pushing Us Beyond the Familiar
