Kuchen gibt es in zwei Stadien. Wir denken darüber nicht nach, weil wir normalerweise nur auf ein Stadium fokussiert sind. Doch dieses Stadium könnte ohne das andere nicht existieren.
Es gibt gebackene Kuchen, an denen wir uns laben. Und es gibt ungebackene Kuchen, aus denen die gebackenen Kuchen werden müssen. Teig und Kuchen. Die zwei Stadien eines Kuchens.
Die Metapher führt nicht sehr weit, also will ich so schnell wie möglich mit ihr durch sein. (Das ist auch die typische Art, wie ich Kuchen anpacke.) Ohne Teig kann es keinen Kuchen geben. Trotzdem unterscheidet sich Teig von Kuchen. Teig sieht anders aus und fühlt sich anders an als ein Kuchen. Beide dienen unterschiedlichen Zwecken.
Das Kuchen ist bereit zum Gegessen-Werden. Beim Teig geht es um Gemacht-Werden. Sicher, man kann ein bisschen vom Teig naschen (Wer hat noch nie die Mixerstäbe abgeleckt?), aber den Teig zu Kuchen zu backen, ist das wirkliche Ziel.
Bei Teig geht es um ständige Veränderung. Wenn man die Zutaten vermischt, ändert sich die Natur des Teigs. Kuchen andererseits ist statisch. Einmal ein Kuchen, bleibt er ein Kuchen. (Reden wir nicht über austrocknen oder vergammeln, denn da ist mit der Metapher Schluss, das hoffe ich zumindest.)
Im UX-Design haben wir etwas, das den beiden Stadien eines Kuchens ähnlich ist: Artefakte und Deliverables. Wenn Deliverables die fertig gebackenen Ideen unseres UX-Designs repräsentieren, repräsentieren Artefakte die halb gebackenen, die sich noch formen.
Die Unterscheidung zwischen Artefakten und Deliverables ist sehr wichtig, aber trotzdem finden wir uns nie in Diskussionen darüber wieder – ebenso wenig wie über die verschiedenen Stadien eines Kuchens eben. Wenn wir das eine entwickeln, während wir denken, wir entwickelten das andere, führt das zu Konfusion, die Zeit verschwendet und das Team bremst. Wir müssen verstehen, wie sie funktionieren und was sie jeweils wertvoll macht.
Vor und nach dem Punkt der Entscheidung
Artefakte und Deliverables sind sehr ähnlich. Tatsächlich können sie manchmal exakt dieselbe Form annehmen. Ein Wireframe zum Beispiel kann sowohl als Artefakt als auch als Deliverable agieren. Ebenso eine Persona-Beschreibung, ein User-Szenario, eine Journey-Map oder eine Design-Skizze.
Bei Artefakten und Deliverables ändert sich der Status, wenn die Design-Entscheidungen getroffen werden. Bevor die Entscheidungen gefällt sind, ist eine Design-Skizze oder ein User-Szenario nur eine Idee – ein Vorschlag, der uns hilft, das Problem besser zu verstehen.
Nach den Entscheidungen sagt uns eine Design-Skizze, welche Richtung das UX-Design nimmt. Das User-Szenario informiert das Team darüber, welche Probleme das UX-Design lösen will.
Deliverables sollen Intention kommunizieren
Deliverables sind das, womit wir die Geschichte davon erzählen, wie das Design sein wird. Natürlich, das klassische Deliverable ist der fertige Produkt selbst. Nichts erzählt die Geschichte des UX-Designs besser als das Produkt.
Vor langer, langer Zeit war das fertige Produkt das einzige Deliverable. Da gab es keine Pläne oder Entwürfe, nur das, was der Handwerker fertigstellte.
Zusammenarbeit über die Organisation hinweg hat alles verändert. Andere mussten unsere Intention kennen – wollten wissen, wie wir das UX-Design haben wollten. Somit waren zwischenzeitliche Deliverables geboren.
Deliverables haben historisch die Form der deskriptiven Spezifikationen angenommen. Weil repräsentative Prototypen erst seit kurzer Zeit Realität sind, haben wir auf Dokumente voller beschreibender Prosa und flache, zweidimensionale Skizzen gesetzt, um unsere Intention des finalen UX-Designs zu kommunizieren.
Erst in den letzten Jahrzehnten haben wir angefangen, die Idee eines Prototypen als Deliverable zu verstehen. Architekten begannen, kleine Modelle der Wolkenkratzer zu bauen, die sie errichten wollten. Auto-Designer bauten Modelle der Fahrzeuge, die in Produktion gehen sollten.
In der Online-Welt nutzen wir Sitemaps und Wireframes, um zu spezifizieren, was wir gerne umgesetzt haben würden. Wenn der UX-Designer nicht die Person ist, die das Design implementiert, brauchen wir Wege, um auszumalen, was wir tun.
Der leane Druck, Deliverables zu elemenieren
Neuerdings gilt "Deliverables" in der UX-Design-Community als unanständiges Wort. Uns wird gesagt, wir müssen aufhören, an Deliverables zu arbeiten, und uns auf die Umsetzung des Produkts selbst fokussieren. Das Argument ist, dass Deliverables nicht ausgeliefert werden können, und alles, was wir spezifizieren müssen, kann in den Code des Produkts eingebunden werden – die ultimative Spezifikation, sagt man uns.
Da steckt eine Menge Logik in diesem Argument. Um zum Beispiel die Farben eines Designs zu spezifizieren, könnte der Designer die Farbwerte direkt in das CSS einbinden. Die Entwickler im Team können diese CSS-Spezifikationen direkt im Code nutzen. Wenn der Designer die Farben ändern will, ändert er einfach das CSS und alles wird mit dem nächsten Release ausgeliefert. Entwickler brauchen keine nicht-auslieferbaren Photoshop-Dateien hernehmen, um die Farbwerte zu bekommen.
Aber Deliverables werden nicht nur genutzt, um Entwicklern die Spezifikationen zu kommunizieren. Manchmal sollen sie den Fortschritt zeigen, der vonstatten geht. Ein anderes Mal sollen sie Einblicke in die Spezifika geben, die andere brauchen, etwa wenn die Marketing-Botschaft für das Produkt geplant wird. In einem Unternehmen, in dem viele parallele Aktivitäten auf das Produkt-Release zusteuern, kommunizieren Deliverables, wie man den Pudding an die Wand nagelt.
Es ist unwahrscheinlich, dass diese Deliverables eleminiert werden können. Die Marketing-Leute gehen nicht los und schauen in den Code, um zu sehen, was entschieden worden ist, also muss ihnen die Intention in einer anderen Form kommuniziert werden. Zwischenzeitliche Deliverables, die die Intention der UX-Designer zeigen, werden in großen Organisationen immer ihren Platz haben. Kein noch so sehnliches Wünschen wird sie ausmerzen.
Allerdings können wir uns immer selbst fragen, ob ein Nicht-Code-Deliverable der beste Weg ist, um mit unserem Publikum zu kommunizieren. Wir können Deliverables spezifisch auf die Bedürfnisse unseres Publikums ausrichten. Das heißt, dass wir versiert in all den verschiedenen Techniken sein und all die Formen beherrschen müssen, die Deliverables annehmen können.
Artefakte formen ein gemeinsames Verständnis
Artefakte repräsentieren unser derzeitiges Denken über die anstehenden Design-Entscheidungen.
Manchmal produzieren wir sehr schnell tonnenweise Artefakte. Nehmen wir beispielsweise ein Design-Studio. Der Prozess dauert ein paar Stunden, und das Team produziert dutzende, wenn nicht hunderte Skizzen. Jede Skizze lotet ein oder zwei Ideen für potenzielle Lösungen aus.
Das Interessante an den Design-Studio-Artefakten sind – wie an allen guten Artefakten – die Diskussionen, die sie fördern. Das Team kann jeden Artefakt kritisch besehen und ein Vokabular im Hinblick auf das Problem entwickeln.
Die meisten Artefakte werden verworfen, die Ideen dahinter sind "der weiteren Betrachtung nicht wert". Aber der Prozess des Erstellens, Kritisierens und Diskutierens ihrer Implikationen lebt weiter. Sie werden die Grundlage für das gemeinsame Problemverständnis des Teams.
Die Desorientierung des Ausbrütens
Artefakte sind am nützlichsten, wenn man über multifunktionale Teams hinweg arbeitet. Das Erstellen von Artefakten bringt die Idee raus an einen gemeinsamen Platz, wo sie inspiziert und diskutiert werden kann.
Das ist eine Form des Ausbrütens: Wir nehmen eine Idee und setzen sie in die Welt hinein, um zu sehen, wie sie funktioniert, wenn sie nicht nur in unserer Vorstellung existiert. Ein UX-Design auf diese Weise zu sehen, ist für seinen Schöpfer desorientierend, denn die Realität des Sehens unterscheidet sich schon sehr von der reinen Vorstellung. So werden Schwachpunkte der Idee deutlich, aber es bringt auch Inspiration hervor.
Wenn Leute mit unterschiedlichen Perspektiven über einer Design-Idee brüten, geht aus der Diskussion ein hilfreiches Vokabular dahingehend hervor, was das Team zu tun versucht. Es kann in neue Richtungen führen. Die regelmäßige Wiederholung kann ganz neue Ansätze in Bezug auf das Problem generieren, die sonst nicht bedacht worden wären.
Im folgenden zweiten Teil des Artikels thematisiert der Autor die Herausforderung, Artefakte und Deliverables in der Praxis zu unterscheiden.
Dieser Artikel wurde im Original am 9. Juli 2014 unter dem Titel Design's Fully-Baked Deliverables and Half-Baked Artifacts
