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.

Mit Start-up-Methoden zu einem besseren Produkt

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.

Think, Make, Check

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

Ausgangspunkt

Praxis-Thema 1: Unterstützung des Arztes

> 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

Praxis-Thema 2: Unterstützung des Patienten

> 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.

Unterstützung des Arztes

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.

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

How might we...?

Hypothese: Wie können wir [person] bei [aufgabe] unterstützen, wenn [situation / paint point]?

Erste Ideen

Nach der Erarbeitung unseres Ideenpools wurden diese Bewertet und selektiert. Sie sollen nun die Grundlage unserer weiteren Arbeit sein.

Storyboard

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.

Infomap auf Basis eines Arztbriefes

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.

AID - Patientenhistorie

Prototyp - MVP

[MVP testen >>>](https://invis.io/KVFYXHP8GWH#/280658509_AID_01 „AID 1.0“)

Hypothesen - Unsere Grundlage

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

Persona in Lean UX

= 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

MVP

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.

Wizard of Oz

> 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)

Lean UX Check

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)

Human-Centered Design

Processes for interactive systems [ISO 13407:1999].

Human-Centered Design bedeutet…

… den Prozess der Entwicklung einer Anwendung so zu gestalten, dass zu jedem Zeitpunkt die Bedürfnisse des späteren Benutzers im Mittelpunkt stehen.

Design Thinking

...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.

Lean UX vs Agile UX

Better together

Fall in love with the problem not the solution. Uri Levine, co-founder of Waze

Fazit

Literatur & Quellen

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“)