Folien zu „Intellektuelles Kapital im Dienste der UX“

Gestern habe ich einen Vortrag am Institut für Wirtschaftsinformatik der Jade HS zum Thema „Intellektuelles Kapital im Dienste der User Experience“ gehalten, dessen Folien ich soeben bei Slideshare hoch geladen habe.
Nachdem ich einiges an Fahrzeit angesammelt hatte (Köln und Wilhelmshaven sind suboptimal durch die Bahn verbunden), möchte ich mich an dieser Stelle noch einmal für die sehr nette Betreuung vor Ort bedanken! Ich hab mich sehr wohl gefühlt.

Vortrag an der Jade HS

Am 18. April halte ich einen Vortrag am Institut für Wirtschaftsinformatik der Jade HS zum Thema „Intellektuelles Kapital im Dienste der User Experience“. In diesem Vortrag möchte ich mich der Frage stellen, wie Fähigkeiten und Wissen von Mitarbeitern und Beziehungen zu anderen Unternehmen genutzt werden können, um Produkte von besonderer Güte und einem herausragenden Nutzungserlebnis zu schaffen. Ebenso werde ich auf Prozesse und die daraus resultierenden Strukturen eingehen. Die Folien stelle ich anschließend natürlich wieder online. Ich freue mich auf den Norden und hoffe, dass das Wetter bis dahin nicht mehr so frostig ist.

IA Konferenz 2013

Am 3. und 4. Mai findet in der Berlin-Brandenburgischen Akademie der Wissenschaften in Berlin die diesjährige IA Konferenz statt. Dieses Jahr steht sie unter dem Motte „Prozess. Dialog. Qualität.“ und bezieht sich auch auf agile Prozesse und konkrete Erfahrungen des agilen Alltags. Aus diesem Grund halte ich einen Vortrag zum Thema UX in der agilen Produktplanung, in dem ich Erfahrungen und Vorgehensweisen vorstellen werde, die UX bereits in sehr frühen Planungsphasen berücksichtigen. Ich möchte die Fragen beantworten, wie kann man die User Experience trotz ihrer Komplexität in der agilen Planung berücksichtigen kann, obwohl man unter Umständen noch in der Ideenfindung ist, und wie Ideen in geeigneter Form aufbereitet werden, um ein Product Backlog für einen nach Scrum organisierten Entwicklungsprozess aufzubauen.

Das Hotel und die Konferenz sind gebucht und ich freue mich schon sehr auf die Konferenz. Da ich zum ersten Mal dort hin fahre, weiß ich nicht genau was mich erwartet. Die Referentenliste lässt aber viel Gutes erhoffen. Vielleicht sieht man sich ja dort?

 

Nicht-funktionale Anforderungen als User Stories

Werden in einem nach Scrum organisierten Entwicklungsprozess die Anforderungen in Form von User Stories beschrieben, stehen diese für einzelne Features bzw. Aufgabenpakete mit Mehrwert für den User. Betrachtet man jedoch die ganze Palette von Anforderungen, die ein Anwender an sein Softwareprodukt stellt, so fällt auf, dass die nicht-funktionalen Anforderungen nicht als User Stories formuliert werden. Wie kann man aber eben diese wichtigen Anforderungen, die nicht 1-zu-1 auf Features runter gebrochen werden können, in die Anforderungsdokumentation in Form von User Stories in Scrum verorten?

Damit nicht-funktionale Anforderungen messbar umgesetzt werden können, müssen diese vorher in quantifizierbare Einheiten zerlegt werden. Zum Beispiel gibt es die nicht-funktionale Anforderung „Die Anwendung soll performant sein“, welche ohne weiteres nie auf Erfüllung geprüft werden kann. Die Beurteilung würde dann nicht anhand objektiver Kriterien sonder subjektiv erfolgen. Damit aber eine objektive Bewertung erfolgen kann, muss die noch sehr abstrakte Anforderung in quantifizierbare Teilanforderungen zerlegt werden. Dem entsprechend könnten aus der oben genannten Anforderung folgende Teilanforderungen hervorgehen:

  • Die Antwortzeit bei einer Datenabfrage soll auf dem Referenzsystemen in weniger als 200 ms erfolgen.
  • Auf Aktionen des Nutzers soll innerhalb von 200 ms auf dem Referenzsystemen eine Reaktion angezeigt werden.
  • Der Start der Anwendung soll auf den Referenzsystemen nicht länger als drei Sekunden dauern.

