{"id":9774,"date":"2019-08-13T15:30:44","date_gmt":"2019-08-13T13:30:44","guid":{"rendered":"https:\/\/www.centigrade.de\/blog\/?p=9774"},"modified":"2021-03-11T14:19:51","modified_gmt":"2021-03-11T13:19:51","slug":"ux-design-return-on-invest-roi","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/ux-design-return-on-invest-roi\/","title":{"rendered":"UX Design – Return on Invest (ROI)"},"content":{"rendered":"

User Experience bedeutet, dass Nutzer ein Produkt erleben<\/em>. Die innovativsten Controls und die fl\u00fcssigsten Animationen n\u00fctzen gar nichts, wenn das Produkt nicht verkauft und genutzt wird. Als UX-Dienstleister haben wir vielfach erlebt, wie durch gute UX das Produkt nicht nur bei den Nutzern erfolgreich ankommt, sondern auch wie UX dazu beitr\u00e4gt, dass ein Produkt es \u00fcberhaupt auf den Markt schafft. Der Return on Invest (ROI) von UX-Design zeigt dabei den Gewinn oder Umsatz, der infolge einer Investition in UX Design erzielt wurde. Woher der zus\u00e4tzliche Gewinn \/ Umsatz kommt, welche weiteren Aspekte zum ROI beitragen und weitere Fragen zu Return on Invest von UX-Design beantworten wir in diesem Artikel.<\/p>\n

\"UX<\/p>\n

Warum braucht mein Projekt UX Design? #Mehrwerte entwickeln<\/h2>\n

Als Product Owner muss man vielen Anforderungen an sein Produkt gerecht werden. Zu oft f\u00fchrt das dazu, dass man ein bestehendes Feature als Anforderung beschreibt und als User Story in den Sprint einkippt. Dabei bleibt h\u00e4ufig die Frage auf der Strecke, ob man da eigentlich das Richtige entwickelt. Ein Beispiel: In einer Produktionshalle muss ein Schichtleiter mangelhafte Teile seiner Linie dokumentieren. Mit der l\u00f6sungsorientierten User Story „Der Nutzer m\u00f6chte ein M\u00e4ngelformular ausf\u00fcllen und abschicken“ baut das Entwicklungsteam ein Formular, das der Schichtleiter dann versenden kann.<\/p>\n

Die User Story gibt vor, was entwickelt werden soll. Aber wenn die User Story bereits eine uninspirierte L\u00f6sung definiert, statt auf die Probleme und Bed\u00fcrfnisse des Nutzers einzugehen, gibt es keinen Raum f\u00fcr UX-Verbesserungen. Das ist fatal, denn so schlucken die Stories Entwicklungszeit, transportieren aber trotzdem keinen Mehrwert f\u00fcr die Nutzer. POs erhalten trotz hohem Invest nicht die Vorteile einer Neuentwicklung, die sie sich eigentlich w\u00fcnschen. Hier wird gern der Spruch \u201eDas Richtige entwickeln, statt nur richtig entwickeln\u201c verwendet.<\/p>\n

W\u00fcrde man vor dem Entwicklungsstart einen Schritt zur\u00fccktreten und die Perspektive des Nutzers einnehmen, wird schnell klar, dass der Schichtleiter kein Formular ausf\u00fcllen will. Eigentlich WILL niemand jemals ein Formular ausf\u00fcllen. Er will den Mangel so schnell wie m\u00f6glich an eine Person weitergeben, die sich darum k\u00fcmmern sollte. Wenn man keine L\u00f6sung vorwegnimmt, sondern die User Story im Problemraum formuliert, lautet sie: „Wenn der Schichtleiter ein mangelhaftes Teil entdeckt, muss er den Mangel dokumentieren, damit Kollegen sich um das Problem k\u00fcmmern k\u00f6nnen.\u201c Hier wird keine L\u00f6sung vorgegeben, das Formular ist nicht erw\u00e4hnt. Das Team kann die Nutzerperspektive einnehmen und das Problem aus dessen Kontext heraus l\u00f6sen, statt auf bestehenden Features aufzusetzen, die wom\u00f6glich technologisch \u00fcberholt sind. Auf dieser Basis wurde im realen Projektbeispiel eine L\u00f6sung entwickelt, bei welcher der Schichtleiter an der Maschine sein Smartphone z\u00fcckt und ein Foto von dem mangelhaften Teil schie\u00dft, es mit einem Stichwort versieht und abschickt. Der Workflow ist dem Ausf\u00fcllen eines Formulars vorzuziehen, weil der Nutzer sich die Schreibarbeit spart, keinen Laptop mitschleppen muss und der Mangel anhand des Fotos viel besser beschrieben wird, sodass beim Empf\u00e4nger viel seltener Missverst\u00e4ndnisse auftreten. Dazu sp\u00e4ter mehr.<\/p>\n

Dieses Umdenken ganz zu Beginn des Entwicklungsprozesses fokussiert die Kapazit\u00e4t des Entwicklungsteams auf L\u00f6sungen, von denen der Nutzer wirklich profitiert. Es wird keine Zeit in das Nachbauen von alten L\u00f6sungen gesteckt, die zwar Entwicklungszeit fressen, aber keinen Mehrwert f\u00fcr das Produkt schaffen. Bestimmte Funktionen werden vielleicht gar nicht in der Form gebraucht, wie urspr\u00fcnglich gedacht. Auch das kann den Entwicklungsaufwand deutlich reduzieren. Wir sprechen von einer nutzerzentrierten Herangehensweise.<\/p>\n

Kann nicht jeder nutzerzentriert denken? Warum sollte ich Personen, die nicht programmieren k\u00f6nnen, in mein Softwareentwicklungsteam involvieren? #Vorhut<\/h2>\n

Die nutzerzentrierte Herangehensweise muss vom ganzen Team geteilt werden. Nur wenn alle mitziehen, kann im Endprodukt eine Verbesserung der User Experience erzielt werden. Auch Software Engineers brauchen diese Sichtweise. Diese vertreten Sie aber nur selten, da sie sich \u00fcberwiegend auf technischen Herausforderungen fokussieren. Der PO oder Projekt Manager vermittelt in erster Linie zwischen dem Entwicklungsteam und umliegenden Abteilungen und Anforderungen aus dem Unternehmen. Falls es also keine UX Designer im Team gibt, fehlt jemand, der die W\u00fcnsche des Nutzers vertritt und so aus einem nutzerzentrierten Requirement auch nutzerzentrierte L\u00f6sungen schafft. Erst die Kombination aller Blickwinkel f\u00fchrt zu einer L\u00f6sung von der POs, das Budget und der Markterfolg des Produktes profitieren.<\/p>\n

Au\u00dferdem f\u00fchrt es zu einer gro\u00dfen Entlastung des Engineering Teams, wenn ein UX Designer bereits alle Fragen aufkl\u00e4rt, Infos zusammentr\u00e4gt und spezifiziert, wie genau das neue Feature funktioniert und sich in den Rest der Software einf\u00fcgt. Dadurch wird nicht nur die initiale Umsetzung f\u00fcr das Team einfacher, sondern es wird auch die Wahrscheinlichkeit reduziert, dass sie auf halber Strecke noch mal umdenken und neu ansetzen m\u00fcssen.<\/p>\n

Wie ist das Kosten-Nutzen-Verh\u00e4ltnis von UX Design? #Entwicklungskosten sparen<\/h2>\n

Prototypen und Mockups, die man schon mit Nutzern besprechen oder mit Stakeholdern pr\u00fcfen kann, decken viele Fehler auf, die man sonst erst w\u00e4hrend der Implementierung oder sogar erst nach dem Release feststellt. Werden die Fehler erst festgestellt, wenn das Produkt ver\u00f6ffentlicht wurde, birgt das verschiedenste Risiken:<\/p>\n