Kategorie-Archiv: Anwenderorientierte Gestaltung

Softwareentwicklung braucht mehr Gestaltungskompetenz

Die Softwareentwicklung in Deutschland braucht mehr Gestaltungskompetenz. Das ist das Fazit der BITKOM-Taskforce „Software-Gestalter“ in der Dr. Kim Lauenroth (adesso AG/IREB e.V.), Prof. Dr. Karsten Lehn (Hochschule Hamm-Lippstadt), Dr. Marcus Trapp (Fraunhofer Institut für Experimentelles Software Engineering – IESE), weitere Autoren und ich uns in den letzten Monaten mit der Frage beschäftigt haben, wie es der Softwareentwicklung in Deutschland gelingen, kann die Herausforderungen der digitalen Transformation zu meistern.

Unsere Beobachtungen, Erkenntnisse und Lösungsvorschläge haben wir in einen Leitfaden für Software-Unternehmen gepackt. Im Grunde wollen wir mit diesem Leitfaden dazu anregen, mehr gestalterisches Wissen und Fähigkeiten in der Informatik-Ausbildung zu vermitteln. Entwickler benötigen neben ihrer technischen Expertise auch gestalterisches Grundwissen, um gemeinsam mit Requirements Engineers und UX Designern digitale Lösungen erschaffen zu können, die Menschen begeistern. Unser Plädoyer ist aber keine Einbahnstraße. Die anderen Disziplinen der Softwareentwicklung, wie z.B. Requirements Engineering und UX Design, müssen sich im Gegenzug mehr hinsichtlich Informatik ausbilden. Die fachlichen Grenzen zwischen den Disziplinen müssen mehr als heute verschwimmen. Das gemeinsame Ringen um die beste digitale Lösung für den Anwender oder Kunden muss in den Vordergrund rücken. Die häufig noch sehr technologieorientierte Denkweise in der Softwareentwicklung muss sich zu einer menschenzentrierten Denkweise verändern.

Um diesen Brückenschlag zu verdeutlichen haben wir ein Idealbild eines Softwaregestalters bzw. Digital Designers entworfen. Dieses Idealbild beschreibt ein Kompetenzprofil aus der Schnittmenge der Disziplinen der Softwareentwicklung. Es soll zum einen Entwicklern, Requirements Engineers und UX Designern Orientierung bei der eigenen Ausbildung geben. Zum anderen soll dieses Kompetenzprofil Managern in Softwareunternehmen als Unterstützung für die Zusammenstellung von Entwicklungsteams und für die Weiterentwicklung der Entwicklungsorganisation dienen.

Der Leitfaden steht als kostenloses Download auf der Bitkom-Webseite zur Verfügung.<<< ><< p>< /p>

Wireframe, Mockup, Klickdummy, (Papier-)Prototyp – Was ist was?

Die Begriffe für Prototypen können manchmal ganz schön verwirrend sein, vorallem wenn sie rein intuitiv verwendet werden. Ich habe für Euch mal die Begriffsdefinitionen für die unterschiedlichen Arten von Prototypen zusammengestellt, die ich in meiner Arbeit verwende:

Wireframe