Diese beispielhaften und sicherlich nicht vollständigen Teilanforderungen verhalten sich zu der eigentlichen Anforderung genauso wie User Stories zu Epics. Während der Kunde  hauptsächlich eine performante Software möchte („Als Anwender möchte ich eine performante Anwendung haben, damit ich schnell und ohne Wartezeit meine Arbeiten erledigen kann.“), gilt es diese für die vertragliche Basis in messbare Eigenschaften zu zerlegen. Diese zerlegten Teilanforderungen müssen letztlich irgendwie in die Formulierung von User Stories einfließen. In der Definition of Done können die quantifizierbaren Teilanforderungen, sofern sie verallgemeinerbar sind (z.B. „Alle Datenabfragen müssen unter 300 ms ausgeführt werden“, „Alle Inhalte müssen semantisch ausgezeichnet sein“, etc.), aufgeführt werden. Ein großer Vorteil der User Stories liegt jedoch in der Diskussion zwischen Entwicklerteam und Product Owner. Daher erscheint es sinnvoll, dass diese Teilanforderungen in ähnlicher Art verfasst werden. Dies ermöglicht des Weiteren ein besseres Verständnis für den Mehrwert der Anforderung auf Nutzerseite durch die Begründung („damit ich schnell und ohne Wartezeit meine Arbeiten erledigen kann“). Da in der Regel die Fachexpertise über das technisch Machbare beim Entwicklerteam liegt, der Product Owner aber für den wirtschaftlichen Erfolg des Projekts (oder Produkts) verantwortlich ist, hilft die Diskussion ein, im Spannungsfeld zwischen Aufwand und Nutzen, optimales Erzeugnis zu schaffen. Neben der Machbarkeit im Verhältnis zum Aufwand können auch weitere Punkte, wie beispielsweise die Behandlung von Grenzfällen, geklärt werden. Die Diskussion ermöglicht dadurch eine Vervollständigung der Teilanforderungen, zumindest wenn ein offener Dialog geführt wird.

Eine User Story zur Abstimmung einer nicht-funktionalen Anforderung könnte wie folgt aussehen:

User Story

Als Anwender möchte ich eine performante Anwendung haben, damit ich schnell und ohne Wartezeit meine Arbeiten erledigen kann.

Akzeptanzkriterien

  • Die Antwortzeit bei einer Datenabfrage soll auf dem Referenzsystemen in weniger als 200 ms erfolgen.
  • Auf Aktionen des Nutzers soll innerhalb von 200 ms auf dem Referenzsystemen eine Reaktion angezeigt werden.
  • Der Start der Anwendung soll auf den Referenzsystemen nicht länger als drei Sekunden dauern.

Da diese Anforderungen jedoch bei vielen einzelnen User Stories integriert sein werden, ist der Aufwand für die Realisierung nicht einfach zu schätzen. Die Schätzung in Form von Story Points scheint schlichtweg nicht möglich, da diese User Stories immer erfüllt werden müssen und in die Schätzungen der User Stories für funktionale Anforderungen einfließen. Sind die nicht-funktionalen Anforderungen jedoch in dieser Form aufgeführt und besprochen, können sie als Anhang oder durch ihre Akzeptanzkriterien direkt zur Definition of Done hinzugefügt werden. Wird die Anzahl der nicht-funktionalen Anforderungen übersichtlich gehalten, können die User Stories mitsamt der Definition of Done ausgehangen werden. Natürlich empfiehlt es sich dann auch, wie bei der Definition of Done üblich, diese von Zeit zu Zeit zu überprüfen und auf die veränderten Gegebenheiten eines Projekts oder Produktumfelds hin zu aktualisieren.

