uxzentrisch erörtert:
Sei nicht klug. Sei nützlich!

Als User Experience Designer setzen wir den Fokus auf Menschen. Menschen, die mit den von uns entwickelten Systemen leben müssen. Ihre Bedürfnisse, ihre Anforderungen, ihr Kontext leiten uns. Alles mit dem strategischen Anspruch: putting people first. Das ist richtig und gut so. Aber was ist eigentlich mit den Bedürfnissen und Anforderungen der Menschen, die unsere Arbeit benutzen sollen?

Denken wir nur halb so viel über die Empfänger unserer Dokumente nach wie über die User der Websites und Applikationen, die wir gestalten? Anders gefragt:

Wie nützlich und nutzbar sind unsere Konzepte, Wireframes, Sitemaps, Personas, Use-Cases etc.?

Information Overload by true2source

Sei nützlich!

In klassischen Werbeagenturen gibt es die Funktion des Planners. Ähnlich wie UX-Designer, ist der Planner dafür verantwortlich, dass die Zielgruppe in einem Projekt nie aus dem Fokus verloren wird. Einer der Koryphäen unter den Plannern, Jon Steel, sagte einmal, die Aufgabe von Plannern sei nicht klug zu sein, sondern nützlich:

»A lot of planners get carried away with the idea of being clever. Being cleverer than the other people around them, showing off their formidable intellect, debating issues to their finest, finest points. That’s fine […] but cleverness is simply a means to an end. […] It’s your job to be useful.« Link

Nützlich zu sein für das Team, das Projekt, den Kunden – das gilt für UX-Designer genauso.

Moment! Ist das nicht unser ureigener Kompetenzbereich? Wir beschäftigen uns doch permanent damit, Dinge möglichst useful und useable zu machen. Wenden wir doch einfach die Erkenntnisse aus dem UX-Design auf unsere eigene Arbeit an!

Der Wert von Dokumentationen

Kurzer Einschub: Der Wert von Dokumentation ist umstritten. Insbesondere im Umfeld von agilen Projekten sind klassische Dokumentationen nicht mehr sinnvoll. Fakt ist aber auch, dass Dokumentationen noch immer Alltag und wichtiger Bestandteil von vielen Projekten sind – insbesondere im Zusammenspiel von Agenturen und deren Kunden. Hier muss (leider) häufig noch in »Wasserfall«-Manier gearbeitet werden. Konzept-Dokumente dienen als Meilensteine von deren Freigabe die weitere Arbeit abhängt. Solange wir in dieser Form dokumentieren müssen, sollten unsere Dokumente so nützlich und nutzbar, wie möglich sein.

»Ähm… steht das so im Konzept?«

Wer diesen Satz noch nie gehört hat, macht anscheinend alles richtig und kann aufhören zu lesen. Ich selber habe den Satz leider schon oft gehört – und zwar gleichermaßen von Kunden wie vom Projektteam. Ich habe bald gelernt, dass Konzepte selten gelesen werden. Und selbst, wenn sie gelesen werden, heißt das noch lange nicht, dass ein gemeinsames Verständnis von den Aussagen herrscht. Gemeint ist nicht gesagt, gesagt ist nicht verstanden, verstanden ist nicht einverstanden. Das berühmte Experiment mit dem unsichtbaren Gorilla bezeugt eindrucksvoll, wie Wahrnehmung (nicht) funktioniert.

Wenn Konzepte nicht gelesen oder nicht verstanden werden, verlieren sie ihren Wert für das Projekt. Genauso, wenn sie nicht sinnvoll genutzt werden können. Lamentieren hilft nichts. Wir müssen uns vielmehr die Frage stellen, wie Konzepte gestaltet werden müssen, dass sie gelesen und verstanden werden können. Wenn man ein Konzept von 300+ Seiten erarbeitet hat, kann man stolz auf sich sein. Es dokumentiert eindrucksvoll die eigene mühevolle Arbeit. Aber danach sollte man sich ernsthaft überlegen, wie ein solches Dokument im Projekt sinnvoll und nützlich eingesetzt werden kann.

