Nutzerorientiertes Design: Schnell zu stimmigen Lösungen

Transkript

1 Nutzerorietiertes Desig: Schell zu stimmige Lösuge Nutzerorietiertes Desig: Schell zu stimmige Lösuge Viele Uterehme setze i der Softwareetwicklug auf agile Vorgehesweise wie Scrum oder Kaba. Diese Asätze lege eie starke Fokus auf die Effiziez der Produktetwicklug. Oft bleibe die Sicht der Beutzer ud somit die Effektivität der Lösug auf der Strecke. Ist es möglich, stimmige Kudelösuge zu baue ud dies schell zu tu? Falls ja, was gilt es dabei zu beachte? Diese Frage geht der Artikel ach. Die Biso Schweiz AG verfügt heute über ei umfagreiches Portfolio a ERP-Lösuge. Nach jahrelager Softwareetwicklug ach dem V-Modell erfolgte im Jahr 2012 die Umstellug auf die agile Vorgehesweise ach Scrum (vgl. [Scr]). Dies führte zu eier Äderug der Uterehmeskultur, die sich äußerst positiv bezüglich der Zusammearbeit ierhalb der Firma ud der Trasparez der Lösug bemerkbar machte. Dies resultierte jedoch icht automatisch dari, dass wir die Probleme der Beutzer effektiver löse kote. Durch usere techologische Kompetez gab es für jede Herausforderug immer auch eie techische Asatz. Ob diese Lösuge mehr als ur das aktuelle Problem behobe habe oder icht optimal zur Arbeitsweise des Beutzers passte, spielte lage Zeit eie utergeordete Rolle. Us wurde aber bewusst, dass wir us diese Arbeitsweise icht leiste köe. Um de Beutzer zu begeister ud die Etwicklug kostegüstig zu halte, müsse wir das aktuelle Problem optimal löse. Die Frage lautet icht, ob wir etwas Bestimmtes baue köe, soder ob wir es überhaupt baue solle. Diese Erketisse decke sich auch mit diverse Studie: Beutzer verwede lediglich 20 Prozet der Fuktioalität eier Software immer oder oft. Higege werde 45 Prozet der Features ie gebraucht (vgl. [Joh02]). Softwareetwickler verbrige 40 bis 50 Prozet ihrer Zeit mit Nachbesserugsarbeite (vgl. [Cha05]). Vo de meistgeate Grüde, warum IT-Projekte fehlschlage, stehe die folgede i direktem Zusammehag mit dem Eibeziehe der direkt Beteiligte (vgl. [Cha05]): 1) Schlecht defiierte Aforderuge. 2) Ugeügede Kommuikatio zwische Kude, Etwickler ud Beutzer. 3) Kei oder ur ugeügedes Eibeziehe der Iteressesvertreter. Im Frühjahr 2014 habe wir i zwei vo zeh Scrum-Teams (siehe Abbildug 1) damit begoe, ebe dem jahrelag eigesetzte Scrum-Etwicklugsframework auch die Methode ud Praktike des utzerorietierte Desigs (User Cetered Desig UCD) azuwede. UCD uterstützt us dabei, de Kude i seiem Nutzugskotext geau zu verstehe. Dies führt dazu, dass wir das wichtigste Problem der Beutzer löse. Das ist die Fuktioalität, die der Beutzer immer oder zumidest oft verwedet (vgl. [Joh02]). Was ist UCD? UCD stellt icht die Techologie is Zetrum, soder de Beutzer. Der Ausgagspukt der Etwicklug ist der Mesch, der eies Tages mit der Lösug arbeite wird. Das zu etwickelde System soll sich vo der Beutzugsschittstelle ableite ud icht umgekehrt. Im Fokus der Etwicklug stehe Nutze ud Beutzbarkeit. Es wird icht ur das techische System ageschaut. Vielmehr geht es um eie gazheitliche Asatz, i dem die Beutzer ud Stakeholder Teile davo sid. Zusätzlich zum Beutzer sid auch desse Aufgabe, sei Umfeld ud seie Ziele wichtige Grudlage für die Erarbeitug eier optimale Lösug. UCD ähelt dem Desig Thikig (DT), das ebefalls brauchbare Produkte astrebt (vgl. [Bro08]). Beim DT stehe die Iovatio ud Visiosetwicklug mehr im Fokus als beim UCD. Zudem werde beim DT die wirtschaftliche Aspekte stärker gewichtet, d.h. wie ei Produkt wirtschaftlich oder wirtschaftlicher sei ka. Bei UCD wird davo ausgegage, dass solche Überleguge bereits getätigt wurde, z.b. mit eiem Busiess Model Cavas oder ebe mit DT. Abb. 1: Scrum-Team bei der Arbeit. 03/