Abschließend ist ein großer Vorteil von separaten User Stories für nicht-funktionale Anforderungen, dass sich die Anforderungen nicht mehr in den normalen User Stories verstecken, sondern an einer zentralen Stelle definiert sind. Dadurch werden sie nicht übersehen, zumindest nicht, wenn die Definition of Done regelmässig geprüft wird. Daher ein klares Ja für nicht-funktionale Anforderungen als User Stories!

User Stories ohne User

Schon seid geraumer Zeit werden vieler Orts User Stories verwendet, um die Anforderungen an ein Produkt mit der Perspektive des Anwenders zu beschreiben. Sie dienen unter Anderem dazu bei den Projektbeteiligten wie Projektleiter, Designern oder Entwicklern mehr Aufmerksamkeit auf den Anwender und den konkreten Mehrwert für diesen zu legen. Daneben gibt es jedoch auch Aufgaben, die dem Nutzer keinen direkten Mehrwert geben oder für die es keine Motivation von Seiten des Nutzers gibt. Ein größeres Refactoring macht manchmal durchaus Sinn, damit die Wartbarkeit der Anwendung gesteigert wird. Dem Nutzer bringt sie jedoch keinen Mehrwert. User Stories in der Form von „Als Anwender möchte ich, dass die Softwarekomponente FileLoader refaktoriert wird, damit die Anwendung besser wartbar ist.“ sind schlichtweg gelogen. Der Anwender will das nicht, denn er kennt die Komponente nicht einmal. Auch die Bereitstellung von Funktionalitäten, die erst die Realisierung normaler User Stories ermöglichen, müssen möglich sein. Vielleicht ist die Refaktorierung notwendig um ein neues Feature überhaupt implementieren zu können. Wie aber kann man das Konzept der Story auch in diesen Situationen nutzen zu können?

Ein Hauptaspekt von User Stories ist, dass ein Mensch in einer Rolle eine Anforderung aus einer Motivation heraus mitbringt. Dies hat den Vorteil, dass, durch die zur User Story gehörende Diskussion, weitere Lösungen und Betrachtungsweisen gefunden werden können. Alle an der Diskussion Beteiligten können sich in die Rolle versetzen und versuchen den Mehrwert der Story nachzuvollziehen. Dies funktioniert auch, wenn es sich bei der Rolle nicht um einen User sondern um einen Entwickler handelt.

Beispiel 1: Als Entwickler möchte ich eine hohe Testabdeckung meines zu überarbeitenden Code haben, damit mir Fehler durch meine Weiterentwicklung früher auffallen.

In dem Beispiel 1 wird die Wartbarkeit gesteigert und damit ein strategischer Mehrwert der Anwendung erzeugt. Davon hat der Anwender nicht direkt etwas, auch wenn er langfristig eine stabilere Software bekommen dürfte.

Beispiel 2: Als Entwickler möchte ich die aktuelle Version von jQuery nutzen können, um von einer höheren Performance und wenigeren Bugs aus der alten Version profitieren zu können.

Bei Beispiel 2 wird eine Systemkomponente ausgetauscht, wodurch der technologische Stand aktualisiert wird. Dem Nutzer entspringt auch hier kein direkter Mehrwert, jedoch werden dadurch neue Entwicklungen möglich, von denen Nutzer anschließend Nutzen ziehen können.

Beispiel 3: Als Entwickler möchte ich auf eine Datenbankabstraktionsschicht zurückgreifen können, die die Datenbank soweit abstrahiert, dass ich mit verschiedenen Datenbanken arbeiten kann ohne mich um Anpassungen kümmern zu müssen.

Im letzten Beispiel wird vielleicht neben MySQL bald auch Oracle unterstützt; ein direkter Nutzen für den Anwender entsteht jedoch nicht unbedingt. Als Anwender einer Webanwendung würde ihm das wahrscheinlich nicht einmal auffallen.