Wie dokumentiere ich meine Arbeit sinnvoll?

Darauf lässt sich natürlich keine pauschale Antwort geben. Aber es hilft, unsere eigenen UX-Methoden anzuwenden und sich folgende Fragen zu stellen:

  • Worum geht es insgesamt im Projekt?
  • Warum erstelle ich dieses Dokument?
  • Was sind die wichtigsten Aussagen, die auf jeden Fall hängen bleiben sollen?
  • Wer wird es nutzen?
  • Wie soll es genutzt werden?
  • Welche Handlungen soll das Dokument unterstützen?

Es ist wichtig zu verstehen, in welchem Kontext des gesamten Projekts die eigene Arbeit stattfindet, und wie sie zum Gesamtziel des Projekts beiträgt. Wir können keine nützlichen Konzept-Dokumente erstellen, wenn wir nicht wissen, für wen wir sie erstellen. Wir müssen die Zielgruppe unserer Dokumente und ihre Bedürfnisse und ihren Kontext kennen.

Ein Problem ist dabei, dass wir es nicht selten mit einer heterogenen Zielgruppe zu tun haben: Kunden, Entwickler, Designer – das sind im Grunde alle »User«, die unsere Konzept-Dokumenten nutzen. User mit unterschiedlichen Bedürfnissen, Zielen, Erfahrungen, Kontexten.

Was also tun?

Konzept-Dokumente müssen auf die konkreten Anforderungen hin gestaltet werden. Vorlagen und Templates sind nützlich, wir müssen sie aber interpretieren,um daraus wiederum nützlich Dokumente zu erstellen. Barnabas Nagyin stellt in seinem Artikel Breaking Out of the UX Status Quo interessante Beispiele für Personas, Sitemaps und Szenarien vor.

Barnabas Nagy, A new version of the traditional persona

Zugegeben, diese Beispiele sind sehr elaboriert und teilweise aufwändig gestaltet. Die Gestaltung darf natürlich kein Selbstzweck sein. Sie ist dafür da, den Nutzwert der Dokumente zu erhöhen. Es nutzt nichts, in Schönheit zu sterben.

Aber es gibt auch einfache Tipps, wie informationslastige Dokumente nützlich gemacht werden können.

    • Wichtige Informationen (z.B. die Ziele des Dokuments) hervorheben, z.B. durch größere Schrift und Kästen – auch wenn die Vorlage das eigentlich nicht vorsieht.
    • Überblick geben: In einem meiner letzten Konzepte habe ich in der Einleitung einen Abschnitt »General approach: the concept in a nutshell« eingefügt, der in wenigen Bullets die Grundgedanken des Konzepts formuliert.
The concept in a nutshell
    • Nutzerführung: Bei umfangreichen Dokumenten ist es sinnvoll, einen Überblick über das Dokument am Anfang geben. Was wird in den einzelnen Teilen behandelt.
    • Inhaltsangaben sollten nicht überfrachtet und nach Möglichkeit gruppiert sein. Axure führt leider zu überlangen Inhaltsangaben.
    • Keine Angst vor kleinen redaktionellen Elementen, die das Dokument auflockern – z.B. ein Zitat aus einem Workshop, ein Bild aus einer Präsentation als Erinnerungsanker etc.
Bilder und Zitate lockern das Dokument auf
    • Fachsprache und Jargon vermeiden. Damit beweist man nicht seine Kompetenz.
    • Die Sprache sollte prägnant und präzise sein. Wortblasen sind für Schaumschläger. (»Die Hauptbühne kommuniziert erlebbare Momente und schafft damit eine Emotionalisierung… « bähh).
    • Änderungen im Dokument (z.B. nach Kundenfeedback) einfach hervorheben – zusätzlich zur Änderungshistorie.