2 Nutzerorietiertes Desig: Schell zu stimmige Lösuge Abb. 2: Ablauf der UCD-Aktivitäte. 3. Kozeptio der Lösug Sketchig & Wireframig: Persoas ud Kotextszearie sid Hilfsmittel, um geeigete Lösuge zu fide. Diese Lösuge lasse sich hervorraged mittels Sketches ud Task-Flows abbilde. Um die Kreativität icht eizuschräke, sollte zu Begi mit Stift ud Papier gearbeitet werde. So köe sehr schell Idee für Abläufe ud Bildschirmasichte erstellt werde. Sobald eie Idee verfeiert wird, sid Papier ud Stift icht mehr geeiget. Zu diesem Zeitpukt eige sich Wireframe- Tools (z. B. Balsamiq Mockups, wireframe.cc ) besser, um schell Äderuge vorzuehme. Prototypig: Wird ei Stad erreicht, der die Aforderuge zufriedestelled erfüllt, ist es a der Zeit, die Idee i eiem Prototyp abzubilde. Ei solcher Prototyp soll icht fuktioiere, soder bloß Teile eier Lösug so gut wie möglich simuliere. Heute ist es möglich, mit weige Stude Aufwad aussagekräftige Prototype zu etwickel. Nur mit Programmierug ist dies meistes icht möglich, weshalb auf Tools wie axure, ivisio, JUS- TINMIND, UXPi, proto.io oder fluid zurückgegriffe wird. Der Prototyp hat zwei Fuktioe: Eierseits macht er die Lösug für alle ivolvierte Persoe klarer als mit jedem adere Artefakt. Adererseits eiget er sich auch, um Usability- Tests durchzuführe. Das Resultat vo UCD ist aber icht ur eie verbesserte Beutzugsschittstelle. Es geht um die gazheitliche Lösug eies Problems. Vereifacht ka gesagt werde, dass UCD wesetlich zu folgede Etscheiduge beiträgt: Wird eie Fuktio tatsächlich beötigt? Ist es sivoll, diese Fuktio über die Beutzugsschittstelle zu löse? Falls ja, wie soll diese Fuktio dem Beutzer präsetiert werde? UCD-Aktivitäte Der eigetliche Ablauf gliedert sich i die im Folgede beschriebee vier Hauptaktivitäte, die iterativ durchlaufe werde (siehe auch Abbildug 2). 1. Aalyse des Nutzugskotextes Eie hervorragede Methode, um de Nutzugskotext zu aalysiere, ist das Cotextual Iquiry (CI) (vgl. [Bey95]). Beim CI geht es darum, eie Beutzer i seiem gewohte Umfeld beim Ausübe der betreffede Tätigkeit zu beobachte. Es ist schell, äußerst ergiebig ud effektiv. Aber es ist icht immer eifach, ei gutes CI durchzuführe. Dies bedarf eier gute Plaug, de icht immer lässt sich eie Tätigkeit auch tatsächlich beobachte. Das CI verliert a Aussagekraft, we die Tätigkeit bloß simuliert oder och schlechter besproche wird. 2. Modellierug der Erketisse Vo de gewoe Erketisse wird u die Essez i Modelle destilliert. Dazu eige sich Persoas (vgl. [Coo04]) ud Kotextszearie. Eie Persoa stellt eie Prototyp für eie Gruppe vo Nutzer dar. Diese beihaltet kokret ausgeprägte Eigeschafte, Tätigkeite ud Schmerzpukte. Am wertvollste sid aber dere Ziele. Die richtige zu fide, ist gar icht so eifach. Ziele sid richtig, we die Persoa diese am Morge beim Aufstehe als Vorsatz verwede ka. So ist beispielsweise Schell teste kei Ziel, soder eie Aufgabe. Das Ziel wäre Fehlerfreie Arbeit abliefer. Gute Ziele sid klar ud spezifisch für die Tätigkeit. Im Kotextszearium ist festgehalte, was die Persoa beim Verwede der zuküftige Lösug erlebt. Diese Geschichte besteht aus eiige kurze Abschitte. Es wird beschriebe, was passiert, aber icht, wie es gelöst ist. Das heißt, es werde keie Beutzugselemete agesproche, stattdesse aber Motivatioe, Bedürfisse ud Aktioe. 4. Evaluatio der Lösug Mit dem Prototyp ist es möglich, bereits ach weige Tage ei erstes Feedback für eie zuküftige Lösug vo de Kude ud Beutzer zu erhalte. Der Prototyp ka eifach vorgeführt ud besproche werde. Mit de Beutzer ist es möglich, auch die Usability-Tests durchzuführe. Dazu wird dem Beutzer eie Aufgabe aus seiem Arbeitsumfeld gestellt, die er mit dem Prototyp erfülle soll. Währed der Ausübug dekt der Beutzer laut. Vor jeder Iteraktio beschreibt er, was er erwartet. So köe sehr schell Probleme i der aktuelle Lösug festgestellt werde. Diese werde i eier weitere Iteratio gelöst ud ereut geprüft. Zusammespiel vo UCD ud Scrum Bei Scrum-Teams mit circa siebe Mitglieder stellt sich die Frage, wie UCD orgaisiert werde soll. Eierseits köte wie teilweise praktiziert dedizierte UX-Teams (User Experiece) zusammegestellt werde. Diese Teams erarbeite alle UCD-Artefakte (siehe Abbildug 2) für sich ud übergebe das Projekt schließlich eiem Etwicklugsteam. Diese Orgaisatiosform hat aber gravierede Nachteile. Adererseits köe cross-fuktioale Teams gebildet werde. So wird UCD direkt i das Etwicklugsteam itegriert. Dies hat drei große Vorteile: Erstes ist ei Team vo Afag bis Ede für ei Produkt bzw. Projekt ver- 28