Letztlich lassen sich die ganzen Rollen von Entwicklern zu Designer über Supporter bis hin zum Anwender zu der Menge der Stakeholder zusammen fassen. Dadurch sind alle vom Projekt oder Produkt Betroffenen abgedeckt. Es erscheint sinnvoll, das Konzept und Verständnis von User Stories zu Stakeholder Stories zu erweitern, wobei der Begriff Story wahrscheinlich schon ausreicht um genug Charakterisierung in diese Art der Anforderungsdokumentation zu bringen. Es geht also darum die Vorteile von User Stories auch für technische Aufgaben oder organisatorischen Aufwand zu verwenden.

UX und die Schlucht

Geoffrey A. Moore adaptierte in „Crossing the Chasm“ den „Technology adaption lifecycle“ dahingehend, dass es zwischen den Early Adoptern und der frühen Mehrheit eine Schlucht gibt. Diese virtuelle Schlucht (orig. „the chasm“) steht für eine Hürde von disruptiven oder nicht iterativen Innovationen, die überwunden werden muss, um die Mehrheit der Nutzer zu erreichen. Jede Nutzergruppe im Lebenszyklus eines Produkts muss anders angesprochen werden und Anmerkungen sowie Kritik der Early Adopter kann helfen diese Schlucht zu überwinden. Early Adopter werden sich über Mängel in der pragmatischen und hedonischen Qualität äußern. Ist ein Produkt nicht „schön“ oder „praktisch“, obwohl es für Early Adopter ausreichend attraktiv ist, wird es nicht zur Mehrheit der Nutzer vordringen. Early Adopter können durchaus auch mit der rein pragmatischen Qualität einer eher technologisch orientierten Neuerung leben, jedoch ist dies für die Mehrheit nicht attraktiv. Ich erinnere mich dabei gerne an die ersten Versionen von Android, das meiner Meinung nach erst mit der Version 4 einen Grad erreicht hat, der auch für die Mehrheit attraktiv ist. Die Differenzierung von der Konkurrenz ist durch die geänderte Designlinie stärker und viele Features sind leichter zu bedienen. Wie es nun bei Android geschehen ist, muss es auch bei anderen Produkten geschehen, damit diese über die Phase der Early Adopter hinausgehen können.

Neben den klassischen Ansätzen der Ergänzung der pragmatischen Qualität (also welche Funktion fehlt noch) ist es meiner Meinung nach sehr wichtig die hedonische Qualität ebenso zu berücksichtigen und weiter zu entwickeln, eben auf Kritik in der Form „das ist nicht schön“, „das ist aber nicht cool“ und ähnlichem zu reagieren. Dem entgegen steht jedoch auch der Aspekt der Originalität, denn Produkte der Early Adopter können alleine durch ihre Ungewöhnlichkeit auf den Nutzer originell wirken. Gelangt ein Produkt im Lebenszyklus zur Mehrheit, wird es normal und verliert das Besondere. Die ersten Smartphones waren ungewöhnlich, heute sind sie üblich. Die ersten MP3-Player waren technologische Prachtstücke, heute sind sie Gang und Gebe. Die ersten Autos waren auffallend, heute sind es die Kutschen. Dies macht noch einmal die Wandlung der User Experience im Wandel der Zeit, oder genauer im Fortschreiten des Produktlebenszyklus, klar. Diese kann also nicht einmal designed, sondern muss fortwährend gestaltet werden.

Das persönliche Informationsmanagement

Der Aufbau des eigenen Informationsmanagements ist eine wichtige Aufgabe, die in ihrer Art und Weise in den letzten Jahren eine enorme Veränderung erfahren hat. Während vor 30 Jahren es noch üblich war, dass die Sammlung extern durchgeführt wurde und man sich eine entsprechende Tageszeitung besorgte und so eine Sammlung an relevanten Themen vorgesetzt bekam, ist das Format der Zeitung heute nicht mehr in der Art nicht mehr zeitgemäß. Die Themen des eigenen Bedarfs sind sehr weit auseinander divergiert und die Verbreitung multimedialer, mobiler Medienkonsumgeräte ist stark gestiegen. Die Nutzer haben gelernt ihre Informationen sehr zielgerichtet zu erhalten, kennen sie doch Suchmaschinen, Newsletter und Social Networks.

