Schon seit einer kleinen Weile beschäftige ich mich mit dem Einsatz von Personas als Konkretisierung der „User role“ in User Stories. Obwohl ich es in der Praxis noch nicht so oft gesehen habe, können auch nicht-funktionale Anforderung in Form von User Stories niedergeschrieben werden. Natürlich lassen diese sich nicht in einer abgeschlossenen Entwicklungszeit (z.B. ein bis zwei Sprints) realisieren, jedoch sind sie als stete Erinnerung hilfreich und die zur User Story gehörigen Akzeptanzkriterien helfen die meist schwer fassbaren Anforderungen auch prüfbar zu halten. In Verbindung mit Personas jedoch, bekommen die User Stories für nicht-funktionale Anforderungen einen direkten Bezug zu dem zukünftigen Nutzer. Die Akzeptanz der nicht-funktionalen Anforderung bei den Projektbeteiligten (z.B. Projektmanager, Programmierer, Designer, etc.) steigt, da die Motivation für die Anforderung emotional leichter erfassbar wird. Des Weiteren kann eine Persona auch genutzt werden, um die nicht-funktionalen Anforderungen auf Erfordernis zu prüfen. Ist eine bestimmte Reaktionsgeschwindigkeit wirklich richtig gewählt oder ist sie doch zu langsam oder kürzer als notwendig? In diesem Zusammenhang werden natürlich messbare Werte mit gefühlten Werten verglichen, was zu Schwierigkeiten im Verständnis führen kann. Eine Anwendung, von der 90% der Oberfläche nach einer Sekunde zur Verfügung steht, kann schon schnell wirken obwohl die restlichen 10% noch zehn Sekunden brauchen. Wann also ist eine Anwendung schnell? Eine entscheidende Frage, die bei der Verwendung von Personas beantwortet werden sollte. Durch diese Antworten wird sich die User Experience des Nutzers erhöhen, denn der Fokus wird von der technisch-faktischen zur gefühlten-wahrgenommenen Anforderung.
Vortrag über Scrum
Ich habe vor einer Weile an der HS Emden/Leer einen Vortrag über Scrum gehalten. Ziel war es einen schnellen Überblick über Scrum als agile Projektmanagementmethode zu geben.
Tierische Personas
Da ich nun seit einiger Zeit auch im Bereich Smarthome unterwegs bin, habe ich eine unkonventionelle aber durchaus sinnvolle Art von Personasmfür mich entdeckt. Eine nichtmenschliche Persona in Form einer Katze hilft dabei die Sichtweise der Projektbeteiligten zu erweitern, da auch unbeabsichtigte Interaktionen mit den Smarthome-Komponenten vorkommen können. Bei jedem Feature kann also unter Berücksichtigung der Persona „Basti“ darauf geprüft werden, ob durch die Interaktionen auf unkonventionale Art Probleme auftauchen.
Persona: Basti, der Neugierige
Basti ist eine männliche, zwei Jahre alte Hauskatze. Mit seinen etwa 50 cm Länge und seinen vier Kilo Gewicht, ist er ein durchschnittlicher Kater. Er ist sehr neugierig und klettert gerne auf Fensterbrettern und Regalen herum und spielt hinter den anderen Möbeln verstecken. Leider ist es schon häufiger vorgekommen, dass er etwas herunter geworfen hat. Jedoch schafft es der schmusefreudige Kater immer wieder die Hausherren zu beschwichtigen.
Natürlich ist diese Art von Persona nicht geeignet um die Anforderungen an das System auf klassische Weise zu bewerten. Sowohl Usability und User Experience spielen hier keine Rolle. Vielmehr ist diese Art von Persona dazu geeignet, die Anforderungen kritisch zu prüfen und das resultierende System so abzurunden.