3 Abb. 3: Aufteilug ud Übergabe der UCD-Arbeit ud Etwicklugsarbeit ierhalb eies Scrum-Teams über mehrere Sprits. atwortlich. Ei Team wird so i die Pflicht geomme ud es gibt keie Übergabe, i der implizites Wisse verlore geht. Allgemei ist dadurch weiger Dokumetatio ötig. Zweites hat das Etwicklugsteam großes Verstädis für das Problem ud ka sich so fudiert i die Lösug eibrige. Durch die techische Kompetez ergebe sich Möglichkeite, welche die Lösug verbesser ud vereifache. Drittes empfidet der Etwickler gaz atürlich Empathie für de Beutzer. Dadurch etsteht eie gaz adere Geisteshaltug. Hauptsache es fuktioiert, reicht auch dem Etwickler icht mehr. Eie Spezialiste für UCD im Team zu habe, vereifacht eiem Team, das uerfahre mit UCD ist, die Arbeit es ist aber icht zwiged ötig. Viel wichtiger ist, dass UCD auch tatsächlich gelebt wird. Um dies i eiem Team ausübe zu köe, sid folgede drei Fähigkeite zwiged erforderlich: Eifühlugsvermöge, um sich i die Situatio der Beutzer ud Kude hiei versetze zu köe. Kommuikatiosfähigkeit, um sich mit Kude, Beutzer, adere Stakeholder ud de Teammitglieder austausche zu köe. Kreativität, um verschiedee Lösugsidee zu eiem Problem etwickel zu köe. eie vorgelagerte Sprit durchzuführe (siehe Abbildug 3). Es geht icht darum eie abschließede Spezifikatio zu liefer. Stattdesse wird im erste Sprit ur eie die wichtigste Tätigkeit des Beutzers agegage. Ideal wäre es, am Ede des erste Sprits eie evaluierte Prototyp für die eie Tätigkeit zu habe. Die gewoee Erketisse werde i Storys gefasst, die das Team im ächste Sprit umsetzt. Je achdem, wie viel UCD-Arbeit gerade asteht, ehme sich wieder ei bis drei Teammitglieder weitere Herausforderuge im ächste Sprit mit UCD vor. So ist sichergestellt, dass jederzeit geüged Storys zur Umsetzug bereit sid (siehe Abbildug 4). Rolle ud Tätigkeite Wie obe beschriebe, ist es sivoll, UCD-Aufgabe i de Etwicklugsteams auszuführe. Das bedeutet aber auch, dass Etwickler zu de Beutzer ud Kude gehe. Dies ka je ach Philosophie der Uterehmug für die Projektleiter, Product Ower, Aforderugsaalyste, Busiess-Architekte, UX-Desiger, Usability-Experte ud selbst für die Etwickler ugewoht oder gar uvorstellbar sei. Tatsächlich ist icht jeder Etwickler dazu veralagt, solche Arbeite zu überehme. Bis jetzt gab es bei us jedoch i jedem Team Etwickler, die dies gere ud gut realisiere kote. Uerfahree Teammitglieder werde bei alle UCD-Tätigkeite vo eier erfahree Perso oder eiem Spezialiste begleitet. Dies gilt auch bei eiem Kudebesuch oder eier Beutzerbeobachtug (Cotext- Iquiry). Mit UCD ka das Team bezüglich der Frage rud um die Kudeaforderuge autoom arbeite. Es ist icht mehr ötig, eiem Team eie Spezifikatio oder eie Aforderugskatalog zu gebe. Da alle Iformatioe ud das Kow-how vorhade sid, ka mit der Umsetzug begoe werde. Welche Tätigkeite bleibe deoch beim Product Ower (PO)? Nebe de admiistrative Aufgabe erarbeitet der PO mit dem Team zusamme eie Visio. Defiitioe vo Rahmebediguge wie Koste, Termie ud adere kommerzielle Aspekte werde vo dieser Rolle vorgeomme. Im Verlauf der Realisierug stellt der PO sicher, dass die etstehede Lösug der Visio etspricht. Zudem ist der PO ach wie vor für die Priorisierug zustädig. Damit er diese Aufgabe wahrehme ka, ist er bei de erste Kude- bzw. Beutzerbesuche atürlich dabei. So hat auch er das ötige Wisse, um sivolle Etscheiduge zu treffe. Widerstäde Nicht ur auf die Meiuge ud Präfereze im Etwicklugshaus zu setze, soder de Beutzer i seiem Kotext bei der Arbeit zu beobachte, fidet im erste Momet oft große Aklag. Auch das Spezifiziere aus der Sicht der Beutzer erschließt sich de meiste. Sobald es aber Wie soll UCD i eiem Scrum-Umfeld ausgeübt werde? Es wäre dekbar, dass UCD- Aktivitäte eifach Teil eier Story sid. Das hat aber eie große Nachteil. Vor de UCD-Schritte ist icht klar, wie die Lösug eier Story aussehe wird. Uter diese Voraussetzuge ist das Plae ud Schätze icht möglich. Bei us hat es sich deshalb bewährt, mit eiige Teammitglieder UCD-Tätigkeite als eigee Story i Abb. 4: Aufwad der UCD-Tätigkeite im erste Sprit. 03/