Tatsächlich ist die Informationsbeschaffung weniger das Problem geblieben, sondern die Informationsauswahl hat an Bedeutung rasant zugenommen. Begriffe wie Informationsflut sind zum allgemeinen Sprachgebrauch übergegangen und die Kompetenz der persönlichen Informationsaufbereitung und -selektion ist von bisher nie dagewesenen Wert. Wie also vorgehen?

Ich habe mir dazu einige Gedanken gemacht und recherchiert. Dabei sind mir RSS-Feeds, Google Alerts und Social Networks als meine primären Informationsquellen besonders positiv aufgefallen. Diese lösen mein Problem der Informationsbeschaffung, da ich gezielt Suchanfragen und Blogs abonnieren, bzw. in relevanten Foren und Communitys suchen kann. Dies löst jedoch nicht mein anschließendes Problem der Informationsselektion. Daher habe ich zuerst begonnen alle Informationen zu zentralisieren. Dabei hilft mir ein Online-RSS-Reader, in diesem Fall Google Reader. Die Google Alerts sind schnell als RSS Feeds eingebunden, die Blogs schnell übertragen und die Foren soweit möglich auch per Feed integriert. Nun habe ich zwar alle Informationen zusammen aber noch nicht übersichtlich aufbereitet. Die E-Mailartige Übersicht von Google Reader hilft mir da leider wenig. Kurze Textzeilen und Informationen zum Erscheinungszeitpunkt helfen mir nicht viel und sind nicht besonders aufregend.

Das Problem habe ich mit Hilfe von Feedly gelöst. Auffallend hübsch ist die Darstellung der mitgelieferten Bilder als Kacheloptik. Die Bilder verhelfen mir zu einem besseren Erlebnis und sprechen mich emotional an. Kein Vergleich zu den langweiligen Textlisten. Das gesamte Design ist meiner Meinung nach sehr gelungen. Besonders die Möglichkeit, Feedly im Chrome oder Firefox als App einzubinden, auf meinem Androidsmartphone und meinem iPad zu installieren und jederzeit nutzen zu können erscheint mir sehr attraktiv.

Für mich ist das nun eine moderne Alternative zur Zeitung. Die für mich relevanten Informationen sind visuell ansprechend aufbereitet und auf vielen Plattformen syncronisiert. Da macht auch tägliches Zeitunglesen Spaß.

Markante Namen von Personas

Durch den regelmässigen Einsatz von Personas und dem Erstellen von Charakteren für Rollenspiele habe ich ein paar hilfreiche Regeln zur Namenswahl für mich gefunden. Dabei stehen vor allen die Wiedererkennung und die Erinnerbarkeit eine große Rolle. Zum Einen verwende ich gerne Kombinationen aus Vor- und Nachnamen, die einen markanten, aber harmonischen, Sprachrythmus haben (z.B. Susanne Marianne …) und zum Anderen nutze ich oft den gleichen Anfangsbuchstaben oder der gleichen Anfangssilbe bei Vor- und Nachnamen (z.B. Hans Hartmut, Erik Ehrenfeld, etc.). Was an den vorgenannten Beispielen auch auffällt, ist die Wahl typischer Vornamen des sozialen Milieus der Zielgruppe. Dies hat natürlich mit den Vorurteilen bei Namen zu tun. Gleichzeitig darf ein solcher Name nicht zu komplex und kompliziert sein. Eine Persona mit Namen „Anne Maria Claudia Sophie von Humpelfelsen“ ist vom Namen zu lang und wird dann mit einem Spitznamen verfremdet. Das liegt ja nicht in unserem Sinne.

Siehe auch:

