Im ersten Teil des Artikels hat Jared Spool eine Analogie gezogen: Im UX-Design gibt es etwas, das dem Teig und dem fertigen Kuchen entspricht - Artefakte und Deliverables. Wenn Deliverables die fertig gebackenen Ideen des UX-Designs repräsentieren, repräsentieren Artefakte die halb gebackenen, die sich noch formen. Doch in der Praxis ist diese Unterscheidung eine Herausforderung, wie dieser zweite Teil zeigt.
Artefakte und Deliverables erzählen die Geschichte auf unterschiedliche Weise
Nicht alle Artefakte sollten verworfen werden, nachdem das Team alles, was es lernen kann, aus ihnen heraus gemolken hat. Sie bieten eine reichhaltige Historie des Denkprozesses.
Die Geschichte eines UX-Designs besteht nicht nur aus dessen Endergebnis. Die Geschichte muss auch die Reise umfassen, die das Team bis zum finalen Resultat genommen hat.
Artefakte sind nützlich, um diese Reise zu kommunizieren. Tatsächlich kann eines Präsentation vor Stakeholdern sehr mächtig sein, wenn man einige der Artefakte zeigt, die die Einschränkungen, die Herausforderungen und das Denken hinter dem endgültigen UX-Design demonstrieren.
Diese Leistungen an die Oberfläche zu holen, kann sowohl erhellend als auch unterhaltsam sein. (Wer mag schließlich nicht das Hinter-den-Kulissen-Material in den DVD-Extras?)
Deliverables erzählen die Geschichte dessen, was wir denken, wie das UX-Design sein sollte. Artefakte erzählen die Geschichte davon, wie wir dorthin gelangt sind. Beides sind mächtige Storytelling-Werkzeuge.
Unterschiedlichen Zwecken dienen
Schon allein das Verstehen der Unterschiede zwischen Artefakten und Deliverables kann ein Team produktiver machen. Zu jedem Zeitpunkt des UX-Design-Prozesses zu wissen, an welchen von beiden man arbeitet, ist kritisch dafür, das meiste aus Artefakten und Deliverables herauszuholen.
Oft sind Artefakte in grober Form am besten und wenn schnell viele von ihnen produziert werden. Deliverables dagegen wollen häufig mehr Verfeinerung haben und Iterationen durchlaufen, um das Denken des Teams akkurat zu repräsentieren.
Deliverables sind zumeist furchtbar ungeeignete Werkzeuge, um über Optionen zu debattieren. Das Team muss sich auf seine Entscheidungen geeinigt haben, ehe es seine Deliverables konstruiert.
Artefakte auf der anderen Seite sind perfekt für Debatten und Diskussionen. Ihre leichtgewichtigen und kurzfristigen Perspektiven machen sie zu idealen Strohmann-Angeboten, um Ideen zu testen und die Probleme zu erkunden. Bei den meisten Artefakten ist es nicht sinnvoll, sie zu verfeinern. Stattdessen packt man sie besser einfach beiseite und startet erneut.
Die große Herausforderung, sich über die Formbarkeit im Klaren zu sein
Wir können nicht sagen, was wir vor uns haben, wenn wir uns einen Artefakt oder ein Deliverable einfach anschauen. Natürlich kann ein Wireframe ein Deliverable sein, das den Entwicklern zeigt, wie wir die Seite gerne hätten. Aber ein Wireframe kann auch der Startpunkt einer Diskussion über das UX-Design sein, ohne die Intention, ihn genau so zu implementieren.
Es kommt auf den Kontext an, in dem ein Wireframe steht; er bestimmt, worum es sich handelt. Ist es, bevor Entscheidungen getroffen worden sind oder danach?
In der Praxis sind wir nicht sehr gut darin, hier klar unterscheiden zu können. Und wenn es an Klarheit mangelt, setzt Verwirrung ein.
Als Konvention haben mit der Genauigkeit unserer Tools gespielt. Eine grobes Design-Mockup mit einem Werkzeug wie Balsamiq macht den Eindruck, dass das Design noch in der Findung ist – anders als etwas, das fotorealistisch aussieht wie etwa ein HTML-Prototyp. Geringere Genauigkeit heißt Artefakt, während höhere Genauigkeit auf ein Deliverable hindeutet. Aber nicht alle Artefakte und Deliverables haben eine Genauigkeits-Dimension, mit der man spielen kann.
Sogar noch komplexer wird dies dadurch, dass in einem Projekt von realistischem Umfang die Design-Entscheidungen nicht alle auf einmal getroffen werden. Sie verteilen sich über die Projekt-Timeline hinweg; einige Entscheidungen sind in Stein gemeißelt, während andere noch darauf warten, ausgelotet zu werden.
Zu zeigen, welche Entscheidungen gefällt sind, während andere noch in der Schwebe sind, kann zu Herausforderungen führen. Wir müssen Werkzeuge und Prozesse entwickeln, um zu kommunizieren, wo im Entscheidungsprozess wir uns befinden, wenn wir an einem bestimmten UX-Design arbeiten.
Wir müssen uns noch reichlich Gedanken rund um Artefakte und Deliverables machen. Ich freue mich auf mehr Diskussionen und Beispiele dafür, wie Teams diese wichtigen Herausforderungen lösen.
Wir müssen unsere halb gebackenen Artefakte erfassen und besser verstehen, wie wir unsere fertig gebackenen Deliverables einsetzen. Die introspektive Ansatz im Hinblick auf unsere Prozesse wird uns zu besseren UX-Designern machen und zu großartigen UX-Designs führen.
Dieser Artikel wurde im Original am 9. Juli 2014 unter dem Titel Design's Fully-Baked Deliverables and Half-Baked Artifacts