4 Nutzerorietiertes Desig: Schell zu stimmige Lösuge darum geht, tatsächlich eie Beutzer zu besuche, gibt es häufig Vorbehalte, wie etwa die folgede: Es wird driged eie Lösug beötigt. Der Kude soll keie falsche Eidruck erhalte. Es hadelt sich um eie Stadardlösug. Besuche verursache zu hohe Koste. Die Aforderuge sid bereits klar. Es existiert jahrelage Erfahrug im Uterehme. Es ist icht weiter erstaulich, dass solche Vorbehalte aufkomme. Statt zu programmiere, werde uproduktive Dige gemacht: Beutzerbesuche, Persoas, Zeichuge ud Beutzer-Tests. Was soll ei Kude deke, we ei kompetetes Etwicklugshaus de Beutzer grudlegede Frage stellt? Verstehe die ihre Arbeit etwa icht? Zudem befide sich dutzede Experte bereits im eigee Uterehme. Der Vorbehalt die Stadardlösug betreffed ist iteressat. Viele Skeptiker deke, UCD heißt, eie Lösug für eie spezifische Perso oder ei spezifisches Team zu erarbeite. Dabei ist UCD besoders geeiget, um ei Stadardprodukt zu etwickel. Beim Eisatz vo Persoas wird vo viele kokrete Beutzer abstrahiert, um ei fokussiertes Produkt zu erhalte, das für das Zielpublikum optimal fuktioiert (vgl. [Goo09]). De: Ei Produkt für alle fuktioiert für iemade. Es ka durchaus sehr schwierig oder je ach Kostellatio gar umöglich sei, ivolvierte Persoe mit Argumete vo UCD zu überzeuge. Wurde ei Projekt aber mit UCD umgesetzt, sid die Widerstäde i der Regel gebroche. Die UCD- Tätigkeite förder mit kleiem Eisatz uglaubliche Erketisse zu Tage. Die Resultate spreche für sich: Die Kude ud Beutzer fühle sich verstade ud erst geomme. Nu stellt sich die Frage, wie UCD bei eiem skeptische Umfeld eigesetzt werde soll. Es empfiehlt sich icht, UCD vo Afag a im volle Umfag zu praktiziere, soder zu Begi ur eizele Teile daraus. Der ergiebigste Teil vo UCD ist das CI (vgl. [Bey95]), also das Beobachte vo Beutzer. Wahrscheilich ist es aber gerade dieser Teil vo UCD, der die größte Ägste auslöst. I diesem Fall ist es empfehleswert, zumidest korrekte Usability-Tests durchzuführe. Diese sid auch außerhalb vo UCD aerkat ud Abb. 5: Eie Beutzeri verwedet die eue Lösug. habe eie heilsame Wirkug. Ei korrekt durchgeführter Usability-Test wird aufzeige, dass viele Aahme, Hypothese ud Etscheiduge icht korrekt ware. Vielleicht sollte das ächste Mal doch auf UCD gesetzt werde Falls es auch i Zukuft icht möglich ist, ei CI durchzuführe, köe auch viele der UCD-Artefakte aufgrud vo Aahme ud Hypothese erstellt werde. Das ist immer och besser, als we die Techologie die Lösug vorgibt. Dabei werde aber immer och häufig die falsche Probleme agegage ud uötige Fuktioalität umgesetzt, statt das eigetliche Problem eifach zu löse. Irgedwa stellt sich die Frage: Ka es sich ei Uterehme leiste, auf UCD zu verzichte? Herausforderuge Nach eiem Jahr mit UCD durfte wir viele wertvolle Erfahruge mache: Was icht fuktioiert Besodere Herausforderuge Wo wir us verbesser köe Ei CI (vgl. [Bey95]) mit eiem Beutzer durchzuführe, bei dem der Vorgesetzte zuschaut, ist keie gute Idee. Der Beutzer arbeitet i diesem Kotext, wie es der Chef gere sehe möchte, statt so, wie tatsächlich gearbeitet wird. Außerdem kommt ei zusätzlicher Stressfaktor hizu, was keie etspate Atomsphäre zulässt. We möglich, sollte dem Vorgesetzte erklärt werde, dass es um eie möglichst authetische Beobachtug geht. We der Vorgesetzte auch sost dem Mitarbeiter icht die gaze Zeit über die Schulter blickt, so sollte er es beim CI auch icht tu. Auch der sostige Ablauf oder uatürliche Situatioe beispielsweise CI im Sitzugszimmer astatt am richtige Arbeitsplatz sollte vermiede werde. Der Tagesablauf sollte so sei wie immer. Ei CI uter realistische Bediguge durchzuführe, ist sehr aspruchsvoll. Nur eie Beutzer pro Rolle zu beobachte, ist immer och besser als gar keie. Um eie ausgeglichee Persoa (vgl. [Coo04]) zu erstelle, sollte pro Rolle midestes füf Beutzer beobachtet werde. Auch we bereits ach eiem CI viele Dige i Erfahrug gebracht wurde, ist trotzdem icht klar, ob alle Beutzer geau gleich arbeite ud deke. Evetuell war die beobachtete Perso besoders IT-affi oder hat besoderes Wisse. Beutzer ud Vorgesetzte habe häufig Lösugsvorschläge, wie ei Problem behobe werde soll. Es ist ei großer Fehler, diese Lösugsvorschläge 1:1 umzusetze, ohe das grudlegede Problem dahiter zu verstehe. We ma diese Lösugsvorschläge direkt umsetzt, übergibt ma das Produktdesig i die Häde der Beutzer oder desse Vorgesetzte. Stattdesse sid wir gefordert, die Beweggrüde ihrer Aforderuge zu verstehe ud dafür stimmige Lösuge zu fide. Als exterer Softwareetwickler habe wir die Möglichkeit, bestehede Abläufe, Strukture ud Prozesse ohe die Ge- 30

