{"id":8380,"date":"2018-03-29T15:51:06","date_gmt":"2018-03-29T13:51:06","guid":{"rendered":"https:\/\/www.centigrade.de\/blog\/?p=8380"},"modified":"2018-03-29T15:52:32","modified_gmt":"2018-03-29T13:52:32","slug":"iot-erobern-mit-lean-ux-teil-2","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/iot-erobern-mit-lean-ux-teil-2\/","title":{"rendered":"IoT erobern mit Lean UX \u2013 Teil 2"},"content":{"rendered":"

Vor kurzem hat mein Kollege Simon Kieke im ersten Artikel<\/a> dieses Zweiteilers ein spannendes Fazit zu der Bedeutung von IoT f\u00fcr den Mittelstand gezogen. Statt einer \u201eAlles oder Nichts\u201c Mentalit\u00e4t, schl\u00e4gt er vor, im Kleinen und auf der Basis von Nutzerbed\u00fcrfnissen digitale Services in Bestandsprodukte einzuweben. So entstehen kleine IoT Produkte ohne gro\u00dfe Risiken, die einen unmittelbaren Nutzermehrwert bieten. Hinter diesem Verst\u00e4ndnis von Produktentwicklung steckt das Prozessrahmenwerk Lean UX und die bereits im letzten Artikel beschriebene Kernmethode des Minimum Viable Products (MVP). Aber wie genau definiert man ein MVP und wie l\u00e4sst sich der Projektverlauf durch andere Lean Methoden weiter risiko- und komplexit\u00e4tsreduziert treiben?<\/p>\n

In diesem zweiten Teil der Reihen m\u00f6chte ich gerne an einer konkreten Projektgeschichte aus dem Bereich Produktdesign, den Einsatz verschiedener Lean Prinzipien exemplarisch verdeutlichen. Diese ist im Rahmen meiner Lehrt\u00e4tigkeit in dem Seminar \u201eDesigning the User Experience for Ubiquitous Computing Devices\u201c an der Universit\u00e4t des Saarlandes mit einer Gruppe von Informatikern ohne Designhintergrund entstanden.<\/p>\n

Umfeld der Projektgeschichte ist eine Gastronomiek\u00fcche. Dieser Kontext wurde von den Studenten frei im Zuge einer fiktiven \u201eStart Up\u201c Gr\u00fcndung gew\u00e4hlt.<\/p>\n

\"\"<\/a>

Der ausgew\u00e4hlte Kontext f\u00fcr das \u201eStart Up\u201c (Quelle: https:\/\/pixabay.com\/de\/k\u00fcche-arbeit-restaurant-kochen-731351\/)<\/p><\/div>\n

Der Protagonist: Ein Gastronomiekoch in einer Restaurantk\u00fcche, der sich vor allem auf das Anbraten von Steaks spezialisiert hat. Als Ziel der Unternehmung sollte die Zahl von Fehlern beim gleichzeitigen Kochen unterschiedlicher Fleischgerichte reduziert werden.<\/p>\n

\"\"<\/a>

Schl\u00fcsselszenario von Kennedy Lemeux<\/p><\/div>\n

Die in diesem Rahmen entstandene Schl\u00fcsselpersona (=Prototypischer Nutzer aus der Zielgruppe) Kennedy Lemeux, ist 30 Jahre alt und seit Kurzem verheiratet. Das Schl\u00fcsselszenario (=Typischer Tagesablauf der Schl\u00fcsselpersona) beginnt mit der f\u00fcr ihn erfreulichen Botschaft, dass ihm seine Frau von ihrer Schwangerschaft berichtet. W\u00e4hrend er in der K\u00fcche besch\u00e4ftigt ist schweifen seine Gedanken demnach \u00f6fters mal ab \u2026<\/p>\n

Das f\u00fchrt zu Problemen, denn heute ist ein besonders gesch\u00e4ftiger Tag und er muss au\u00dfergew\u00f6hnlich viele Gerichte zubereiten. Dazu geh\u00f6ren auch einige gute (und teure) Steaks, die er zeitgleich \u00fcberwachen muss. In Gedanken schon bei dem neuen Familiengl\u00fcck, verpasst er leider den richtigen Garzeitpunkt \u2013 sehr zum \u00c4rger seines Chefs. Schade f\u00fcr Kennedy \u2013 eigentlich h\u00e4tte es doch der perfekte Tag werden k\u00f6nnen.<\/p>\n

Sicherlich gibt es hier professionelle K\u00fcchensysteme, die unter anderem auch f\u00fcr diesen Fallstrick eine (integrierte) L\u00f6sung bereitstellen. Doch ein solches System gibt es nicht in jeder K\u00fcche und so auch nicht bei unserem Koch Kennedy. G\u00e4be es nicht auch eine kleinere, leichter umsetzbare L\u00f6sung \u2013 ein MVP \u2013 f\u00fcr sein Problem?<\/p>\n

Ein MVP zu definieren ist keine leichte Aufgabe. Aus diesem Grund sollte man das MVP des Projektes vor Beginn \u201ekurz und knackig\u201c definieren. Dies geschieht im sog. MVP-Statement, welches die Zielrichtung des Projektes in einem einfach verst\u00e4ndlichen Satz formuliert:<\/p>\n

\u201cMit dem Release des Produktes Ende August 2017, wird Kennedy Lemeux in der Rolle des Souschefs darauf hingewiesen, dass ein Steak seiner Aufmerksamkeit Bedarf, um zu verhindern das ihm bei der parallelen Arbeit ein Steak misslingt.\u201c<\/p><\/blockquote>\n

Erkennbar wird hier ein nachvollziehbares menschliches Bed\u00fcrfnis, dessen L\u00f6sung der Zielgruppe einiges an Frustration ersparen w\u00fcrde. Der fremden Dom\u00e4ne und der Komplexit\u00e4t von IoT-Projekten wird durch ein fokussiertes und benutzerzentriertes Projektziel entgegengewirkt.<\/p>\n

Lean Prinzip: Gemeinsames Verst\u00e4ndnis<\/h4>\n

Das kollektive und wachsende Projektwissen muss allen Teammitgliedern schnell und einfach zur Verf\u00fcgung gestellt werden. Dabei handelt es sich zu Beginn um den Kontext, den Nutzer und seinen (Arbeits-) Alltag. Arbeitsergebnisse wie eine Persona, ein Szenario (in Prosa & als Comic) und ein MVP-Statement bringen diesen Zusammenhang standardisiert und pr\u00e4gnant auf den Punkt. Durch diese Designmethoden ist das Team \u00fcber das Ziel des Projektes informiert und wird von hier in die gleiche Richtung laufen. Los geht\u2019s!<\/p>\n

Nutzerforschung<\/h3>\n

Nutzerforschung l\u00e4sst sich sehr aufwendig und zeitintensiv durchf\u00fchren. Unser Projekt ist jedoch bereits im Ursprung \u201eLean\u201c und wir wollen nat\u00fcrlich auch in der Analyse schnell und schlank agieren. Insofern sollte Nutzerforschung nicht willk\u00fcrlich \u201ein der Breite\u201c stattfinden. Stattdessen m\u00fcssen f\u00fcr das Projekt kritische Fragestellung explizit in Form von Annahmen notiert werden. Das Beseitigen dieser \u201eUnsicherheiten\u201c stellt einem unsch\u00e4tzbaren Projektwert dar.<\/p>\n

Lean Prinzip: Annahmen vor Anforderungen<\/h4>\n

Bevor etwas zu einer harten \u201eAnforderung\u201c werden kann, muss ihr Wert f\u00fcr den Endnutzer best\u00e4tigt werden. Erst dann sollten Ressourcen auf Ihre Realisierung gebucht werden. Selbst ein erfahrenes Team kann nicht alles \u00fcber eine Zielgruppe und Ihre Arbeitsabl\u00e4ufe wissen. Eine Produktgestaltung, die auf falschen, nie ausgesprochenen Annahmen aufbaut, kann ihr Ziel verfehlen und im (Arbeits-)Alltag nicht nahtlos oder \u00fcberhaupt einsetzbar sein.<\/p>\n

Wir \u00fcberpr\u00fcfen Annahmen durch Nutzerforschung.<\/a><\/p>\n

Der Begriff \u201eMinimum Viable\u201c Research mag zwar eine Wortneusch\u00f6pfung darstellen, scheint aber mit Blick auf Lean Prinzipien (semantisch) lange \u00fcberf\u00e4llig. In dem oben genannten Seminar hatten wir Gl\u00fcck: Ein Teilnehmer hatte einen Koch in seinem Bekanntenkreis, was hier \u201eMinimum Viable Research\u201c im wahrsten Sinne des Wortes erm\u00f6glichte. Die Erkenntnisse aus einem kurzen Telefonat haben das Projekt nachhaltig gepr\u00e4gt und Designm\u00f6glichkeiten aufgedeckt, die sonst niemals diskutiert worden w\u00e4ren.<\/p>\n

Nun kann man nat\u00fcrlich nicht immer davon ausgehen, dass man pers\u00f6nlich jemanden aus der Zielgruppe kennt. Hier gilt es, pragmatisch zu sein. Der zentrale Zweck von User Research ist, unbekannte Stolpersteine aufzudecken, bevor man dar\u00fcber f\u00e4llt. Daf\u00fcr k\u00f6nnen auch andere (unkonventionelle) Methoden verwendet werden:<\/p>\n