Beispielhafter Erfolg & Beispiellose Niederlage – Warum gute Beispiele so wichtig für den Erfolg eigener Ideen sind habe ich in meinem Talk beim UX Day 2017 in Mannheim vorgestellt.
Am 10.10.2017 fand wieder der UX Day in Mannheim in der Alten Feuerwache statt. Ich bin ein großer Fan der Veranstaltung und wurde auch in diesem Jahr wieder nicht enttäuscht. Bei der Closing Keynote gab es sogar „Zugabe“-Rufe, was auf Konferenzen eher nicht der Fall ist. Auch in 2017 war ich wieder mit einem Vortrag vertreten. Worum es ging, erfahrt ihr hier und den Link zum Vortragsvideo findet ihr unten:
„Hast du mal ein Beispiel, damit ich es besser verstehen kann?“, „Wie muss ich mir das vorstellen, zeigst du das noch am Beispiel?“, „Das hast du aber sehr vereinfacht erklärt, hast Du noch ein realitätsnahes Beispiel?“ – Diese oder ähnliche Aussagen sind oft die ersten Reaktionen auf die Präsentation einer neuen Idee. Obwohl wir selbst den Präsentierenden oft als Erstes nach einem guten Beispiel fragen, vergessen wir bei unseren eigenen Präsentationen gerne, wie wichtig gute Beispiele sind, um andere von unseren neuen Ideen zu überzeugen. Der Vortrag zeigt, warum „Lorem Ipsum“, „Max Mustermann“, „Unternehmen 1“ und „Kundengruppe A“ nicht ausreichen, um andere für die Umsetzung eigener Ideen zu begeistern.
Oft sind es gute Beispiele, die über den Erfolg oder Misserfolg einer Idee entscheiden. Verwenden wir keine oder schlechte Beispiele, wenn wir unsere Ideen anderen erklären, so stoßen wir oft auf Missverständnis oder gar Unverständnis. Da wir uns selbst so lange mit der Idee beschäftigt haben, fällt uns das Fehlen von Beispielen oft gar nicht so leicht auf, da wir selbst kein Beispiel (mehr) benötigen. Wenn wir jedoch Pech haben, dann wird unsere Ideen direkt nach unserer Präsentation abgelehnt, ohne dass wir die Chance haben, die Idee noch einmal besser zu erklären. Wenn wir Glück haben, dann werden wir direkt nach einem guten Beispiel gefragt, um unsere Ideen zu illustrieren oder zu visualisieren. Dann müssen wir jedoch spontan reagieren und uns ein Beispiel ad hoc überlegen. Das funktioniert meistens nicht gut. Denn gute Beispiele für die Erklärung von neuen Ideen zu erstellen ist harte Arbeit. Es ist meist ein langwieriger Prozess, bei dem viel ausprobiert werden muss. Ein gutes Beispiel muss „groß genug“ sein, um realitätsnah zu sein und nicht direkt als „vereinfachter Spezialfall“ abgehandelt zu werden. Eine moderate Komplexität ist zudem wichtig, um ein oft gewünschtes „durchgängiges Beispiel“ zu erhalten, dass uns erlaubt, die Idee aus unterschiedlichen Blickwickeln zu zeigen und möglichst vielen Facetten zu beleuchten. Das Beispiel muss aber auch klein genug sein, dass wir nicht die ganze Vortragszeit benötigen, um das Beispiel zu erklären. Die Realitätsnähe zum tatsächlichen Anwendungsfalls ist immens wichtig. Warum „Max und Maria Mustermann“, „Lorem Ipsum“, „Unternehmen 1“ und „Kundengruppe A“ daher nur bedingt geeignet sind, um gute Beispiele zu erstellen und worauf wir noch achten müssen, um unsere Ideen zu beispielhaften Erfolg zu führen, wird im Vortrag aufgezeigt.
Auch in diesem Jahr gab es wieder sehr viele gute Vorträge. Insbesondere möchte ich euch die folgenden Vorträge ans Herz legen:
Javier Bargas-Avila zum Thema „Me no speak English“. Wie wichtig und schwierig es ist ist, einen internationalen Webauftritt in jeder Sprache wirklich gut hin zu bekommen, zeigt der Javier Bargas-Avila von Google am Beispiel von Youtube.
Wir brauchen immer mehr tolle Ideen! Aber woher nehmen, wenn nicht stehlen? Anregungen zur kreativen Beschaffung von Ideen aus meinem Vortrag vom UX Day 2015.
„Bringt mir neue, innovative Lösungen!“, „Seid doch endlich mal kreativ!“, „Wir müssen uns neu erfinden!“ und ähnliche Aussagen hören wir vermehrt in letzter Zeit. Es scheint jedoch so, als wäre alles schon von anderen erfunden, und die anderen haben sowieso immer die besseren Ideen, so dass wir uns zur Lieferung neuer Ideen fragen müssen: Woher nehmen, wenn nicht stehlen? Ob das vielleicht sogar eine ernsthafte Lösung ist oder wie wir unser Wissen über existierende gute Lösungen gewinnbringend zur Erarbeitung von neuen Ideen einsetzen können, wird in diesem Vortrag diskutiert.
Die Nachfrage nach neuen, kreativen Lösungen oder Produkten steigt stetig an. Immer mehr Menschen sollen in ihrer täglichen Arbeit innovativer werden. Sie sollen ihre „Komfortzone verlassen“ oder „um die Ecke denken“. Das ist aber für viele Menschen leider sehr ungewohnt und oft auch unangenehm. Erschwert wird die Situation zudem dadurch, dass dem ersten Eindruck nach, jede erarbeitete Idee schon lange von anderen bereits erfunden oder erdacht worden ist. Es erscheint vordergründig, als ob es täglich schwerer wird, etwas Neues zu erschaffen. Dies wird zudem noch oft von den eigenen Mitarbeitern bestätigt: „Gibt’s schon. Das brauchen wir gar nicht erst zu versuchen. Das haben andere schon ewig.“ Schnell kann man sich in dieser Situation fragen „Woher nehmen, wenn nicht stehlen?“
Im Vortrag wird diskutiert, ob vielleicht gerade das eine Lösung unseres Problems darstellen könnte, selbstverständlich im übertragenen Sinne. Warum sollten wir unser Wissen über bereits existierende gute Lösungen immer destruktiv nur zur Ablehnung der eigenen Ideen verwenden? Schließlich können wir die bereits bekannten guten Lösungen als Inspiration konstruktiv nutzen. Bei genauem Betrachten sind nämlich meistens die selbst erdachten Ideen doch nicht ganz genauso schon einmal von jemand anderem erdacht worden (wie die Kollegen aber angeben). Aber gerade weil schon mal jemand zuvor eine gute Lösung für ein (sehr) ähnliches Problem gefunden hat, kann man bestimmte Aspekte dieser Lösung auf das eigene Problem übertragen. So geht es hier nicht um Kopien oder gar Diebstahl von Ideen sondern vielmehr um Inspiration, Transformation oder einen „Remix“. Auch können wir aus vielen bereits existierenden Lösungen für Teilaspekte unseres Problems eine Gesamtlösung zusammenbauen.
Der Vortrag zeigt mit vielen anschaulichen Beispielen, wie diese „kreative Beschaffung“ bereits von erfolgreichen Unternehmen eingesetzt wird. Zudem motiviert der Vortrag sich mit vielen Bereichen und Domänen auch außerhalb der eigenen Arbeit zu beschäftigen, um Lösungsideen von dort in die eigene Arbeit zu übertragen.
Am 13. & 14. Oktober findet in Mannheim der UX Day 2016 statt. Ich freue mich auch dieses Jahr wieder mit dabei zu sein. Mein Vortrag dieses Jahr trägt den Titel:
„Wir müssen reden!“
Gute Kommunikationsfähigkeiten sind eine wichtige Voraussetzung für nahezu jede Rolle im User Experience Engineering. Selbst unter besten Voraussetzungen:
wenn genau der richtige Stakeholder,
zum genau richtigen Zeitpunkt zum Gespräch eingeladen wurde,
das Gespräch perfekt vorbereitet wurde und
in den perfekten Räumlichkeiten stattfindet,
so kommt es dennoch zu einem erheblichen Maße auf die persönlichen Kommunikationsfähigkeiten des UX-Experten an, wie gut oder schlecht die Ergebnisse des Gesprächs sein werden. Dieser Vortrag liefert konkrete Tipps und Tricks von Kommunikationsexperten aus unterschiedlichsten Domänen (Kriminalistik, Jura, Journalistik, uvm.) zur Verbesserung der Kommunikation in persönlichen UX-Stakeholder-Gesprächen.
Das persönliche Interview ist immer noch eines der wichtigsten Instrumente zum Erheben und Validieren von UX Anforderungen. Es gibt viele Techniken, Methoden und Werkzeuge, die uns dabei unterstützen, die Interviews zu planen und die richtigen Stakeholder für diese Interviews zu identifizieren. Noch mehr Unterstützung gibt es, die UX Experten helfen, die zu erhebenden Informationen festzulegen und somit auszuwählen, welche Fragen den Stakeholder genau gestellt werden sollen. Jedoch egal wie gut das Interview vorbereitet und aufgesetzt wurde, im Interview selbst, hängt es dann jedoch erheblich von den persönlichen Kommunikationsfähigkeiten des UX Experten ab, ob das Interview erfolgreich verläuft oder nicht. Es gibt somit viel Unterstützung für das WANN, WER und WAS aber fast keine Unterstützung für das WIE. Die im UX-Stakeholder-Interview benötigen Kommunikationsfähigkeiten unterscheiden sich nicht (stark) von den Kommunikationsfähigkeiten von Experten aus anderen Domänen, in den es ebenfalls wichtig ist, Informationen zu erheben und zu validieren. Polizisten müssen Informationen von Zeugen und Verdächtigen erheben und auf ihren Wahrheitsgehalt hin beurteilen. Ähnliches gilt für Anwälte, die zudem noch die Aussagen von Gutachtern einschätzen müssen. Auch für Reporter ist das persönliche Interview ein wichtiges Mittel zur Erhebung von Informationen. Aber auch die Gesprächsführung beim Dating oder im Job-Interviews ist ähnlich zum UX-Stakeholder-Interview, da auch hier versucht wird, Informationen vom Gegenüber zu erhalten und diese auf ihren Wahrheitsgehalt hin zu überprüfen. Es gibt viele Tipps & Tricks aus diesen Domänen und Disziplinen, die auch in UX-Stakeholder-Interviews angewendet werden können. Dies gilt nicht nur die verschiedenen Phasen des eigentlichen Interviews, sondern auch die Interview-Vorbereitung und -Nachbereitung.
Ich bin seit vielen Jahren ein großer Fan der Veranstaltung und freue mich daher schon jetzt wieder auf einen tollen Tag in Mannheim. Alle Informationen zum UX Day 2016 gibt es hier! Dieses Jahr gibt es zum ersten Mal einen zweiten Veranstaltungstag, an dem die UX Masterclass stattfinden wird.
App-Entwickler müssen gute Nachbarn sein und wieder sorgsamer mit knappen Ressourcen (Speicher, CPU, Akku) umgehen, sonst werden ihre Apps wahrscheinlich bald von Benutzern gelöscht.
Die World Wide Developer Conference (WWDC) 2015 in San Francisco ist nun schon wieder weit mehr als einen Monat vergangen. Ich habe von der Veranstaltung eine Aufgabe bzw. Herausforderung für uns Architekten, Programmierer und Designer mitgenommen, die ich für sehr wichtig halte:
Diese unterschwellige Nachricht habe ich über die gesamte Veranstaltung hinweg immer wieder wahrgenommen. Obwohl wir alle auch in der realen Welt gute Nachbarn sein sollten, meine ich das natürlich im übertragenen Sinne. In einer Wohnnachbarschaft trägt jeder einzelne Bewohner zur Lebensqualität der Stadt, des Bezirks, des Viertels, der Gegend, der Straße oder des Blocks bei. Genauso trägt jede einzelne App zur User Experience eines Smartphones, eines Tablets, einer Smartwatch usw. bei. Es wird erwartet, dass sich alle an „geltende Regeln“ halten. Regelverletzungen werden in Nachbarschaften meist recht schnell „geregelt“.
Gute Nachbarn halten sich jedoch nicht nur an die Regeln, sondern unterstützen sich gegenseitig über diese Regeln hinaus, um das Leben in der Gemeinschaft zu verbessern. So parken gute Nachbarn mit eigenem Parkplatz auch auf diesem und belegen nicht die wenigen frei zugänglichen Parkplätze, auf die andere Bewohner ohne eigenen Parkplatz angewiesen sind. Diese guten Nachbarn gehen offensichtlich rücksichtsvoll mit der knappen Ressource Parkplätze um.
Ein rücksichtsvoller Umgang mit knappen Ressourcen wird auch in der App Entwicklung wieder wichtiger. Durch den schnellen technologischen Fortschritt wurden wir in der jüngeren Vergangenheit verwöhnt und sind es gewohnt, dass sich ein Speicher- oder Performance-Problem unserer Software oft mit der nächsten Hardware-Generation quasi von selbst löst („Hit it with Hardware!“).
Ressourcenknappheit im zeitlichen Verlauf
Die Einführung von Smartphones und anderen mobilen Endgeräten hatte zwar zunächst einen ressourcenschonenderen Umgang gefordert, aber auch hier bringt jede neue Hardware-Generation mehr Ressourcen mit sich. Spätestens jedoch mit der Einführung von Wearables und Kleinstgeräten für das Internet of (Every)Thing(s) müssen wir auf Softwareseite wieder schonender mit knappen Ressourcen umgehen. Zu diesen knappen Ressourcen gehören unter anderem Speicherplatz (Disk Space), Hauptspeicher, Rechenleistung und Akku-Kapazität.
Obwohl der Speicherplatz auf Mobilgeräten immer größer wird, reicht er meist dennoch nicht aus. Wir speichern nämlich immer mehr Bilder, Apps, Musik usw. auf unseren Geräten. Apple trägt jüngst seinen Teil dazu bei, die knappe Ressource Speicherplatz besser zu nutzen. So benötigt beispielsweise schon jetzt das Betriebssystem nach manchen Updates sogar deutlich weniger Speicherplatz als zuvor, obwohl oftmals sogar neue Features hinzukommen. Eine solche Verschlankung sollten wir auch berücksichtigen, wenn wir für unsere Apps Updates zur Verfügung stellen.
Um dieses „App Thinning“ zu unterstützen, stellt Apple mit „Slicing“ ab iOS 9 eine neue Funktionalität zur Verfügung. Apps, die für verschiedene Geräte entwickelt wurden (z.B. iPhone 4, iPhone 5, iPhone 6, iPhone 6 Plus, iPad mini, iPad), wurden bisher vollständig auf die unterstützten Geräte übertragen. Zur optimalen Darstellung auf dem jeweiligen Geräte werden hierzu aber mehrere Versionen einer Grafik in unterschiedlichen Auflösungen erstellt. Bisher werden alle Versionen auf jedem Gerät gespeichert. Mit Slicing werden ab iOS 9 automatisch nur noch genau die Versionen übertragen, die vom jeweiligen Gerät benötigt werden.
Um gute Nachbarn zu sein, sollten wir jedoch diesen neu gewonnen Speicherplatz nicht verschwenden, sondern vielmehr darauf achten, wo wir in unseren eigenen Apps noch zusätzlichen Speicherplatz freisetzen können. Reicht vielleicht mal ein stärker komprimiertes JPG aus oder muss es wirklich immer ein PNG sein? Falls es ein PNG sein muss, reichen vielleicht auch mal die 256 Farben eines 8-Bit PNG? Kleine Dateigrößen sind auch gerade für den Austausch zwischen iPhone und Apple Watch hilfreich. Denn wenn wir auf die Uhr sehen, dann wollen wir eins definitiv nicht sehen: Das Lade- bzw. Synchronisations-Symbol. Eine verbesserte Speichernutzung trägt damit auch zu einer besseren Performanz und somit zu einer besseren User Experience bei.
Der sorgsame Umgang mit knappen Ressourcen gilt neben dem Speicherplatz ganz genauso für den Umgang mit Hauptspeicher und Rechenleistung (CPU und GPU). Auch hier gilt zunächst, dass die eigene App auf den ersten Blick nichts davon hat, dass sie sorgsam mit diesen Ressourcen umgeht, solange man nicht an die Leistungsgrenze kommt. Dennoch trägt auch die sorgsame Nutzung dieser Ressourcen zur User Experience des Smartphones bei. Benötigt die aktuell (im Vordergrund) benutzte App weitere Ressourcen, so wird beispielsweise diejenige App vom Betriebssystem beendet, die momentan im Hintergrund die meisten Ressourcen benötigt.
Dies beeinträchtigt nicht nur die Ladezeiten für deren nächstes Öffnen sondern ggf. sogar deren Funktionalität, da Hintergrundoperationen nicht mehr durchgeführt werden können. Wir tun somit gut daran, auf die Ressourcennutzung unserer Apps zu achten (so dass wir zumindest nicht die meisten Ressourcen verbrauchen bzw. verschwenden und damit oben auf der Liste stehen). Dies wird mit der Einführung von „echtem“ Multitasking mit iOS 9 auf dem iPad Air 2 noch wichtiger. Wir können dann nicht mehr davon ausgehen, dass unsere App alleine im Vordergrund ist, sondern sie muss sich die Ressourcen ggf. mit einer weiteren App teilen. Der eigenen App stehen dann ein Drittel, die Hälfte oder der ganze Bildschirm zur Verfügung. Apple empfiehlt hier „Nice-to-Have-Funktionalitäten“ zu opfern, wenn die eigene App derzeit nur zur Hälfte oder einem Drittel angezeigt wird. Die Benutzer werden es danken.
Der sorgsame Umgang mit Rechenleistung wirkt sich zudem positiv auf die Akkulaufzeit aus. Wir erwarten heute, dass wir unser Smartphone den ganzen Tag lang nutzen können („All-day Battery Life“). Im besten Fall müssen wir es tagsüber nicht aufladen. Dies ist jedoch bei intensiver Nutzung des Geräts leider immer noch nicht möglich. Zwar werden die Akkus immer größer und leistungsfähiger, jedoch müssen wir als Softwareentwickler auch hier unseren Teil dazu beitragen. Mit Bezug auf die Rechenleistung gibt Apple hier die Faustregel an „Schneller = weniger Energieverbrauch“.
Wenn wir somit eine rechenintensive Operation durchführen, so braucht eine „naive“ (Algorithmus-) Variante ohne Optimierung am meisten Energie, gefolgt von einer optimierten Operation. Noch weniger Energie benötigt eine Operation, wenn sie parallel von mehreren CPUs ausgeführt werden kann (Multicore-Optimierung). Optimiert man die Operation dann noch durch OpenCL oder GPU Nutzung, so spart man noch mehr Energie. Dies erscheint zunächst nicht offensichtlich, da eine Operation, die parallel mehrere CPUs und die GPU in Anspruch nimmt, natürlich viel mehr Energie benötigt. Laut Apple kann die Operation aber so viel schneller ausgeführt werden, dass es sich am Ende auszahlt. Es lohnt sich somit nicht, einfach naiv jede Operation so umzusetzen, wie man es schon immer gemacht hat, sondern beispielsweise Bibliotheken zu verwenden, die für Multicore-Nutzung optimiert sind.
Schneller = weniger Energieverbrauch. Operationen die bezüglich Multicore, OpenCL und GPU Benutzung optimiert wurden beanspruchen zwar den Prozessor mehr, sind aber deutlich schneller. Operationen mit naiv umgesetzten Algorithmen beanspruchen zwar den Prozessor weniger, durch die lange Rechenzeit wird jedoch am Ende deutlich mehr Akkuleistung verschwendet.
Neben der Multicore-Optimierung habe ich folgende weitere Empfehlungen zur Optimierung der Akkulaufzeit mitgenommen:
Nur dann transparente Overlays in Videos verwenden, wenn wirklich nötig, da diese Overlays energiesparende Mechanismen aushebeln.
Networking (Bluetooth, WLAN, LTE) minimieren. Muss die App wirklich immer im Hintergrund synchronisiert werden, oder reicht es vielleicht die Synchronisation bei der nächsten Benutzung durchzuführen?
Sleep Zustand nicht verzögern.
Operationen erst dann durchführen, wenn der Benutzer deren Ergebnis benötigt.
GPS Nutzung nicht übertreiben. Man muss auch nicht immer gleich alles in der App aktuell halten. Man kann z.B. auch Minutenlang die Position einfach von der Hardware tracken lassen (M7 Motionprocessor) und aktualisiert die App erst später, z.B. sobald die App wieder in den Vordergrund kommt. d.h. verwendet wird.
Operationen dann durchführen, wenn der Benutzer das Gerät gerade aktiv verwendet.
Apple hat zudem iOS 9 hinsichtlich Akkulaufzeit verbessert und verspricht mit iOS 9 auf gleicher Hardware 1 Stunde mehr Akkulaufzeit als mit iOS 8. Hierzu werden beispielsweise folgende Änderungen eingeführt:
Liegt das mobile Gerät mit dem Display nach unten (Face Down), wird das Display nicht eingeschaltet, um eine Benachrichtigung anzuzeigen.
Die Sleep Timer wurden optimiert. So wird das Display beispielweise schneller wieder ausgeschaltet, wenn der Benutzer schon aktiv mit einer Benachrichtigung interagiert. Ohne Interaktion bleibt das Display länger an, da der Benutzer die Benachrichtigung ggf. noch nicht gesehen hat.
Benutzer werden in den Einstellungen informiert, was viel Energie verbraucht und es werden Vorschläge gemacht, wie man den Energieverbrauch verbessern kann.
Außerdem wird mit iOS 9 ein „Low Power Mode“ eingeführt, der bei gleicher Hardware zusätzliche 3 Stunden Akkulaufzeit bringen soll. Aktiviert der Benutzer diesen Mode, so werden beispielsweise keine Background-Downloads durchgeführt und keine E-Mails im Hintergrund abgerufen.
Es bleibt natürlich abzuwarten, ob Architekten, Programmierer und Designer gute Nachbarn sein können und (augenscheinlich) uneigennützig ihre Apps bezüglich des Umgangs mit knappen Ressourcen optimieren. Vielleicht pressen sie auch weiterhin alles bis aufs Letzte aus den verfügbaren Ressourcen raus („Nach mir die Sintflut.“). Hiervor möchte ich auf jeden Fall waren. Es geht nämlich nicht nur um die Optimierung der User Experience des Smartphones für den Benutzer. Ein rücksichtsvoller bzw. rücksichtsloser Umgang mit knappen Ressourcen hat ggf. auch einen Einfluss auf das eigene Business. So kann beispielsweise eine App, die wenig Speicherplatz und Akkulaufzeit „frisst“, momentan sogar ein Alleinstellungsmerkmal (USP) sein. Dies gilt insbesondere für Apps, für die es viele Konkurrenz-Apps gibt, die sich nicht wirklich in ihrer Funktionalität unterscheiden (z.B. Wetter-Apps).
Viel wichtiger ist jedoch, dass Benutzer selbst mittlerweile einen viel besseren Überblick haben, welche Apps die Ressourcen ihrer Smartphones verschwenden. In den iPhone Einstellungen unter „Allgemein->Benutzung->Batterienutzung“ bzw. „Allgemein->Benutzung->Speicher verwalten“ werden alle Apps in einer Rangliste aufgeführt.
Möchte der Benutzer beispielsweise eine App löschen, die seiner Meinung nach zu viel Speicherplatz benötigt, so kann er die App direkt dort löschen. Dazu werden nur 2 Klicks benötigt. Wer jedoch sorgsam mit den knappen Ressourcen umgeht, hat offensichtlich nichts zu befürchten.
Am 16. und 17. Juni tag der Hauptausschuss des DStGB (Deutscher Städte und Gemeindebund) in Bonn. Die Tagung beschäftigt sich den den Themen „Die Stadt der Zukunft gestalten“ und „Flüchtlingsströme meistern – Einwanderung steuern“. Ich halte dort einen Vortrag mit folgendem Titel:
Ich bin vom 08.-12. Juni auf der Apple World Wide Developer Conference (WWDC) 2015 in San Francisco, USA. Die Konferenz läuft dieses Jahr unter dem durchaus selbstbewussten Titel „The epicenter of change.“, was einiges hoffen lässt. Ich freue mich schon sehr und hoffe nächste Woche viel Interessantes berichten zu können.
Der Radio-Journalist Christian Bollert (BEBE Medien GmbH, detektor.fm) berichtete von seinen Erfahrungen beim Vorbereiten und Durchführen von Interviews fürs Radio. Radiohörer haben leider nicht die Möglichkeit bei einem Wort, das sie nicht verstehen kurz anzuhalten und das Wort nachzuschlagen. Auch können sie nicht einfach einige Seiten zurückblättern, um noch einmal etwas nachzuschlagen. Daher müssen Texte im Radio einfach zu verstehen sein. Ich sehe jedoch keinen Grund, warum geschriebene Texte komplizierter sein sollten, schon gar nicht wenn es um Anforderungen geht. Die 10 Grundregeln für Texte im Radio, die Christian Bollert vorgestellt hat, können somit für jegliche Art von Text angewendet werden:
Kurze, verständliche Sätze, möglichst wenig Nebensätze
Gesprochene Sprache, keine Kunstsprache. Nach dem Motto: Wie erzähle ich es einem Freund – mündlich!
Sätze zum Vorlesen sprechend entwickeln (laut vorlesen)
Aktiv statt Passiv; kein Nominalstil, verbal schreiben
Sätze nicht mit Informationen überfrachten
Eines nach dem Anderen erklären
Fremdwörter oder Fachbegriffe sofort erklären oder ganz darauf verzichten
Namen und zentrale Begriffe wiederholen – Redundanz erwünscht! („Redundanz statt Varianz“)
Bildlich vergleichen: So groß wie ein Fußballfeld
Füllwörter nutzen. Sie ermöglichen Atempausen und verbinden (Beispiele: „deshalb“, „darum“, „aus diesem Grund“)
Gerade technische Texte beschreiben oftmals eine überaus komplexe Fachlichkeit. Daher sehe ich überhaupt keinen Grund, warum diese Texte durch umständliche Formulierungen weiter verkompliziert werden sollen.
Requirements Engineers verwenden oftmals leider nicht allzu viel Zeit auf die Vorbereitung von Interviews mit Stakeholdern. Zudem wird bei der Vorbereitung meist nur festgelegt WAS man von einem Stakeholder wissen möchte und leider nicht WIE man eigentlich danach fragt. Auch hier hatte Christian Bollert nützliche Hinweise. Er hat 12 verschiedene Typen von Fragen vorgestellt und dabei neben Beispiele auch beschrieben, unter welchen Umständen man den jeweiligen Fragentyp einsetzen sollte. So soll beispielsweise die Entscheidungsfrage„Was brauchen Kinder ihrer Meinung nach mehr: mehr Freiheit in der Erziehung oder mehr Struktur?“ verhindern, dass der Befragte um den heißen Brei herumredet oder sich einfach herausreden kann. Mehrfachfragen sollten gar nicht gestellt werden, da Befrage eigentlich nur die Einzelfragen beantworten, die ihnen am besten zusagen und sowieso nie alle Einzelfragen beantworten.
Auf die Frage „Was macht einen guten Interviewer aus?“ gab Christian Borschert die folgende Antwort:
Empathie
Geduld
Höflichkeit
Rollendistanz zum Thema
Der letzte Punkt seiner Antwort warf dann jedoch die Frage auf, ob Fachwissen für Interviewer bzw. Requirements Engineers hilfreich oder schädlich ist. Darauf antwortete Christian Borschwert: „Manchmal ist es gut, wenn man ein Experte ist, sich aber traut trotzdem wieder naive Fragen zu stellen. Wenn das gelingt, dann ist man einer der Großen.“ Also: „Sei schlau, stell Dich dumm.“ Aus eigener Erfahrung kann ich mich hier uneingeschränkt anschließen. Es lohnt sich eigentlich immer auch grundlegende Konzepte noch einmal zu klären. So sollte man nicht davor zurückschrecken, z.B. in einem Versicherungsunternehmen noch einmal zu fragen „Was ist eigentlich ein Tarif?“ Darauf folgt leider nicht selten die Antwort „Solche grundsätzlichen Fragen müssen wir hier nicht mehr klären. Jeder von uns weiß, was ein Tarif ist.“ Lassen sie sich nicht abschrecken und fragen sie ruhig weiter nach: „OK, dann erklären Sie es mir bitte dennoch einmal. Ich kenne mich in Ihrer Domäne nicht so gut aus.“ Meist stellt sich dann heraus, dass es doch nicht so klar ist, was ein Tarif tatsächlich ist. Sollten mehrere Personen an der Befragung teilnehmen, so haben diese fast immer ein unterschiedliches Verständnis, selbst (oder gerade) von grundsätzlichen und vermeidlich einfachen Dingen. Es lohnt sich immer mutig zu sein und naive Fragen zu stellen.
In seinem tollen Vortrag „Kultur, Methode, Werkzeug – Drei Bausteine effektiver Anforderungserhebung“ verglich Sebastian Adam (Osseno Software GmbH) Requirements Engineering mit einer Autofahrt von Kaiserslautern nach Leipzig. Auf äußerst unterhaltsame Weise veranschaulichte er die Herausforderungen und Entscheidungen, die beim Aufsetzen und der Durchführung eines unternehmensspezifischen Requirements Engineerings getroffen werden müssen. Immer wieder wurde der Vergleich zu einer Autofahrt gezogen:
Auto = Tool / Methode:
Man kann einen Laster, einen Kombi oder einen Sportwagen verwenden. Mit allen Fahrzeugen (Tools) kommt man ans Ziel. Jedoch hat jeder Autotyp vor und Nachteile. Wenn man genug Zeit hat, kann man sogar mit dem Fahrrad fahren und die Landschaft genießen. Möchte man weniger Aufwand betreiben, kann man auch mit der Bahn fahren (= einen Dienstleister beauftragen).
Straßenbeschaffenheit = Firmenkultur (bzgl. RE)
Man kann über Autobahnen, Landstraßen oder Feldwege ans Ziel kommen. Genauso kann eine Firmenkultur die Arbeiten im Requirements Engineering beschleunigen oder verlangsamen.
Strecke = Prozess
Viele Wege führen ans Ziel bzw. im Beispiel führen viele Wege von Kaiserslautern nach Leipzig. Es gibt auch nicht den einen besten Weg, alle haben ihre Vor- und Nachteile.
Ziel (z.B. Leipzig) = Produkt-/ Projektumfang
Alle vier Punkte müssen jedoch zusammenpassen und aufeinander abgestimmt. Zwar kann man sicherlich mit einem Ferrari über Feldwege von Kaiserslautern nach Leipzig fahren, aber wer will das schon? Sebastian Adam stellte zudem die provokante Frage (natürlich in Bezug auf RE): „Würden Sie mit jemanden von Kaiserslautern nach Leipzig fahren, der keinen Führerschein hat, nicht weiß wo Leipzig ist, nie in einer Fahrschule war und nur sehr selten Auto fährt?“
Ein wichtiger Punkt fehlt jedoch im obigen Vergleich. Wenn wir heute unterwegs sind, möchten wir unser Navigationssystem nicht mehr vermissen. Das Navigationssystem sagt uns genau, wo wir gerade sind, wie lange es noch dauert und wann wir wohin abbiegen müssen. Zudem reagiert unser Navigationssystem auf unvorhergesehene Probleme und bietet uns alternative Routen an. Außerdem bringt uns unser Navigationssystem immer wieder auf die Stecke zurück, falls wir einen kurzen Abstecher gemacht haben. Aber wo ist das Navigationssystem fürs Requirements Engineering? Genau dieser Frage hat sich das Fraunhofer IESE Spin-Off OSSENO angenommen, das Sebastian Adam mit seinen beiden Kollegen Norman Riegel und Özgür Ünalan gegründet hat.
Mit seinem enthusiastischen Vortrag „Von der Idee bis zum Code: Flüssige Anforderungen fließen besser“ eröffnete Kurt Schneider (Leibniz Universität Hannover) den zweiten Tag der Veranstaltung. Insbesondere ging es dabei um die Erstellung von Informationsflussmodellen mit der FLOW (kein Akronym) Notation. Dabei unterscheidet man feste und flüssige Informationen. Feste Informationen (z.B. Dokumente, Bilder, Mitschriften, …) haben den Vorteil, dass sie langfristig zugänglich sind, an viele Empfänger weitergegeben werden können, und vor allem können Dritte ohne Hilfe etwas damit anfangen. Ein großer Nachteil ist jedoch, dass die Erstellung und auch der Abruf (z.B. das Auffinden) von festen Informationen sehr viel Zeit kostet. Flüssige Informationen sind nicht persistiert und somit nur in den Köpfen von Mitarbeitern vorhanden. Diese können jedoch schnell und effizient übergeben werden. Nachteilig ist jedoch, dass diese Informationen an Individuen gebunden sind, kapazitätsbeschränkt sind und mit der Zeit „versickern“. Bei der Informationsflussmodellierung mit der FLOW Notation wird für jede Information angegeben, ob diese fest oder flüssig ist. Kurt Schneider gibt auch nicht vor, wie flüssig oder wie fest ein Informationsfluss sein sollte. Sieht man sich jedoch einen Informationsfluss an, so ist oft leicht zu erkennen, welche Abschnitte „verflüssigt“ werden sollten, da sie zu starr und unflexibel sind. Genauso leicht ist zu erkennen, welche Abschnitte „verfestigt“ werden sollten.
Wenn es ums „Verfestigen“ geht, sollten wir nicht immer gleich an epische Dokumente denken. Informationen können auch auf andere Art persistiert werden. Kurz Schneider schlägt hierzu auch vor, Videos zu verwenden. Videos können auf effiziente Art und Weise Dokumente ersetzen. Dem kann ich mich nur anschließen. Auch wir haben schon sehr positive Erfahrungen mit Videos gemacht. Dabei ist ganz wichtig, dass diese Videos nicht OSCAR-reif gespielt, gedreht, geschnitten und produziert werden müssen. Dem Verwendungszweck angemessen können auch einfach erstellte Videos einen großen Nutzen bringen. Es muss aber auch nicht immer (gleich) Video sein. Ich bevorzuge beispielsweise auch Fotoprotokolle von Meetings. Einfach die Whiteboards, Flipcharts oder sonstigen Ergebnisse, die im Meeting erarbeitet wurden abfotografieren und in einem PDF-Dokument zusammenfassen. Der Aufwand einer manuellen Digitalisierung (d.h. Abtippen der Bilder) bietet oft keinen Mehrwert, der den Aufwand rechtfertigt.
Alles in allem war es wieder mal eine tolle Veranstaltung bei den Softwareforen. Ich freue mich schon auf meinen nächsten Besuch in Leipzig.
Ich komme gerade vom BITKOM UUX Fachgruppentreffen in Berlin und warte am Flughafen Tegel auf meinen Rückflug. Die Teilnahme hat sich voll und ganz gelohnt. Zum angekündigten Streitgespräch kam es jedoch nicht. Im Großen und Ganzen waren sich die Teilnehmer einig, obwohl sehr viel und auch sehr emotional diskutiert wurde. Deutlich mehr als bei ähnlichen Veranstaltungen, vor allem sobald das Thema Scrum oder Design Thinking angesprochen wurde.
Es wurden zwar unterschiedlichste Themen rund um das Thema Usability und User Experience diskutiert, in jedem Vortrag oder der zugehörigen Diskussion wurde jedoch auf die eine oder andere Art über die Evaluation von Usability und UX gesprochen: Wann sollte man mit welcher Methode und wie oft evaluieren? Ulf Schubert (DATEV) hat hierzu etwas Interessantes erzählt. Bei der DATEV muss das gesamte Entwicklungsteam während einer Usability Evaluation anwesend sein. Es sind somit nicht nur die Qualitätssicherungs- und Usability Experten anwesend, sondern alle an der Entwicklung beteiligten Personen. Das Team kann die Testnutzer durch eine Scheibe im Usability Labor beobachten. So bekommt jeder im Team direkt mit, sobald ein Testnutzer ein Problem mit der Benutzung hat. Kommt ein Testnutzer in größere Schwierigkeiten bei der Benutzung, so löst das beim anwesenden Projektteam Betroffenheit aus. Genau das ist das Ziel von Ulf Schubert: „Im Projektteam soll Betroffenheit hervorgerufen werden.“ Ich habe auch schon die Erfahrung gemacht, dass man deutlich besseres Verständnis im Projektteam erreicht, wenn man Videos von Problemen während der Nutzung von Testnutzern zeigt und nicht nur die Anzahl von Problemen in einer Tabelle listet. Zwar hört sich „18 von 20 Nutzern haben das Produkt nicht auf die intendierte Art und Weise gestartet“ auch nicht gerade gut an, zeigt man aber einen Video-Zusammenschnitt dieser 18 (oder 20) Starts, so stellt sich Betroffenheit und anschließend Verständnis im Projektteam viel schneller und eindringlicher ein. Nach Aussage von Ulf Schubert, funktioniert es aber noch besser, wenn das Projektteam live beim Test mit anwesend ist. Das Projektteam hat auch immer Whiteboards zur Verfügung, um direkt Verbesserungsvorschläge zu diskutieren. Natürlich nur untereinander und nicht mit den Testnutzern. Weitere Tipps von Ulf Schubert gibt es in seinem User Experience Blog. Er hat auch zwei Beträge zum Fachgruppentreffen verfasst (Vormittag, Nachmittag).
Eine weitere Interessante Frage, die diskutiert wurde ist: Wer führt zukünftig eigentlich UX Tests durch? Momentan liegt diese Kompetenz hautsächlich bei Beratungshäusern und Usability/UX Agenturen. Derzeit bauen aber immer mehr Design Agenturen diese Kompetenz auf und bieten auch UX Tests an. Hinzu kommt, dass immer mehr Unternehmen eigene UX Test-Kompetenz aufbauen, um die Evaluation selbst durchführen zu können. Immer öfter werden UX Test sogar im unternehmenseigenen UX Labor durchgeführt. Wohin sich das entwickelt, werden wir in den nächsten Jahren feststellen. Es bleibt also spannend.
Mit seinem Vortrag „Do you understand me? Supernatural and innovative interactions“ eröffnete Sascha Wolter (Deutsche Telekom) das Fachgruppentreffen fulminant. Wer die Gelegenheit hat, sollte sich unbedingt einmal eine Präsentation von Sascha Wolter ansehen (hier stehen seine Vortragstermine). Voller Energie und Enthusiasmus berichtete er vom Internet of Things (IoT). Interessant fand ich seine Aussage „Die Erotik-Branche schiebt neue Technologien an.“ Das galt für die das Internet, die DVD, HD-Video, usw. „Als nächstes ist wohl das IoT dran. Es ist unglaublich, was es da schon alles gibt.“
Wenn es um neue Interaktionsmöglichkeiten geht, es ist es wichtig, dass man nicht nur darüber redet, sondern diese unbedingt persönlich ausprobiert. Nur dann kann man wirklich auch wirklich darüber reden. Entwickelt man selbst gerade eine neue Interaktionsform, dann sollte man diese unbedingt prototypisch umsetzen und ausprobieren. Das gilt nicht nur für die Software, sondern auch für die zugehörige Hardware. Es muss ja nicht immer gleich perfekt sein. 3D Drucker, Bausätze und ähnliche Hilfsmittel unterstützen uns heute immer mehr dabei. Sascha Wolter ist ein großer Fan vom Ausprobieren und hat z.B. auch das Autofahren mit einer Blackbox seiner Versicherung getestet, die guten Autofahrern bessere Tarife verspricht: „Ich probiere das alles mal aus und sehe mir an, wozu das führt und erziehe meine Kinder zu einem bewussten Umgang mit Daten.“
Besonders wenn es um das IoT geht bedauert Sascha Wolter, dass die Systeme immer noch zu wenig Empathie besitzen. Wir können heute jede Lampe in jedem Raum unserer Wohnung oder unseres Hauses dazu bringen, genau das richtige Farbschema zu erzeugen, das am besten zu unserer momentanen Gemütslage passt. Allerdings müssen wir dieses Farbschema noch selbst auswählen. Die Systeme können unsere Gemütslage momentan noch nicht ausreichend gut erkennen. Die notwendige Technologie ist hierzu wahrscheinlich sogar schon vorhanden. So gibt es beispielsweise in Japan Getränkeautomaten, die mit einfachen Sensoren die Gemütslage den Käufers (vorgeben zu) erkennen und ein passendes Getränk auswählen.
Am Nachmittag hat Dirk Dobiéy (SAP) mit „Learning from creative disciplines for better outcomes in business and society“ eine weitere beeindruckende Präsentation gehalten. „Es wird immer mehr automatisiert, nicht nur der Börsenhandel, sondern sogar die Berichte über den Börsenhandel. Immer mehr Wissensarbeiter werden automatisiert. Welche Eigenschaften müssen wir denn überhaupt zukünftig haben?“ Dirk Dobiéy und seine Kollegen von Age of Artist glauben, dass solche Eigenschaften in künstlerischen Bereichen gefunden werden können und haben mit Künstlern aus unterschiedlichsten Bereichen gesprochen. Dabei haben sie versucht herauszufinden, was Künstler ausmacht, was sie antreibt und ob es gemeinsame Eigenschaften gibt. Diese Eigenschaften werden dann immer in Bezug oder besser in Kontrast zum momentanen Business-Alltag gesetzt. Um wieder das Beispiel der Evaluation aufzugreifen, ist ihnen beispielsweise aufgefallen, dass in der Geschäftswelt leider immer noch oft gesagt wird „Das gefällt mir nicht!“ oder „Ich würde das nicht so machen!“. Künstler sprechen in einer Evaluation subjektiver und emotionaler „Ich sehe hier…“ oder „Ich fühle dabei…“. Dirk Dobiéy gibt folgende Eigenschaften von Künstlern an, die sie von Geschäftsleuten unterscheiden:
Planning by Doing. Making to Learn.
Exploration without Intention.
Substantial Amounts of Search and Reflection.
Accepting Ambiguity and Crisis.
Appreciating Feeling and Emotions.
Everything is a Derivative: Finding again the New.
Non-Linear.
Zudem gibt Dirk Dobiéy folgende Eigenschaften an, die wir entwickeln müssen, um „Business Artists“ zu sein:
Observation & Listening
Dialogue & Conversation
Exploring & Deconstructing
Abstracting & Simplification
Generating Ideas & Experimenting
Problem Solving
Collaboration & Cooperating
Giving Feedback & Dealing with Critique
Reframing & Improvising
Designing & Performing
Knowledge-Worker benötigen schon heute aber vor allem in der Zukunft andere Fähigkeiten, vor allem Soft Skills. Es reicht zudem nicht aus, nur einen gut ausgeprägten Soft Skill zu haben, sondern wir werden immer mehr beherrschen müssen. Ob es genau diese Skills sind, die im Vortrag angesprochen wurden ist dabei gar nicht so wichtig. Der vorgestellte Ansatz, bei Künstlern nach solche Eigenschaften zu suchen, ist jedoch sehr spannend.
Ich freue mich schon auf das nächste UUX Fachgruppentreffen, das wohl noch dieses Jahr stattfinden wird.
Am 28./29. April bin ich bei den Softwareforen Leipzig in der User Group Requirements Engineering. Das Thema des 10. User Group Treffens ist „Effektive Anforderungserhebung und Ideenfindung im Requirements Engineering“. Seit einigen Jahren setze ich am Fraunhofer IESE gezielt ausgewählte Kreativitätstechniken zur Ideenfindung in unterschiedlichen Bereichen. Zusammen mit meinem Kollegen Jörg Dörr werde ich einen interaktiven Workshop zum „Ausprobieren neuer Kreativitätstechniken“ abhalten.
Am 22. April halte ich einen Vortrag beim BITKOM FA Usability & User Experience (UUX) in Berlin. Das Thema der Veranstaltung ist „Wer braucht schon User Experience?“. Die Veranstaltung läd mit diesem Titel offiziell zu einem „Streitgespräch“. Ich freue mich schon auf eine spannende Veranstaltung. Der Titel meines Vortrags ist:
Neueste Kommentare