updates-im-dokument

Fazit

Damit unsere Arbeit Effekt hat, müssen wir uns über den Kontext in dem sie verwendet wird Gedanken machen. Standards sind nützlich, aber wir müssen sie adaptieren auf die vorliegenden Anforderungen und Menschen im Projekt.  Wer wird das Dokument nutzen? Wie soll es genutzt werden? Die besten Konzepte helfen nichts, wenn sie nicht operationalisiert werden können. Da können wir noch so klug sein, wenn wir es nicht schaffen nützlich zu sein, sind alle Konzepte Kokolores.

 

Welche Tipps und Erfahrungen habt ihr? Ich freue mich auf euer Feedback.

1 Kommentar

Natalia Weimann vor 3 Jahren

Seit einiger Zeit arbeite ich als Forscherin für ein Consulting-Unternehmen, dessen Ziel ist, die Entwicklung von innovativen Produkte und Dienstleistungen durch der UCD-Forschung zu fördern.
Beim letzten von unseren Projekten, der auf die Entwicklung der internen Kommunikation in einer Organisation gezielt wurde, wählten wir die SCRUM-Methode als eine Strategie der Zusammenarbeit mit unserem Kunden. Bei dieser Methode geht es um das maximalen Engagement des Kunden im Projekt. Um es zu erreichen, betrachtet man den Kunden als ein Mitglieder des Forschungsteams, so dass sowohl die Forschungsergebnissenkommunikation, als auch die Einführung von Änderungen oder Verbesserungen im Forschungsprozess einfacher ist.

Obwohl in der Theorie es ganz ermutigend klingt, ist die Praxis als sehr schwierig bewiesen, weil zum Beginn des Projekts stellte sich heraus, dass der Kunde entweder den Kern des Forschungsprozesses noch die Sprache der Teammitgliedern nicht verstanden hat.
Weil ich kulturelle Anthropologin bin, war es für mich eine sehr interessante Erfahrung – die Beobachtung der Kollision von zwei Welten, zwei unterschiedliche Perspektiven, die für das Gemeinwohl in Einklang gebracht werden müssten.

Schließlich ist es meinem Team gelungen, obwohl es unmöglich war, zahlreichen Missverständnissen, Spannungen und gegenseitigen Beschuldigungen komplett zu vermeiden. Jedoch dank dieser Schwierigkeiten haben wir gelernt, wie während des nächsten Projektes diesselbe Fehler nicht mehr machen.

Also, die wichtigsten Regeln der nützliche Projektkommunikation sind wie folgende:
1. Sei schlicht – der Kunde hat manchmal mehr Recht, als du hast
2. Sei flexibel – du arbeitest für den Kunden und musst seine Anforderungen respektieren, auch wenn sie im Laufe des Projektes geändert werden.
3. Sei selbstsicher – du bist der Expert und Berater und es ist deine Rolle, dem Kunden es professionell zu erklären, dass manche seiner Anforderungen irrelevant für die Ziele des Projektes sind und geändert werden müssen.
4. Sei verständlich – schon am Anfang des Projektes lerne die Sprache der Kunden und verwende sie (es ist einfach über schwierige Sachen kompliziert zu sprechen, aber es ist die Kunst, sie zugänglich jedoch ohne eine Verharmlosung zu erklären).
5. Sei dich selbst – verliere nie deine Individualität, weil wegen dieser kleinen Besonderheiten, die dich von der Konkurrenz unterscheiden, wurdest du von deinem Kunden ausgewählt!

Ich glaube, dass Verwendung von dieser einfachen Regeln wird die Projektkommunikation mit dem Kunden einfacher und nützlicher für beide Seiten machen – was ich jedem SCRUM-Team herzlich wünsche!

P.S. Als wir hier über den Usability reden, ermutige ich euch, die UTC Webseite zu besuchen:

http://usabilitytools.com/

Viel Spass!