Ein Wireframe ist ein sehr früher konzeptioneller Entwurf einer Bedienoberfläche. Die visuelle Gestaltung und technische Funktion spielen bei Wireframes keine Rolle. Die verwendeten Gestaltungselemente sind sehr stark reduziert. Das Augenmerk eines Wireframe liegt auf der Anordnung von Elementen und der Benutzerführung. (https://de.wikipedia.org/wiki/Wireframe)

Mockup

Mock-up oder Mockup bezeichnet eine Art Attrappe. Der Begriff wird meist für ein maßstabsgerechtes Modell bzw. eine Nachbildung eines Produktes bzw. Services zu Präsentationszwecken benutzt. Bei Mockups steht das visuell-interaktive Design im Vordergrund. Die Zuschauer sollen sich einen möglichst guten Gesamteindruck vom finalen Produkt bekommen ohne sich dabei zu sehr in Details zu verlieren. (https://de.wikipedia.org/wiki/Mock-up)

Klickdummy

Ein Click-Dummy oder Klickdummy ist eine teilweise interaktionsfähige Demo einer Bedienoberfläche, welche bestimmte Interaktionen mit dem zukünftigen Produkt simuliert. Klickdumys weisen bereits relevante Merkmale des fertigen Produktes auf und ähneln hinsichtlich der Gestaltung dem finalen Produkt. Anwender können so einzelne Abläufe und einzelne Interaktionen im Detail erleben. Klickdummys sind in der Regel funktional unvollständig. Sie werden häufig als Grundlage für User Research-Maßnahmen verwendet. (http://t3n.de/magazin/wireframes-prototypes-optimalen-interface-prototyping-ux-233367/2/)

Papier-Prototyp

Ein Papier-Prototyp visualisiert mit Hilfe von gezeichneten oder gedruckten GUI-Komponenten die konzeptionelle Gestaltung einer Bedienoberfläche. Ähnlich wie bei Wireframes spielen visuelle Gestaltung und technische Funktion keine Rolle. (https://de.wikipedia.org/wiki/Paper_Prototyping)

Prototyp

Ein Prototyp stellt ein funktionsfähiges und in der Regel vereinfachtes Versuchsmodell eines geplanten Produktes, Services oder Bauteils dar. Er ist funktional und gestalterisch dem finalen Produkt sehr ähnlich. Prototypen können eine Grundlage für das Anforderungsmanagement (Evaluation von Anforderungen), Machbarkeitsprüfungen und User Research sein. „Prototyp“ wird manchmal auch als Oberbegriff für unterschiedliche Prototypenarten verwendet. (https://de.wikipedia.org/wiki/Prototyp_(Technik))

Complementing Journey Maps with Situational Frames to Create Actionable Design Spaces #muc17

Joerg Beringer (Splunk), Thomas Herrmann und Jan Nierhoff (Bochum University) stellten eine Methode vor, wie die Erkenntnisse, die in Customer Journey Maps erarbeitet und visualisiert wurden, in konkrete Anforderungen überführt werden können. Die Herausforderung dabei ist, dass bei der Überführung das große Bild nicht verloren geht.

Sie nennen das Verfahren „Situational Frame“. Ähnlich wie „Jobs to be done“ basiert das Verfahren darauf, das man sich auf Basis der Customer Journey Kernaufgaben und Situationen als Rahmen setzt und im Rahmen eines Workshops tiefer hinsichtlich Akteuren, Aktivitäten und Arbeitsobjekte analysiert. Der Workshop findet direkt im Anschluss an die Erstellung der Customer Journey statt. Für die Analyse modellieren sie das Zusammenspiel von Akteuren, Aktivitäten und Arbeitsobjekte. Sie verwenden dafür die Modellierungssprache SeeMe.

Der Clou ist, dass sich mit Hilfe der Modelle aus den unterschiedlichen Sichten von Akteuren, Aktivitäten und Arbeitsobjekten konkrete Anforderungen ableiten lassen. Dies erfolgt so, dass man sich beispielsweise alle Aktivitäten und Arbeitsobjekte der beteiligten Akteure anzeigen lässt und so erkennen kann, was ein Nutzer in der erstellten Customer Journey alles konkret tun muss. Auf dieser Basis können dann relativ einfach die konkreten Anforderungen und User Storys für die Entwicklung formuliert werden.

Full Stack Customer Journey Mapping für das digitale Schadenmanagement #muc17

Olde Lorenzen-Schmidt (mind-centric experience) und Gundula Beier (Allianz Handwerker Services) berichteten über ein Praxisprojekt zur Entwicklung einer Customer Journey und deren Nutzung bei der Allianz Handwerker Services GmbH (AHS). Die AHS kümmert sich um die Behebung von Gebäudeschäden im Rahmen der Schadensregulierung der Allianz Versicherung. Der Service der AHS hat einen großen Einfluss auf die Kundenzufriedenheit im Schadensfall. Es ist eine Art „Rund um Sorglos“-Dienst, der die vielen Dienstleister und Maßnahmen zur Behebung eines Schadensfalls koordiniert. Daher ist es auch das zentrale Unternehmensziel des AHS die Kundenzufriedenheit zu steigern.

Die Customer Journey ist in erster Linie ein strategisches Kommunikationsmittel, dass zum besseren Verständnis des Kundenerlebnisses dient.

In dem vorgestellten Prozess wurde eine Customer Journey Map visualisiert, um Ansatzpunkte zur Steigerung der Kundenzufriedenheit zu finden. Die AHS nutzt den NPS, um Kundenzufriedenheit zu messen und damit das Unternehmen zu steuern.

Begonnen wurde das Projekt mit der Ermittlung der Innen-Perspektive auf das Kundenerlebnis mit Hilfe von Workshops mit Teilnehmern aus allen betroffenen Unternehmensbereichen der Allianz. Danach wurden Telefoninterviews und eine Handwerker-Befragung zur Ermittlung von ersten Annahmen zum Kundenerlebnis durchgeführt. Diese Annahmen wurden dann mit Hilfe von Tiefeninterviews ergründet. Interessanter Nebenaspekt: die Tiefeninterviews wurden im Stehen durchgeführt, damit sich die Kunden auf einem Zeitstrahl, der auf dem Boden aufgemalt war, durch ihren letzten Schadensfall bewegen und dadurch besser erinnern konnten. Die aufgezeichneten Erkenntnisse und einzelnen Customer Journeys aus den Interviews wurden dann mit Excel ausgewertet. Die Ergebnisse wurden auf einem 3,2 x 1,4 m großen Plakat grafisch aufbereitet. Zum Abschluss wurden in internen Workshops auf Basis der Customer Journey Map die Maßnahmen(-pakete) entwickelt, die die Kundenzufriedenheit und damit den NPS steigern.

Service Safaris – Auf der Jagd nach der Kundenperspektive #muc17

In ihrem Workshop haben sich Philip Marzoch und Jan Köppen (UID) sowohl theoretisch als auch praktisch mit dem Thema Service Safaris beschäftigt. „Service Safari“ ist eine User Research-Methode aus dem Service Design zur Analyse von Kundenerlebnissen. Service Design choreografiert Ressourcen und Touchpoints, um dadurch Mehrwerte zu schaffen.

Service is everything you can’t drop on your feet.

Bei klassischen User Research-Methoden, wie z.B. dem Contextual Inquiry, geht es darum Anwender zu beobachten und aus dem Verhalten der Anwender Schlüsse zu ziehen. Bei Service Safaris oder Service Design Safaris erfahren User Researcher, Designer und Andere einen Service am eigenen Leib und untersuchen so den Service aus Kundenperspektive. Die Erkenntnisse werden in einer Art Tagebüchern festgehalten und in sogenannten Service Blueprints visualisiert.

UX Thinking – UX ist mehr als bunte Bildchen und fancy Animationen #muc17

Die MuC 2017 begann für mich mit einem Tutorial von Herbert A. Meyer und Hias Wrba von artop zu UX Thinking. Hinter dem von artop geschaffenen Begriff „UX Thinking“ verbirgt sich ein ganzheitliche Sichtweise auf UX. Nach der Erfahrung der Beiden wird UX häufig auf Interaktionsgestaltung und visuelle Gestaltung reduziert. Weiterführende Aspekte wie User Research, Anforderungsanalyse und Kontextanalyse kommen bei der praktischen Umsetzung von UX zu kurz.

Der Denkansatz „UX Thinking“ basiert auf 3 Grundgedanken:

  • Shared Understanding: Die Entwicklung eines gemeinsamen Verständnisses im Team. „Das Ekelige an Shared Understanding ist, dass man ab der ersten Minute im Team glaubt, man hätte es.“
  • Bricolage: Natürlich müssen UX Methoden verstanden und angewendet werden können. Teams müssen aber darüber hinaus in der Lage sein UX Methoden für ihre Bedarfe zu adaptieren. „Es geht so ein bisschen darum den Respekt vor der Unantastbarkeit der UX Methoden zu verlieren.“
  • Critical Thinking: Das kritische Hinterfragen von Annahmen, scheinbaren Gegebenheiten und Problemen.

Strategize for impact, Design for outcome, Build for output.

Methodischer Hintergrund von UX Thinking sind Theorien zu Aktivität und Motivation von Diefenbach und Hassenzahl. Durch diese werden die Frage nach dem Warum und das Wohlbefinden bei der Gestaltung von Produkten und Services in den Mittelpunkt gestellt.

Mein Fazit: UX Thinking ist eine Zusammenfassung der aktuell anerkannten Vorgehensweisen und Best Practices zur Gestaltung und Entwicklung von Produkten / Services. (Lean, Agile, Design Thinking, Service Design, Human Centered Design, …)

Neben dem Gedanken des UX Thinking nehme ich aus diesem Tutorial den Verweis auf eine Studie der Carnegie Mellon mit, die sich damit beschäftigt hat, wie man Teams zusammensetzen muss, damit eine kollektive Intelligenz und eine hohe Teamperformance entsteht. Die praktische Übung dieses Tutorials hatte nämlich nicht nur den Zweck die Erstellung von Visionen in Gruppen zu üben, sondern auch die Teamperformance mit dem Redeanteil der einzelnen Teammitglieder ins Verhältnis zu setzen – ein Sozialexperiment quasi. Damit sollte mit Referenz auf die Studie der Carnegie Mellon University bewiesen werden, dass die Teams mit dem ausgeglichensten Redeanteil die besten Ergebnisse erzielen. Ganz geklappt hat es nicht: Das Team mit dem ausgeglichensten Redeanteil landet nur auf Platz 3.

Adapting UX Methods for Unfamiliar Contexts #uxstrat

Zach Hyman (Continuum) sprach über die Berücksichtigung des sozialen und kulturellen Kontextes bei der Gestaltung von digitalen Services. Er berichtete aus einem Projekt in dem sie als Agentur beauftragt wurden, für die jordanische Bank NMB einen Weg zu finden, wie Menschen in ländlichen Gegenden Krediten abzahlen können.

Zum Hintergrund des Projektes muss man wissen, dass Jordanier Bargeld lieben. Nur 1,5% der Jordanier haben eine Kreditkarte. Außerdem nutzen viele Featurephones und nur wenige Smartphones. Das konkrete Problem, was zu lösen galt, war die Rückzahlung von Krediten. Menschen, die in ländlichen Gegenden in Jordanien leben, müssen weite Weg zu Banken zurücklegen, um ihre Kredite bar abzuzahlen. Oft beauftragen sie Verwandten oder Freunden das Geld einzuzahlen. Außerdem scheinen sich viele Jordanier schwer zu tun Geld zu sparen, um die Kredite abzuzahlen. 

„We should design the behavior, rather than the product.“

Durch intensive Beobachtung des Nutzungsverhaltens von Kreditnehmern und des Nutzungskontextes entwickelten sie ein entsprechendes Konzept. Sie beobachteten, dass Menschen zum einen ein sehr vertrauensvolles Verhältnis zu ihren lokalen Händlern haben. Außerdem beobachteten sie, dass viele Menschen ein „Hassalah“ – eine Art jordanisches Sparschwein – zum Ansparen verwenden. Mttels Prototypen entwickelten sie einen Service, bei dem lokale Händler die Aufgaben von Bankschaltern übernahmen und mittels einer mobilen App die Kreditrückzahlungen abwickeln. Bei Bedarf kann bei jedem Einkauf entweder der komplette Kreditbetrag oder auch nur ein kleiner Teil eingezahlt werden – wie beim Sparschwein.

Neben den Projektergebnissen hob er hervor, wie wichtig es für Agenturen ist, Empathie für ihre Kunden und deren Kontext zu entwickeln. Auch wenn Agenturen wegen ihrer Expertise eingekauft werden, so müssen sie zuerst verstehen, wie und in welcher Umgebung ihre Kunden arbeiten. Wenn der Kunde darüberhinaus in einem anderen kulturellen Umfeld lebt als die Agentur, ist es wichtig ein lokales Team zu haben, was direkt vor Ort im gleichen kulturellen Kontext arbeitet und sich mit den lokalen Gepflogenheiten auskennt.

You are only as goog as your local team.

Siehe auch

Prototyping invisionapp.com