In seiner Funktionalität auf die Lehre in gestalterischen Studiengängen zugeschnitten... Schnittstelle für die moderne Lehre
In seiner Funktionalität auf die Lehre in gestalterischen Studiengängen zugeschnitten... Schnittstelle für die moderne Lehre
In diesem Kurs wurden Konzepte des Lean Startup mit denen von Agile Development sowie User Experience Methoden theoretisch verknüpft und praktisch erlebt. Neben den notwendigen theoretischen Fundamenten liegt das Augenmerk auf stetigem und vielfältigem Erproben, Scheitern und Verbessern (Build – Measure – Learn) unterschiedlicher Systeme und Services.
Zu beginn des Semesters startete eine hälfte des Kurses in einem sehr intensiven "Eintagesworkshop" mit den ersten Sprints. Aus dieser Runde gingen bereits erste Ideen und Ansätze für das zu bearbeitende Semesterthema hervor. Danach folgten umfangreiche Theorieeinheiten sowie die Bearbeitung unseres gewählten Themas, welche im folgenden Zusammenfassend erläutert sind.
Agile Entwicklungsprozesse erlauben es, flexibel auf Änderungen funktionaler Anforderungen zu reagieren und diese gut zu beherrschen. Aber wie stellt man zwischen User Stories, Sprints und Stand-up Meetings sicher, dass die Belange des Nutzers nicht zu kurz kommen? Die nutzerzentrierte Entwicklung von Software entsprechend der Grundsätze von „Lean UX“ ist hierfür eine geeignete Methode.
Lean UX basiert auf der Mischung verschiedener Denkansätze, um Prinzipien und Methoden zur Verbesserung der Usability und User Experience in eine agile Entwicklung zu integrieren. Der Grundgedanke stammt aus der amerikanischen Start-up-Szene. Lean UX stellt jedoch keine völlig neue Philosophie dar, sondern vereint vielmehr Ansätze der - Bereiche „agile Entwicklung“, „Design Thinking“ und „Lean Startup“. Die einzelnen Bereiche greifen sinnvoll ineinander und führen so zu einer schlanken („lean“), nutzerzentrierten Entwicklung von Produkten.
Ein Grundpfeiler von Lean UX sind agile Entwicklungsprozesse wie Scrum. Das iterative Vorgehen in Teams und das damit verbundene Umsetzen kleiner, gut beschreibbarer Pakete ermöglicht es, regelmäßig kleine, schnelle Tests durchzuführen. Ihre Ergebnisse fließen wiederum direkt in die weitere Entwicklung der nächsten Sprints ein.
Design Thinking, die zweite Säule von Lean UX, beschreibt eine lösungsorientierte Denkweise. Im Fokus stehen dabei zuerst das vollständige Verstehen des Problemkontextes und eine uneingeschränkte Kreativität bei der Lösungsfindung. Durch eine gesunde Portion Rationalität werden gefundene Lösungen dann an den Problemkontext angepasst. So lassen sich auch komplexe Probleme zunächst gründlich analysieren und angehen.
Um im Laufe dieses iterativen und kreativen Prozesses aber auch den richtigen Weg zu finden, bedient sich Lean UX bei der Denkweise von Lean Startup: Alles ist eine Hypothese und folglich zu überprüfen. Das ergebnisoffene Vorgehen setzt einen beständigen Lernprozess in Gang. Das Team lernt mithilfe von Experimenten über die Nutzer und den Markt. Damit das funktioniert, muss man sich jedoch bewusst sein, dass Scheitern zum Lernen dazu gehört. Nicht jede Hypothese wird validiert werden, nicht jedes Experiment die erhofften Ergebnisse liefern.
I can not learn without failing, and i can not fail without learning. Jared M. Spool, UIE
> Wie kann der Arzt im Krankenhaus durch die zeitliche Darstellung unterschiedlicher Ereignisse in der Patientenhistorie bei seiner täglichen Arbeit effektiv unterstützt werden?
> Wie kann der Arzt mit den richtigen Informationen zur richtigen Zeit bei der Behandlung seiner Patienten/seiner täglichen Arbeit im Krankenhaus effektiv unterstützt werden?
> Zeitliche Darstellung von unterschiedlichen Ereignissen in der Patientenhistorie (mit Fokus auf Erkennung der krankheitsrelevanten Zusammenhänge) zur Unterstützung des Arztes bei seiner täglichen Arbeit im Krankenhaus.
Problem > Ärzte haben wenig Zeit für Patientenüberblick und Behandlung
> Viele Patienten mit unterschiedlichen Krankheitsverlauf (Arzt kann sich nicht an alles erinnern)
> Unterschiedliche Informationen je nach Patient/Erkrankung relevant
> Unterschiedliche Informationen je nach Fall (OP, Visite) relevant
> Arzt: Onkologe, Radiologe, Neurologe, Nephrologe
> Patienten: Krebspatienten, Patienten mit Spenderniere/Nierentransplantation, Psychisch erkrankte
Tägliche Arbeit > Lokation: festes Behandlungszimmer, Visite, ambulant, Notfall-OP-Saal
> Aufgaben: Untersuchung, OP, Aufnahmegespräch, Kontrolle, etc.
> Arbeitszeiten: Tag, Nacht, Schichtarbeit
> Verwendete Geräte: PC, Laptop, Tablet, Smartphone, Wearables
> Wie kann ein digitales Produkt den Patienten bei seiner Therapie/ seinem Krankenheitsverlauf unterstützen?
> Wie kann ein Patient mit Nierentransplantation bei seiner Therapie durch den Einsatz von digitalen Produkten effektiv unterstützt werden?
Problem > Patienten verstehen Krankheit oft nicht (Fachbegriffe, Entstehung, Zusammenhänge, etc.)
> Arzt hat wenig Zeit für ausführliche Erklärungen, Patient muss sich selbst informieren -> Motivation? Welche Quellen?
> Besprechungen/Rückfragen meist nur nach festen Terminen
> Patient hat keinen Überblick über Therapieverlauf
> Feedback über Verbesserung/Verschlechterung des Zustandes fehlt Digitales Produkt?
> PC, Laptop, Tablet, Smartphone, Wearable, Chips
Patienten: Krebspatienten, Patienten mit Spenderniere/Nierentransplantation, Psychisch erkrankte, Diabetes, M.S.
Wir entschieden uns für das Thema 1 mit dem Schwerpunkt auf die Unterstützung der Ärzte. Um mit der Bearbeitung loslegen zu können benötigten wir exestierende Probleme bzw. Schweirigkeiten die im Alltag eines Arztes/einer Ärztin vorhanden sind. Diese gewannen wir zum einen aus Recherchen, jedoch maßgeblich aus einem Interview mit einer angehenden Ärztin.
Aus dem Gespräch kristalisierten sich schnell die wesentlichen Painpoints bei der bewälltigung des Alltages in einem Krankenhaus heraus. Basierend auf diesen Aussagen entwickelten wir erste Ideen.
Persona > Martina > 27 Jahre > angehende Ärztin > Anähstesie, Chirurgie und innere Medizin > nach Abschluss arbeitet sie im Krankenhaus
Pain-Points > analoge Patientenakten > Datenübertragung innerhalb des Krankenhauses unzureichend > Datenabgleich zu Abrechnungszwecken > Anfragen beim Hausarzt
Hypothese: Wie können wir [person] bei [aufgabe] unterstützen, wenn [situation / paint point]?
Nach der Erarbeitung unseres Ideenpools wurden diese Bewertet und selektiert. Sie sollen nun die Grundlage unserer weiteren Arbeit sein.
Unsere Idee ist eine Patientenhistorie die auf der Krankenkarte abgelegt ist oder auf einer unabhängigen Datenbank hinterlegt ist. Dabei dient die Krankenkarte als Authentifizierungsschlüssel.
Da sich heraus stellte, dass vorallem eine konsistente Verfügbarkeit der Patientendaten problematisch ist, konzentrierten wir uns auf die Entwicklung einer Patientenhistoriensoftware. Um das Programm sinnvoll strukturieren zu können, erstellten wir eine Infomap basierend auf einem Arztbrief. Diese Infomap vermittelt uns die Komplexität und hilft uns auch hier wieder zu priorisieren.
Mittels der Infomap konnten wir die relevantesten Menüpunkte mit ihren dazugehörigen Unterfunktionen clustern. Im Vordergrund stand eine einfache schnelle Beidenbarkeit. Zu beginn stand ein Prototyp aus Papier der aber schnell durch einen digitalen ersetzt wurde. Bei ihm konnten Änderungen leichter eingepflegt werden. Wir durchliefen mit unserem Prototypen mehrere Testdurchläufe bei denen wir auf die intuitive Bedienbarkeit achteten und problemstellen direkt anpassen konnten.
[MVP testen >>>](https://invis.io/KVFYXHP8GWH#/280658509_AID_01 „AID 1.0“)
Von nebulösen Annahmen zu klaren Produkt-Features
Globale Hypothese Wir glauben, dass [Annahme]. Unsere Annahme ist korrekt, wenn wir [Verhalten, Feedback, Kennzahlen-Veränderungen] beobachten können.
Subhypothese Wir glauben, dass [Realisierung eines Features, einer Nutzererfahrung] für [bestimmte Menschen / Personas] in [Ergebniss] resultiert.
Wir werden richtig liegen, wenn wir folgendes sehen: [Markt-Rückmeldungen, quantitative Erkenntnisse].
Annahme: eine abstrakte Ansicht über die Welt (Nutzer, Bedürfnisse, Trends, Marktnischen etc.)
Hypothese: Operationalisierung der Annahme
Ergebnisse: Validierung der Hypothese
= hypothesenbasierende, ständig wachsende und validierte, prototypische Beschreibung der Menschen, für die eine Lösung gedacht ist
Name Alter, Geschlecht
Background & Experience: Finanzamtbeamtin, Raucherin, Diabetis Typ 2 (Altersdiabetes), BMI = 27, muss Insulin spritzen
Main Tasks: > Strukturierte Medikamenteneinnahme > Blutzuckerkontrolle > Diät > Arzt-Termine einhalten > BE kontrollieren
Sub Tasks (for certain groups): > Wissen: warum Diät? > Wie Diät ausgestalten > Blutzucker kontrollieren > Blutzucker protokollieren
Main Contacts > Sohn > Arzt > Kollegen
Main Goals > Gesund werden > Lebenswertes Leben führen
Needs > ...
Personal Environment > zu viele Meetings > Sohn > Kollegen mit verführerischen Kuchen
Pain Points > Weder Zeit noch Lust, regelmäßig Sport zu machen
> Symptome: Konzentrationschwächen, Wassereinlagerungen, Bluthochdruck
> Stress (Arbeit, Krankheit)
> Oft Heißhunger
> Atemnot bei Treppensteigen
> Vergisst oft, Medikamente zu nehmen
> Muss häufig Arzttermine verschieben, um berufliche termine wahrzunehmen
Minimum Viable Product Das Minimum Viable Product (MVP) beschreibt eine der Kernmethoden von Lean UX. Es verdeutlicht die Konzentration auf das Wesentliche und somit die kleinstmögliche erste Version eines Produkts. Und diese gilt es dann – im Rahmen von Annahmen und Tests – direkt am Markt und mit echten Nutzern zu überprüfen.
Dabei muss das MVP längst nicht jede Funktion des fertigen Produkts enthalten. Es genügt vielmehr eine erste, einfache Version, die dem Nutzer bereits einen gewissen Mehrwert bietet. Durch die Einschränkung auf die wesentlichen Features ist ein MVP häufig schnell umsetzbar und somit auch geeignet, um Annahmen früh und kostengünstig zu überprüfen.
> Menschen nutzen ein reales System - das Backend ist ein Mensch, der alle Systemreaktionen und - veränderungen manuell „spielt“.
Wofür? > Neue Interaktionsformen testen
> „natürliche“ , „intuitive“ Interaktionsformen (Sprache, Gesten, Blicksteuerung, ect.) herausfinden
> Reaktionen auf „futuristische“ Systeme (z.B. smart home, Assitenten), (auch negative Reaktionen)
Kolloaborativ > alle Aktivitäten und Verantwortlichkeiten für UX Research werden an das gesamte Team verteilt
> Ziel: alle lernen zusammen, alle haben ein tiefgreifendes, gemeinsames Verständnis
> Alle Team-Mitglieder sind bei Interviews / Beobachtungen dabei, um gemeinsam von Nutzern zu lernen
> UX Researcher coacht Team bei Planung und Ausführung
Kontinuierlich > Regelmäßige UX Research Aktivitäten (z.B. einmal pro Woche an einem bestimmten tag)
> Das gesamte Team nimmt teil (auch remote per screen sharing)
Processes for interactive systems [ISO 13407:1999].
… den Prozess der Entwicklung einer Anwendung so zu gestalten, dass zu jedem Zeitpunkt die Bedürfnisse des späteren Benutzers im Mittelpunkt stehen.
...beschreibt eine Vorgehensweise zur Entwicklung von Innovationen. Sie orientiert sich am Nutzer und dessen tatsächlichen Bedürfnissen. Die Methodik basiert auf der Überzeugung, dass Innovation nur dann entstehen kann, wenn sich multidisziplinäre Teams zusammenfinden, um innerhalb einer gemeinschaftlichen Kultur die Schnittstellen unterschiedlicher Erfahrungen, Meinungen und Perspektiven hinsichtlich einer spezifischen Problemstellung zu erforschen.
Für die Lösung komplexer Probleme setzt man auf ein möglichst vielschichtiges Team. Mit unterschiedlichen Hintergründen und Fachrichtungen. Das Gute: Je multidisziplinärer die Teams, desto innovativer sind meist die Lösungen. Die Teams durchlaufen einen Prozess in sechs Schritten, der mit dem Nutzer beginnt.
Verstehen Zunächst geht es darum, das Problemfeld zu verstehen und Expertenwissen zu erwerben. Zu diesem Zweck werden ein Glossar angelegt, ein gemeinsamer Arbeitsplatz eingerichtet, Direktiven für die Recherche geplant und diese eingeleitet. Zum Abschluss der Phase hat das Team eine geeignete Fragestellung entwickelt, welche die Bedürfnisse und Herausforderungen des Projekts definiert.
Beobachten Hierbei erfolgt eine ausführliche, vorurteilsfreie Auseinandersetzung mit der Interessensgruppe mittels Beobachtung, Befragung und Interaktion, um deren Bedürfnisse zu erfassen und zu verstehen. Sämtliche daraus resultierenden Einsichten werden aggregiert und dokumentiert.
Sichtweise definieren In dieser Phase werden die gewonnenen Einsichten zu einem Standpunkt verdichtet und ergeben ein gemeinsames Gesamtbild. Anhand von Skizzen werden Informationen gebündelt sowie Muster identifiziert und so das vorhandene Wissen vermittelbar gemacht – mit dem Ziel, aus einem gemeinsamen Wissensstand heraus agieren zu können.
Ideen finden Bei der Phase der Ideengenerierung kann prinzipiell jede Kreativitätstechnik Anwendung finden (z. B. Brainstorming). Wichtig dabei ist, eine möglichst hohe Quantität an Ideen zu erzeugen. Anschließend werden die gesammelten Ideen strukturiert, nach Ähnlichkeit sortiert und zusammengefasst. Aus diesem Pool werden die vielversprechendsten Ideen hinsichtlich ihrer Erwünschtheit, Machbarkeit und Wirtschaftlichkeit ausgewählt.
Prototypen entwickeln In dieser Phase werden die herausgefilterten Ideen iterativ erprobt. Zum Einsatz kommen dabei aufwandsarme Prototypen, z. B. Papiermodelle, aber auch Rollenspiele. Dabei geht es darum, die jeweiligen Ideen besser zu verstehen und zu veranschaulichen.
Testen Nehmen die Prototypen realiter Formen an, werden sie im offenen Dialog mit der Interessengruppe getestet. Das resultierende Feedback dient als Quelle für Optimierungen und mögliche Alternativen.
Fall in love with the problem not the solution. Uri Levine, co-founder of Waze
Lean UX ist eine Mischung aus Prinzipien und Methoden, die es erlauben, Ideen und Produkte schnell und zielgerichtet zu entwickeln. Dabei entsteht jedoch kein großer Masterplan zu Beginn der Entwicklung, sondern eine kontinuierliche Ausrichtung am Kunden während der laufenden Entwicklung. Gemeinsam mit der Fokussierung auf Teamarbeit und dem konsequenten Testen von Hypothesen bietet Lean UX die Möglichkeit, mitreißende Produkte und Ideen mit und damit auch für den Kunden zu verwirklichen.
Ron Kohavi; Online Experimentation at Microsoft (2009)
Jeff Gothelf mit Josh Seiden; Lean UX – Applying Lean Principles to Improve User Experience; O'Reilly 2012
Eric Ries; The Lean Startup; Portfolio Penguin 2011
Anthony Viviano; The Lean UX Manifesto: Principle-Driven Design; Smashing Magazine, 2014
Jeff Gothelf; Lean UX: Getting out of the Deliverables Business; Smashing Magazine, 2011
Anders Ramsay; Agile UX vs Lean UX – How they're different and why it matters for UX designers, 2012
[Fabian Hennecke](https://www.heise.de/developer/artikel/Lean-UX-Mit-Start-up-Methoden-zu-einem-besseren-Produkt-2544807.html „Lean UX: Mit Start-up-Methoden zu einem besseren Produkt“)
[mediaworx berlin AG](https://mediaworx.com/leistungen/digitale-strategie/Designthinking/ „Design Thinking“)