Ich selbst habe bereits einige Präsentationen von Software(-systemen) durchgeführt, und habe noch mehr Abnahmepräsentationen als Teilnehmer beigewohnt.

Dabei sind mir immer wieder Dinge aufgefallen, die ich für mich mitgenommen und verbessert habe, um eine effektivere und verständlichere Vorstellung zu ermöglichen. Diese Erkenntnisse wollte ich hier festhalten, damit auch andere davon profitieren können.

Dabei bleibt vor allem eines festzuhalten: Vorbereitung ist die halbe Miete. Man muss nicht unbedingt eine Generalprobe abhalten, aber man sollte sich durchaus zu folgenden Aspekten Gedanken machen.

1. Persona verwenden und vorstellen

   Nichts ist langweiliger und weniger einprägsam als Max Mustermann, wohnhaft in der Musterstraße 123 in 12345 Musterhausen. Eine gute Präsentation lebt auch von einer sprechenden, glaubhaften Geschichte (Stichwort: Storytelling). Und eine gute Persona hilft dabei, den Anwendungsfall besser zu demonstrieren. Legen Sie sich eine Persona zurecht und verwenden Sie diese auch konsequent in der Präsentation. Gleich bei der Vorstellung kann man so auch implizit und elegant die zugrunde liegende User Story aufgreifen.

2. Liste der Anwendungsfälle aufschreiben

   Dieser Punkt ist extrem wichtig, gerade wenn man mehrere User Stories oder Änderungen vorstellt. Oft ist es so, dass die Anforderungen an bestimmten Punkten Synergien aufweisen, weil zum Beispiel gleiche Oberflächen betroffen sind. Deshalb ist es umso wichtiger sich vorab zu vergegenwärtigen, in welchem Schritt der Präsentation man ggf. kurz abschweift um eine kleinere Anforderung mit vorzustellen.
   
   Beispiel: Der Checkout-Prozess wurde grundlegend überarbeitet, es gab aber auch Verbesserungen an der Warenkorbansicht, der Gutscheineingabe und an der Produktsuche. Es ist also nur logisch, zuerst sich ein Produkt zu suchen, und dabei wenn möglich gleich die Verbesserungen an der Suchfunktion anzusprechen und zu demonstrieren, um anschließend in der Warenkorbansicht die dort eingefügten Verbesserungen zu zeigen und erst dann den Checkout und die verbesserter Gutscheineingabe zu demonstrieren.
   
   Das mag für Sie trivial klingen, wird aber oftmals nicht gemacht. Stattdessen wird jede Anforderung der Liste nach abgearbeitet und dabei manche Oberfläche x Mal durchgeklickt, was sich für die Zuschauer und Zuhörer sehr ermüdend und repetitiv anfühlt.

3. Funktionsweise testen

   Vor jeder Präsentation ist es wichtig, sich mit der Funktionsweise der Software auseinanderzusetzen! Das E-Maileingabefeld unterstützt keine Umlaute? – Gut dann auch wähle ich für meine Präsentation eine E-Mail ohne Umlaute.
   Es geht hier ausdrücklich nicht darum Fehler zu kaschieren, sondern sich mit der Funktionsweise der Software auseinanderzusetzen. Wie oft kommt es vor, dass bei der Präsentation der Präsentator, beispielsweise an den Passwortkomplexitätsrichtlinien, scheitert, weil er 123456 in der Schnelle eingeben wollte? Oder weil er eine URL beim Kunden aufrufen wollte, die aber für Aufrufe aus dem Internet nicht freigeschalten war?
   Es gibt viele mögliche Gründe, weswegen das System sich nicht so verhält, wie Sie es angenommen haben. Deswegen gilt im Rahmen einer guten Vorbereitung – testen Sie was Sie präsentieren wollen und ersparen Sie sich und anderen die hektische Lösungssuche während der Präsentation. P.S.: Sprechen Sie auch deswegen auch immer noch mal mit den Technikern!

4. Relationen zwischen Akteuren skizzieren

   Auch dieser Punkt ist wichtiger, als man denkt. Skizzieren Sie sich, welche Interaktionen ggf. entstehen. Beispielsweise zwischen dem Supportmitarbeiter und dem Nutzer und wie sie dies in der Präsentation zeigen möchten. Im Idealfall präsentieren Sie einen Anwendungsfall, bei dem der Nutzer in einen Fehler läuft und leiten dann geschickt über zur Rolle des Supportmitarbeiters, der dem Kunden hilft, sein Konto freizuschalten. Wichtig ist es diese Rollenwechsel auch in der Präsentation deutlich zu kommunizieren.
   Denken Sie auch immer daran, dass nicht alle Rollenwechsel so offensichtlich sind wie zwischen Kunde und Support-Agenten – so ist es beispielsweise schon schwerer zwischen Mitarbeiter und Supervisor zu differenzieren, wenn auch beide in derselben Oberfläche arbeiten. Im besten Fall kommen schnell verwirrte Rückfragen „Wie kommt der Kunde denn zu unseren Eingabemasken für den Support?“, im schlimmsten Fall verlassen die Leute Ihre Präsentation mit einem falschen Eindruck, wie das System aufgebaut oder verwendbar ist.