Folien zur Langversion „UX in den frühen Phasen des Innovationsprozesses“

Gestern war ich auf dem World Usability Day 2012 in Bremen. Die Folien zu meinem verlängerten Vortrag zum Thema „UX in den frühen Phasen des Innovationsprozesses“ findet ihr nun unter Slideshare. Der Tag in Bremen war sehr schön und ich möchte mich an dieser Stelle noch einmal beim Orgateam für die ausgezeichnete Arbeit bedanken. Habt ihr sehr gut gemacht!

Innovationsmanager (IHK) – Eine Retrospektive

Vom 25.09. bis zum 30.10.2012 habe ich am Lehrgang zum Innovationsmanager (IHK) an der IHK Köln und gehalten von Robert Freund teilgenommen. Da vor Kurzem der Abschlussworkshop war, glaube ich, es ist Zeit für eine Retrospektive.

Meine Erwartungen waren hoch, da ich nach Besuch des Projektmanager (IHK) bei Herrn Freund die guten Erfahrungen dort als Maßstab nahm und entsprechendes wieder erwartete. Dem standen meine Vorkenntnisse entgegen, denn ich wusste schon etwas z.B. über verschiedene Prozessmodelle und die Differenzierung der unterschiedlichen Arten von Innovation. Diese hatte ich mir im Beruf angeeignet und auch schon mit anderen Themenfeldern verbunden. Da der Kurs sehr offen konzipiert war, waren dem entsprechend auch viele unterschiedliche Berufe und Tätigkeitsfelder vertreten. Dies hatte zur Folge, dass man immer etwas an der Oberfläche blieb und ich selber die Transferleistung des Erlernten in die Softwareentwicklung bringen musste. Dies hat etwas gedauert, aber dadurch war die Erkenntnis umso größer.
Als Prüfungsleistung mussten neben der regelmässigen Teilnahme an den Präsenztagen Einsendeaufgaben online bearbeitet werden. Dies gestaltete sich recht einfach, aber manchmal etwas umfangreicher. Die Lerninhalte wurden in einem eigens bereit gestellten Moodle angeboten, wo auch die Einsendeaufgaben bearbeitet werden mussten. Neben den Teilnahmen und den Einsendeaufgaben wurde in der Gruppe eine Dokumentation für die Fallstudie erarbeitet. Diese hat tatsächlich einiges an Zeit benötigt. Am Tag des Abschlussworkshops wurde diese abgegeben und in der Gruppe mit einer Powerpointpräsentation präsentiert. Eine vorgelagerte Klausur bildete eine Wissensabfrage in der Art wie man sie vom Studium her kennt.

Was nach dem Abschluss bleibt, ist das Gefühl etwas gelernt zu haben und die Motivation dieses nun anzuwenden und etwas zu bewegen. Diese Motivation scheint es auch bei den anderen Teilnehmern zu geben, wenn man das Feedback am letzten Tag zusammen fasst. Ich bedanke mich sehr für die interessanten Inhalte, die hervorragende didaktische Aufbereitung und  die sehr positive Lernatmosphäre. Als Fazit kann ich Kurs und Referent nur empfehlen! Beide Lehrgänge (Projektmanager und Innovationsmanager) haben mich sehr überzeugt und bleibenden Eindruck hinterlassen. Vielen Dank für das Erlebnis und das Gelernte! Die Organisation des Lehrgangs war zusätzlich rundherum gelungen. Kaffee, Wasser und Fruchtsäfte waren immer ausreichend vorhanden und gelegentlich ergänzten Kekse das Angebot. Die Anmeldung lief wunderbar reibungslos und prompt. Warum also nicht noch einmal bei der IHK Köln einen Lehrgang besuchen, vor allen wenn Herr Freund als Referent durch die Inhalte führt und einem bei der Konstruktion des Wissens hilft? Aus meiner Sicht spricht nichts dagegen… den Wissenmanagers gibt es ja auch noch. Vielleicht, wenn ich einmal Zeit und Lust habe etwas Neues zu lernen, also bald.