Versionskontrolle: Wie ein*e UX-Autor*in ein Wort gegen ein anderes abwägt
Im UX-Design kann ein einziges falsch platziertes Verb die Benutzer*innen in die Irre führen, ihre Erwartungen enttäuschen und Verwirrung stiften. Deshalb wählte der UX-Autor Henry Freedland seine Worte sehr sorgfältig, als er hinzugezogen wurde, um ein neues Prototyping-Feature zu optimieren.
Versionskontrolle: Wie ein*e UX-Autor*in ein Wort gegen ein anderes abwägt teilen
Hero-Illustration von Antonio Carrau
Das Entwerfen eines Produkts ist ein wenig wie das Erfinden neuer Naturgesetze. Du beschreibst ein Universum voller Aktivitäten, die darauf warten, in Gang gesetzt zu werden – von Menschen, Produkten, Maschinen und Code. Um zu verstehen, wie man sich in diesem Universum zurechtfindet, müssen die Menschen wissen, wie sich die anderen Akteure verhalten; mit anderen Worten, sie müssen wissen, was Fallen bedeutet, auch wenn sie die Schwerkraft nicht berechnen können. Als Disziplin versucht UX Writing dieses Gleichgewicht zu finden.
Das war meine Aufgabe, als wir auf die Bitte der Benutzer*innen eingingen, bitte – unbedingt und auf jeden Fall – eine Art Prototyp eines „Offline-Modus“ zu entwickeln. Georgia Rust, eine Produktmanagerin bei Figma, hatte Ingenieur*innen zusammengebracht, um eine einfache Arbeitsversion zu erstellen, die sie dann zusammen mit Produktdesigner*innen verfeinerte. Es schien kurz vor der Auslieferung zu stehen, wenn einige UI- und Leistungsprobleme gelöst werden könnten – aber zuerst brauchten sie nur ein paar Worte, um die neue Funktionalität und deren Nutzung zu erklären.
Als die UX-Autorin, die am Prototyping gearbeitet hat, wurde ich hinzugezogen, um bei einem Menübegriff zu beraten. Ich las die Diskussionen, die das Team geführt hatte, und dachte, Ah, mal wieder. Die Sprache hatte tiefgreifende Fragen darüber aufgedeckt, was wirklich vor sich ging.
Version eins: Was steckt dahinter?
Das, was wir heute als „Laden“ bezeichnen, ist ein Teilbereich vieler Arten von Ladevorgängen in der Geschichte der Computer. „Booten“ zum Beispiel ist eine verkürzte Form von "Bootstrap-Laden" – die Idee, dass ein Computer sich irgendwie selbst laden muss, um zu starten. Dieser Ausdruck bezieht sich auf die Redewendung aus dem 18. Jahrhundert, „sich an den eigenen Stiefelschlaufen hochziehen“.
Zunächst lautete der Platzhalter „Preload prototype“ – sehr präzise in Bezug auf die Programmierfunktion.
Prototypen werden normalerweise Bildschirm für Bildschirm geladen, während du mit ihnen interagierst, und nicht alle auf einmal. Mit dieser neuen Option kannst du alles im Voraus laden und so lange speichern, bis es präsentiert werden soll. Im Code wird die Verbesserung der Web-Performance durch das frühzeitige Sammeln wichtiger Assets als „Preloading“ (Vorladen) bezeichnet. Wenn du also technisch versiert bist, beschreibt dieses Verb die Erfahrung ziemlich gut.
Für alle anderen ist der Begriff „preload“ (vorladen) knifflig. Es ist genau, aber es erfordert, dass eine Person in eine Zeitschleife eintritt. „Pre-“ bedeutet, dass etwas vor etwas anderem passiert, wie beim „Vorheizen“ eines Ofens. In diesem Beispiel erwartest du, dass dein Ofen vom Zustand „aus“ zu „ein“ wechselt. Wenn du hingegen diese Option zum „Vorladen“ siehst, hast du bereits einen Ladebildschirm durchlaufen, um den Prototyp anzuzeigen. Was wir damit meinen, ist, dass du den Rest laden kannst, bevor du etwas anderes tust – beispielsweise offline gehen, um eine Präsentation zu halten. Aber um das zu erkennen, musst du mehr wissen, als wir dir hier erzählen.
Eine besser verstandene Computeraktion ist der übliche Akt des „Ladens“ – hätte das hier funktioniert?
Wir haben mit Substantiven gespielt: „Load full prototype“ (Vollständigen Prototyp laden), „Load all screens“ (Alle Bildschirme laden), „Load all assets“ (Alle Assets laden). Aber jedes davon schien das zentrale Vertrauensverhältnis zwischen der Person und dem Programm zu zerstören. Du hast soeben diesen Prototyp geladen; woher willst du wissen, dass er noch nicht fertig ist? „Laden“ ist eine wunderbar anschauliche Aktion, von der dein Computer dir mitteilen kann, dass er sie in deinem Auftrag ausführt. Aber wenn es erledigt ist, musst du daran glauben, dass es erledigt ist.
Version zwei: Was ist der Punkt?
Beim Schreiben für Software ist es wichtig, sich zu fragen, warum der/die Benutzer*in überhaupt etwas tut. Was ist das Ziel? In diesem Fall war es klar: Die Menschen mussten auch ohne Internetzugang verlässlich eine Präsentation abhalten können. „Present prototype offline“ (Prototyp offline präsentieren) oder „Prepare to present offline“ (Offline-Präsentation vorbereiten) zielen genau auf den Wunsch einer Person ab. Aber sind das die richtigen Verben in den richtigen Phrasen?
Der Computerpionier Terry Winograd schrieb bereits 1987: „Menschen agieren durch Sprache.“ Wenn wir jemandem eine Phrase in einem Menü präsentieren, etablieren wir deren Perspektive. Die meisten dieser Phrasen sind entweder Imperative, die an ein Programm gerichtet werden, oder Neigungen, die den Satz „Ich möchte…“ vervollständigen können. Die Worte müssen die Denkweise einer Person mit Computeraktionen verbinden, die ein bestimmtes Ergebnis liefern. Wenn die Kluft zwischen dem Denken, den Worten und dem, was passieren wird, zu groß ist, scheitert die Begegnung.
Die Lücke bei beiden Iterationen fühlte sich ziemlich groß an. Auf „Present…“ (Präsentieren) zu klicken, ohne zu präsentieren, ist stark verzögerte Befriedigung. Und auf „Prepare…“ (Vorbereiten) zu klicken, ohne zu wissen, was diese Vorbereitung ist oder wie früh Sie sie anfordern müssen, ist zu mehrdeutig. Jede dieser Aktionen könnte funktionieren, wenn wir ein größeres Erlebnis geplant hätten, gefolgt von granularen Aktionen, die der/die Benutzer*in ausführen muss. Aber das war nicht unsere UI. Beides wirkte zu aufdringlich für eine Menüoption, die ein- und ausgeschaltet werden kann.
Version drei: Was kannst du steuern?
Es gibt einen Punkt in allen Produkttexten, an dem sich die Wörter nahezu austauschbar anfühlen. Unweigerlich sagt jemand: „Wer wird das außer uns bemerken?“ Aber ich glaube wirklich, dass ein einzelnes Verb eine einzigartige Macht hat, etwas zu erschaffen. Es kann die Angelegenheit zwischen Ihnen und dem Objekt Ihrer Aufmerksamkeit regeln. Es rückt den Fokus einer Begegnung ins Rampenlicht und sorgt dafür, dass „die Lampe zum Arbeiten leuchtet“.
Welche Phrase würde eine Person dazu bringen, Figma als unterstützenden Partner zu nutzen? Wir könnten ein Verb ausprobieren, das sich auf „Befähigung“ bezieht –einen sanften Anstoß von einer Person an einen Computer, damit beide zusammenzuarbeiten.
„Make“ (Machen) ist ein sanfter Imperativ, der dennoch ein Gefühl von entschiedener Autorität vermittelt. Wenn man nicht gerade ein Schiffskapitän ist, sagt man normalerweise nicht zu anderen: „Mach das so.“ Wir beeinflussen jedoch die Welt damit: Wir machen Abendessen, machen Aufhebens, machen Sinn und machen die Dinge richtig. Vielleicht besteht die Rolle eines Benutzers bzw. einer Benutzerin hier tatsächlich darin, Figma jetzt in diesem Moment darüber zu informieren, was später bei der Präsentation benötigt wird: „Make (it) available offline.“ (Mache es offline verfügbar).
Sehr nah dran, aber immer noch nicht ganz genug. Bei „Make available offline“ (Offline verfügbar machen) denkst du möglicherweise daran, dass etwas für immer auf deinen Computer heruntergeladen wird. Und es gab ein paar Teammitglieder, die befürchteten, dass dies für Leute, die einfach nur eine bessere Prototypenleistung wollten – auch wenn sie noch online waren – zu unklar wäre. Also brauchten wir ein wenig mehr Text, um die endgültige Version fertigzustellen.
Die endgültige Version: Was passiert als Nächstes?
Die Ethnografen von PARC stellten einen Xerox-Hochgeschwindigkeitskopierer in einem Raum und beobachteten die Menschen bei der Nutzung des Geräts.
1983 stellte eine Anthropologie-Studentin namens Lucy Suchman eine Kamera auf, um Menschen dabei zu beobachten, wie sie mit einem neuartigen Hochgeschwindigkeitskopierer kämpften. In einem Video versuchen zwei Forscher*innen herauszufinden, was das Gerät über das, was sie tun, weiß und warum unerwartete Dinge passieren.
Lucy notierte später: Es war nicht nur wichtig, dass die Benutzer*innen wussten, was zu tun war, sondern auch, dass ein Computer klar machte, was er tat – und warum.
Wir mussten uns daran erinnern, dass es nicht ausreichte, jemanden zum Klicken zu bringen. Wir waren auch dafür verantwortlich, sicherzustellen, dass sie sich der Auswirkungen dessen, was geschah, bewusst waren. Also haben wir für die endgültige Erfahrung Icon-Status am Anfang einer Datei hinzugefügt, begleitet von einer ausführlicheren Erläuterung, die den technischen Sachverhalt mit den übergeordneten Zielen der Erfahrung selbst verbindet.
Wir haben die allgemein verstandene Idee des „Herunterladens“ verwendet, um zu beschreiben, was geschah, als die Datei-Assets von der Cloud zu deiner Browsersitzung verschoben wurden, jedoch nicht in deinen Gerätespeicher. Und als alles fertig war, haben wir daran erinnert, was du endlich tun konntest – offline präsentieren – und dabei klar angegeben, was man tun sollte und was nicht, wenn du das in Zukunft tun willst – den Tab offen lassen, denn wenn du ihn schließt, wird der Download gelöscht.
Ganz einfach, wirklich – nur ein paar Worte, schließlich: machen, behalten, präsentieren, schließen, klar. Eine Reihe winziger Handlungen, die einander in einem großen Figma-Universum umkreisen.
Danke an alle, die an diesem Projekt gearbeitet haben, darunter Georgia Rust, Connor Skees, Tim Van Damme, Niko Klein, Jackie Chui, Jediah Katz, Stephanie Cheuk und John Lai.