5. Präsentationsskript ausarbeiten

   Auch wenn es banal klingt, aber alles, was man sich aufschreibt, muss man nicht im Kopf behalten. Und das ist in einer Stresssituation genau das Richtige. Das Skript muss im Übrigen nicht wortgenau vorgeben, was man sagt, aber es empfiehlt sich genau das festzuhalten, was wir in den vorhergehenden Stichpunkten schon festgehalten haben, also zum Beispiel:
   
   „auf Oberfläche Warenkorb, Spreche an Verbesserung TICKET-ID: 1234 >Übersichtlichere Berechnung des Gesamtbetrags<;“
   
   oder
   
   „… Nach Abschluss Kontoregistrierung – WECHSEL ZU SUPPORT-GUI – Ansprechen, ich bin jetzt Supportmitarbeiter. Telefoniere gerade mit dem Kunden und bediene Funktion „Konto entsperren“ …“

Während der Präsentation

• Bei Online-Meetings und Telefonkonferenzen darauf hinweisen die Mikrofone stummzuschalten, oder noch besser, selbst stummschalten.
• Einen Timer / eine Uhr sichtbar stehen haben und darauf achten nicht zu überziehen. Nach 30 Minuten sollte man fertig sein.
• Fragen am besten nach hinten stellen.
• Am Ende der Präsentation auch noch wichtige URLs nennen, wenn diese für Teilnehmern verfügbar sind.

Nach der Präsentation

• Eine Zusammenfassung der vorgestellten Anforderung schicken (eventuell mit Ticket-Links). Die wenigsten der Teilnehmer werden mitschreiben und gerade diesen Teilnehmern hilft die nachträgliche Zusammenfassung, auch um selbst noch mal etwas genauer nachzuforschen.
• Klärungen zu aufgekommenen Fragen, die nicht sofort beantwortet werden konnten, nachreichen. Nicht jede Frage lässt sich einfach in einem Termin beantworten. Deswegen sollten sie aber trotzdem beantwortet werden. Damit sich keiner vergessen oder vernachlässigt fühlt, empfiehlt es sich, Antworten zu komplexeren Fragen nach dem Termin schriftlich zu beantworten.
• URLs zu gezeigten Systemoberflächen und Testwerkzeugen bereitstellen. Damit auch interessierte Teilnehmer sich mit dem System oder der Software beschäftigen können. Sicher, viele werden sich nicht damit abgeben, aber gerade für den einen oder anderen mag es doch hilfreich sein. Und wenn es nur der Azubi oder Praktikant ist, der es sich noch mal ansieht. Je mehr Augen sich damit beschäftigen, desto besser.

Ich hoffe, ich konnte Ihnen einige nützliche Ansatzpunkte geben, die auch Ihnen helfen, bei der nächsten Abnahmepräsentation Ihre Zuhörer besser mitzunehmen und allgemein das Verständnis für die Anforderungen zu erhöhen.

Document your intentions and ideas

The notes section in Axure is another underrated feature of Axure. Especially when designing a prototype as a team. In this scenario, I think the following rule of thumb should apply.

Write at least two notes for every page, describing:

• Page intention / Desired User Behavior
• Reasons Why / Triggers
• Obstacles
• Improvements (to keep track of good ideas)

Additionally, you can add the following notes, they really make sense, I see them as CAN-fields or Nice-to-have fields. Those would be:

• Targeted Version
• Mobile Behaviour (what changes on smaller screens)

The comment feature should be used with fellow colleagues, who have access to your team project and therefore have gone through some kind of expertise check – otherwise they hopefully wouldn’t have access to your project. If you want to catch feedback from a broader audience of spectators or a not so expert crowd, you should use the discussion-feature that comes with the HTML-Export.

But the best tool doesn’t do you any good if you are not used to using it. So practice or even force yourself to fill in at least two notes. Your future self will thank you and you will always keep track of the essential information that is behind each screen design.

Tipp: If you are uncomfortable with others being able to read your notes –  you can exclude the notes from getting exported into HTML by simply creating or customizing the HTML-Export in Axure.

Also you can add notes to each element. I don’t recommend you do this, because it is very tedious work and I don’t think it offers that much of a benefit. But in case you are wondering, here is a idea on how to use notes on an element level. You can use notes organized into named sets to document your notes right.

• Set: Planning
  • Improvements
  • Alternatives
• Set: Workflow
  • Note
  • Last edit
• Set: CMS
  • CMS Location
  • CMS Key

P.S.: This is an article that I originally posted in German and recently translated to English for a broader audience. See the original post if you want to read it in German.

In letzter Zeit habe ich für ein Projekt für das IDIS mehrere Usability-Tests mit unterschiedlichsten Probanden durchgeführt. Ziel der Tests war es das Verhalten auf der Webseite und deren Bedienbarkeit zu erforschen. Dabei haben wir neben Daten zur Funktion auch Informationen zur Person, zur Motivation, zu Emotionen und Relevanz der Webseite erhoben.

Gute oder bewährte Fragen habe ich für meine Teammitglieder und für spätere Tests in einem Dokument festgehalten.

Diese Fragen finden Sie hier: Sammlung von Interviewfragen.