5 schichte dahiter zu sehe ud auch zu hiterfrage. Allzu schell ka dies i de Hitergrud rücke ud der Fokus liegt bloß och auf der Optimierug eies bestehede Prozessschritts. Ud selbst we ei Prozess, eie Tätigkeit oder eie Rolle vo us als silos oder ieffiziet erkat wird, ist es häufig icht leicht, dies mit dem Kude zu bespreche. Viel leichter ist es, eifach das zu mache, was der Kude will, auch we es für ih ud seie Uterehmug icht die beste Lösug ist. Bevor ma sich auf eie Lösug eischießt, sollte ma de Fokus vergrößer ud das Problem verstehe. Dies erlaubt es, mehrere Variate zu erarbeite, bevor a eier Lösug geschliffe wird. Eifache, geiale ud praktische Lösuge erschließe sich eiem icht immer gleich, soder müsse etdeckt werde. Es gibt durchaus Situatioe, i dee alle Aspekte des Projekts mit UCD erarbeitet werde, bevor mit dem Umsetzug begoe wird. Dies ist häufig dort der Fall, wo UCD icht im Etwicklugsteam stattfidet. Dieses Vorgehe ist risikoreich. Es staut viele Etscheiduge auf, bevor sie sich im produktive Eisatz bewähre köe. Bedeuted besser ist es, bereits ach zwei Woche eie Teil der Lösug im produktive Eisatz zu habe. Das bedeutet aber auch, dass ierhalb dieses Zeitraums erstes UCD ud erste Umsetzuge stattfide müsse. I eiem solch kurze Zeitraum ist es icht möglich, alles bis is letzte Detail festzuagel. Dies bedarf eiige Muts, etspricht aber vollkomme eiem agile Vorgehe ud hat bei us im letzte Jahr für eiige positive Überraschuge gesorgt. Es tate sich plötzlich Lösuge auf, die wir sost ie gesehe hätte. Wir habe aus eigeer Erfahrug festgestellt, wie schwierig es ist, eiem Beutzer bei der Evaluatio icht zu helfe. Es ist teilweise schmerzhaft, eie Beutzer bei der Aufgabe verzweifel zu sehe. Der Beutzer muss Prototype aber selbst etdecke köe. Nur so köe Probleme festgestellt werde. Beutzer sehr egagiert ud idetifiziere sich mit dem Produkt. Zum adere fällt praktisch keie Zeit für Nachbesserugsarbeite a. Die Lösuge passe bereits bei der Eiführug (siehe Abbildug 5). Abschließed gilt es folgedes zu beachte. Versuche Literatur & Liks [Bey95] H. Beyer,K. Holtzblatt, Appreticig with the Customer, Commuicatios of the ACM, 1995 [Bro08] T. Brow, Desig Thikig, i: Harvard Busiess Review, Jui 2008, siehe: [Cha05] R.N. Charette, Why Software Fails, 2005, siehe: [Coo04] A. Cooper, Imates Are Ruig the Asylum The: Why High-Tech Products Drive Us Crazy ad How to Restore the Saity, Sams Publishig, 2004 [Goo09] K. Goodwi, Desigig for the Digital Age: How to Create Huma-Cetered Products ad Services, Joh Wiley & Sos, 2009 [Joh02] Jim Johso of the Stadish Group, Keyote speech at 3rd Iteratioal Coferece o Extreme Programmi, 2002, siehe: [Scr] Scrum Alliace, siehe: eifach zu starte: Scho die Awedug der eigägigste UCD-Tätigkeite ka sehr wertvolle Resultate liefer. auch bei großem Widerstad ei Pilotprojekt mit UCD durchzuführe: Die daraus gewoe Erketisse werde zu eiem Umdeke führe. alle Teammitglieder mit der UCD- Vorgehesweise vertraut zu mache: Die Autore Das führt zu eiem bessere Verstädis ud daraus zu eier optimalere Lösug. Vermeide zu glaube, dass mit eiem UCD- Experte im Team alle Probleme gelöst sei werde: Das Team, das Uterehme ud auch der Kude müsse dieses Vorgehe mittrage. dara festzuhalte, UCD erst azuwede, we der komplette Ablauf durchgezoge werde ka. zu lage ud zu viel Zeit i die Kozeptphase zu ivestiere. Schelle Feedback-Zykle sid kritische Erfolgsfaktore. Fazit Um auf die eigags gestellte Frage eizugehe: Ja, es ist möglich eigebettet i eie effiziete Etwicklugsprozess effektive Lösuge zu etwickel. Wir köe bezüglich der Effektivität der Lösug eie klare Tred verzeiche: Die Kude ud auch die Beutzer sid vo de Lösuge begeistert. Dies macht sich auf zwei Arte bemerkbar. Zum eie sid die Philip Schöholzer (philip.schoeholzer@biso-group.com) ist Product Ower ud UX-Coach bei der Biso Schweiz AG. Er setzt sich für die User-Experiece der Produkte ud die Sesibilisierug der Etwicklugsteams bei Biso ei. Seie Leideschaft sid stimmige Lösuge für komplexe Probleme. Peter Zurkirche (peter.zurkirche@biso-group.com) egagiert sich als Scrum Master ud Agile Coach bei der Biso Schweiz AG. Er treibt agile Werte ud Methode vora, fördert diese vo der Stufe Team bis hi zu uterehmesweite Aspekte ud beschäftigt sich mit Agilität ud Selbstorgaisatio. 03/