Wie Sie methodisch zu richtig guter Software kommen
Früher: Digitale Werkzeugkoffer für Spezialisten
Frühere Unternehmenssoftware war abstrakt. Zu Zeiten von DOS waren Interfaces ausschließlich textlastig und die Bedienung erfolgte per Tastenkürzel, die auswendig gelernt werden mussten. Intuitiv war das nicht, ein Nutzer musste also immer ausgiebig geschult werden.
Für das einfache Verständnis von Software war der erste grafische Desktop von Apple als Analogie zum echten Schreibtisch ein großer Schritt nach vorne. Objekte konnten nunmehr mit der Innovation der Maus angeklickt werden. Zahlreiche Metaphern wie der Ordner, Papierkorb und Fenster ließen auf Anhieb die Funktionalitäten verstehen.
Es ist erstaunlich: Der heutige Desktop ist ohne große weitere Entwicklungen seit Jahrzehnten nahezu unverändert. Fenster, Scrollbars, Icons. Na ja. Farbe ist hinzugekommen.
Schlimmer noch: Unternehmenssoftware hat nicht einmal zu solchen Metaphern wie dem Desktop aufgeschlossen. Sie bestehen flächendeckend aus abstrakten Visualisierungen wie Formularen, Tabellen und versteckten Rechtsklicks. Viel intuitiver als das damalige DOS ist das nicht….
Zugegeben: Es gibt Nutzer, die mit oben abgebildeter Software effizient gut arbeiten können. Auch wirkte es damals nahezu artistisch, wie Nutzer zu DOS-Zeiten über die F-Tasten tanzten. Eine Voraussetzung für diese Höchstleistung waren allerdings: Ausgiebige Schulungsprogramme, ordentlich Frust während der Einarbeitung und natürlich langjährig erfahrene Mitarbeiter.
Zusammengefasst: Viele heutige Softwareprodukte im Unternehmenseinsatz sind Werkzeugkoffer, die ganz, ganz, ganz viel an wichtiger Funktionalität bieten. Der Benutzer muss sich allerdings dieses Funktionsspektrum erst erschließen, sich einen Weg zu seinem Ziel suchen und ihn sich mühsam merken. Das geht nicht ohne Schulungen und ggf. Frust.
Heute: Software und Apps überall für jedermann
Nun verschärft sich die Lage. Wurden die oben beschriebenen Boliden noch auf stationären Desktops ausgerollt und langwierige Release-Zyklen zogen sich über viele Jahre, so fluten im aktuellen Zeitalter der Digitalisierung neue Produkte und Apps nahezu jede berufliche Nische. Maschinen verfügen über Touch-Displays oder können sogar per iPad und App gesteuert werden. Ärzte verfassen Ihre Berichte nicht im Nebenzimmer am Monitor, sondern direkt am Tablet.
Das bedeutet: Nicht mehr nur sorgfältig geschulte Experten nutzen Software, sondern jedermann. Und überall. Mit stetig wachsendem Funktionsspektrum und kürzeren Release-Zyklen. Hat man sich gerade an eine Software-Version gewöhnt oder ein Schulungsprogramm absolviert, rauscht bereits das nächste Update rein.
Boliden sind ein Desaster für die Nutzer und die Wertschöpfung
Für die Effizienz der Prozesse und die Analyse der Daten ist die agile Digitalisierung hervorragend. Für den Menschen, der sich mit all dem konfrontiert sieht, während er vor einem Boliden an Software sitzt, der kaum noch zu beherrschen ist, ist all das allerdings ein wenig diskutiertes Desaster.
Software, die sich dauernd neu erfindet, die abstrakt Informationen abbildet, viele Funktionen liefert, die ein Benutzer gerade nicht braucht, hilft nicht, sie stört und stößt nicht auf Akzeptanz. Im schlimmsten Fall bekommen sie herzlos gepflegte und falsche Datenbestände oder Mitarbeiter meiden sogar die Nutzung. In einem tatsächlich erlebten Fall gingen Verkaufszahlen eines Agenturvertriebs rasant in den Keller, weil die freien Berater lieber einfacher zu konfigurierende Produkte eines Mitbewerbers verkauft haben.
In einem anderen positiven Fall wurde das erste Mal komplexe und teure Hardware im Messtechnikumfeld ausschließlich auf Grund von einfacher Bedienung – also wegen einer guten Konfigurationssoftware – verkauft.
Es scheint also Hoffnung zu geben! Betrachtern wir im Folgenden was eine solche „gute“ Software ausmacht und wie der konkrete Weg dorthin ausschaut.
Die Lösung: Vereinfachte Interfaces durch „Use Case Driven“
Die gute Nachricht für Freunde des großen Funktionsspektrums: Es braucht nicht weniger Funktionalität in neuen Software-Produkten – Im Gegenteil, wegen der neuen Einsatzszenarien und der aufblühenden Technologievielfalt sind mehr Funktionen denn je erforderlich.
Was es allerdings braucht, ist eine Segmentierung dieses wachsenden Funktionsspektrums, so dass jede Benutzergruppe nur noch den Ausschnitt an Informationen und Interaktionsmöglichkeiten bekommt, den sie in der aktuellen Situation gerade braucht. Und zwar so aufbereitet, dass jeder Screen intuitiv verständlich und effizient zu bedienen ist.
Im Fachjargon nennt sich das Ganze „Use Case Driven“.
Die Magie ist, nicht jedem Anwender in jeder Nutzungssituation das gleiche komplexe User Interface zu präsentieren. Es können beispielweise über ein Dashboard verschiedene Unterbereiche angesteuert werden. Diese Einsprungspunkte können Sie auch “Apps” nennen, das fördert die Management-Akzeptanz 😉
Jeder dieser Bereiche berücksichtigt die Nutzergruppen und damit zum Beispiel den passenden Komplexitätsgrad, aber auch die Interaktionsmöglichkeiten.
So kann ein Bereich Touch- oder Smartphone optimiert sein, ein anderer fokussiert große oder mehrere Bildschirme. Ein Bereich mag für Gelegenheitsbenutzer optimiert sein, so dass alle Informationen und Klick-Pfade leicht verständlich sind und nicht erlernt werden müssen. Ein anderer Bereich für Experten und umfasst alle Funktionen, die die Lösung zu bieten hat.
Der konkrete Weg zu Use Cases
Sobald es konkret wird, wird es schwierig. Und zwar nicht auf Grund schwer zu findender neuer Lösungswege. Ehrlicherweise sind die meisten Optimierungsnotwendigkeiten aus Sicht eines externen Beraters peinlich offensichtlich. Schwierig ist das Unterfangen, weil viele Protagonisten auf einmal umdenken müssen. Ein Entwickler hängt an seiner Eier-legenden-Woll-Milch-Sau-Datentabelle, der Produktmanager hat sich arg auf seinen Wortlaut „Unsere Anwendung kann alles“ eingeschossen und der UX-Experte hat Angst vor zu viel Fokus auf den echten Nutzer, weil er den schlicht nicht kennt.
Die Magie für den neuen Benutzer-orientierten Perspektiv-Wechsel liegt darin, viele Beteiligte zu eigentlich offensichtlichen Erkenntnissen zu führen – und zwar losgelöst von akuten Herausforderungen und eingebrannten Lösungswegen. Diese Erkenntnisse gilt es in klare Regeln zu gießen und dann – und zwar wirklich erst dann – diese auf akute Baustellen zu projizieren.
Tun Sie dies am besten in sehr fokussierten Workshops mit möglichst vielen Protagonisten. Nehmen Sie sich nicht zu viel Zeit. Zwei Workshoptage sollten für die ersten beiden Schritte reichen! Die offensichtlichen Ideen entspringen in den ersten Stunden, die weiteren werden in der Regel genutzt, um sie wieder mit persönlicher Subjektivität zu zerreden. Geben Sie also den Beteiligten nicht zu viel Raum, um sich damit auseinanderzusetzen, was denn die neuen Ansätze für die eigene Komfortzone bedeuten.
Schritt 1: Personas
Die Reise fängt bei den Menschen an, die die Software nutzen oder am gesamten Lebenszyklus eines Softwareprodukts teilhaben. Betrachten Sie demnach auch ihr eigenes Marketing, den Vertrieb oder auch den Support. Versuchen Sie ein möglichst treffendes, aber reduziertes Bild zu bekommen.
Zu betrachtende Aspekte können sein:
- Rolle und ihr Hauptziel: Was ist die Kernaufgabe der Persona? Gerne stelle ich die Frage “Was macht diesen Menschen glücklich, wenn er abends nach Hause geht?”
- Vermeidung: Wovor hat eine solche Persona unterschwellig Angst? Was will sie partout vermeiden? Hier geht es vor allem um nicht-fachliche, psychologische Faktoren.
- Veränderungswille: Wie sehr sucht sich eine solche Persona eigene Wege und wie offen ist sie für neue Werkzeuge?
- Fachliche Expertise: Wie fachlich qualifiziert ist sie?
- Digital-Expertise: Wie ist die Persona an den Umgang mit dem Digitalen gewöhnt? Hilfreich ist hier auch die Frage nach genutzten Medien im freiwilligen privaten Bereich. Welche Apps nutzt eine solche Persona?
- Vertriebseinfluss: Wie wichtig ist die jeweilige Persona für den Verkaufsprozess der Software?
Schritt 2: Szenarien
Eine Persona arbeitet unter verschiedenen äußeren Rahmenbedingungen, einem „Kontext“. Eine Persona in einem Kontext nennt sich „Szenario“. Eine Arzthelferin im Sprechzimmer mag ein Szenario sein, die gleiche Arzthelferin an der Anmeldung ein anderes, weil die äußeren Umstände und die Aufgaben andere sind.
Der Kontext bestimmt also über Möglichkeiten der Interaktion und der Informationsaufnahme. So mag in einem Fall extreme Hektik wenig Raum für Informationsaufnahme in einer Software die Folge sein. In einem anderen Fall steht nur ein Touch-Panel zur Verfügung, wieder in einem anderen disqualifiziert sich Unterstützung durch Sound auf Grund von alles übertönender Maschinenlautstärke. Häufig spielen hier auch Lichtverhältnisse eine Rolle: Ein Nachtmodus in reinen Rottönen oder andersherum sehr hoher Kontrast, um gleißendem Sonnenlicht entgegenzuwirken, können die Folge sein. Die Nutzung in einem Fahrzeug wiederum kann die Interaktion stark einschränken, z.B. ist in einem solchen Fall von Drag & Drop abzuraten.
Aspekte können sein:
- Routine: Wie stark ist der Nutzer an die Arbeitssituation gewöhnt?
- Stress: Steht der Nutzer unter Stress? Hat seine Tätigkeiten womöglich drastische Auswirkungen?
- Aufmerksamkeit: Hat der Nutzer Raum, um sich der Software voll zu widmen, oder erfordern andere Aktivitäten seine eigentliche Aufmerksamkeit?
- Informationsrezeption: Kann der Nutzer uneingeschränkt Informationen aufnehmen? Oder ist seine Sicht eingeschränkt?
- Interaktion: Welche Endgeräte stehen zur Verfügung? Welche Tätigkeiten muss der Nutzer zusätzlich ausführen und hat womöglich die Hände gar nicht frei?
- Sonstiges Equipment als zusätzlicher Hinweisgeber: Trägt der Nutzer Handschuhe und ist Touch-Interaktion daher eingeschränkt? Trägt er ein Visier und hat eingeschränktes Sichtfeld? Hat er eine Maschine in der Hand und kann nur einhändig tippen?
Schritt 3: Ableitung von Regeln je Szenario
Haben Sie in Schritt 2 die Szenarien definiert, so gilt es nun, die Erkenntnisse in rein logische Regeln für das Interface abzuleiten. Unabdingbar wichtig ist zu diesem Zeitpunkt, dass Sie ausschließlich die Konsequenzen, die sich aus den Personas und den Kontexten ergeben, diskutieren und nicht in altbekannte Funktionsdiskussionen abdriften!
Diskutieren Sie, wie Sie jeder der Erkenntnisse aus den Personas und den Kontexten begegnet können. Kommen Sie anschließend zu einem Konsens in Form eines Regelkatalogs je Szenario.
Je konkreter und verbindlicher Sie diesen Regelkatalog in großer Runde festzurren, desto klarer können Sie in den kommenden Monaten und womöglich Jahren alle Diskussionen rational und effektiv führen!
Schritt 4: Use Cases
Nun können Sie sich über konkrete Aufgaben Ihrer Nutzer Gedanken machen. Vermeiden Sie aber rein funktionale Formulierungen wie „Der Nutzer muss die Bewegungsdaten aggregiert angezeigt bekommen.“. Legen Sie stattdessen den Fokus auf:
- Trigger: Was lässt den Benutzer aktiv werden? Woher weiß er, dass er etwas tun muss?
- Ziel: Was genau muss der Benutzer erreichen? Mit dieser Zielformulierung können Sie später in Diskussionen zu Funktionalitäten immer die Frage stellen: „Ist die Funktion für die Zielerreichung des Use Cases unabdingbar?“.
- Entscheidungen: Welche Entscheidungen muss der Benutzer treffen? In welcher Reihenfolge tut er das in der Regel?
- Informationen: Welche Informationen benötigt er für diese Entscheidungen? Welche Vorstellungen hat der Benutzer von diesen Informationen? Gibt es aufgreifbare „Mentale Modelle“? Wichtig: Je visueller Analogien sind, desto einfacher ist das Verständnis. Denken Sie also in Bildern und nicht in Formularen und Tabellen.
- Interaktionen: Was genau sind die Entscheidung des Nutzers? Sind es Selektionen von Daten? Ist es Eingabe von Informationen? Wie kann der Benutzer diese Entscheidungen effektiv dem System mitteilen?
Schritt 5: Gliedern in Apps
Mit einer Liste an Szenarien, die Kombinationen von Personas und Kontexten beschreiben, und einer langen Liste an Use Cases, müssen Sie diese in Einsprungspunkte gliedern. Stellen Sie sich dazu ein Dashboard vor, auf dem der Nutzer seine aktuelle Aufgabe – also App – wählt. Was in Ihrem Kontext eine App ist, ist abhängig vom Funktionsumfang Ihrer Software. So kann ein Szenario eine App sein, oder einzelne Use Cases. Wichtig sind folgende Merkmale:
- Der Nutzer muss seine Aufgabe klar mit einer und zwar einer einzigen App in Verbindung bringen. Sonst gibt es Zweifel, Versuche, Scheitern und dahinschwindende Akzeptanz.
- Definieren Sie glasklar, welche App welches Szenario und welche Use Cases adressiert werden. Nur so können Sie in subjektiven Diskussionen auf die Erkenntnisse und Regelkataloge referenzieren.
- Überfrachten Sie keine App! Je kleiner und fokussierter eine App, desto besser! Sonst landen Sie wieder am Anfang: Bei einem Boliden ohne Nutzerakzeptanz, dafür aber mit hohem Schulungsaufwand.
Schritt 6: Priorisierung
Jetzt sollten Sie das gesammelte Material priorisieren. Das Ziel: Das erste MVP („Minimal Viable Product“). Welche Szenarien sind am wichtigsten? Warum? Welche Use Cases sind für diese Szenarien essentiell? Wie groß ist der relative Aufwand der Use Cases? Gibt es die Möglichkeit von „Low hanging fruits“ – also viel Mehrwert durch wenig Aufwand?
Ergebnis muss eine Liste an Apps sein, die definierte Szenarien und Use Cases bespielen.
Das Ziel! Schritt 7: Funktionalität
Sie sind angekommen! Jetzt dürfen Sie je priorisierter App über Funktionalität und Technologie diskutieren! Nun haben Sie aber klare Leitplanken! Hilft das Feature XY im aktuellen UseCase YZ? Sind die Interface-Konzepte und Entwicklungen mit dem einst aufgestelltem Regelkatalog konform?
Führen Sie jede einzelne kleine Anforderung auf die Bedürfnisse der Personas, der Kontexte und der Use Cases zurück und entlarven Sie subjektive Meinungen, die die Software wieder verwässern würden.
Fazit
Die Krux neuer, schlanker und agiler Softwareprodukte liegt in der klaren Adressierung der Kunden und Nutzer. Konkret in Form von neu gegliedertem Funktionsspektrum und reduzierten Interfaces, die immer nur die gerade relevanten Nutzergruppen und Anwendungsszenarien fokussieren. Im Wege stehen Gewohnheiten und subjektive Meinungen, die diesen Perspektiv-Wechsel zu einem anstrengenden Unterfangen machen.
Die Lösung ist eine klare Argumentationskette von Personas, zu Kontexten, zu Szenarien und Use Cases. Mit dieser hier vorgestellten Vorgehensweise lässt sich in Diskussionen immer der Kunde und der Nutzer in das Zentrum rücken und Subjektivität vernünftig und unemotional einsortieren.
„Internet of Things“ ist das neue Hype-Thema in Medien und Kongress-Landschaften. Ausnahmsweise könnte sich diese neue durchs Dorf getriebene Kuh dieses Mal allerdings als reinrassiges Sportpferd entpuppen, denn das Thema scheint konkreter als manch anderes Kürzel aus der Buzzword-App und bekam unter dem Schlachtruf „Industrie 4.0“ sogar Rückendeckung von der Bundesregierung. Grund genug, sich das Thema von der historischen Wurzel bis hin zu den zu erwartenden Chancen und Risiken anzusehen. 
Schon lange bin ich auf der Suche nach einem Begleiter an meinem Arm, der mein Leben digital bereichert. Nach einigen Jahren des Experimentierens bin ich nun fündig geworden. Und zwar nicht kurzfristig fasziniert, sondern nun seit Monaten nachhaltig begeistert! Das kleine Gerät, das es in mein zugegeben kritisches Herz geschafft ist, mag allerdings für den einen oder anderen eine Überraschung sein…
Der Konzern Apple macht dieser Tage eine Schlagzeile nach der anderen. Und es fällt schwer all diese Nachrichten einzuordnen, denn mal werden gigantische Gewinne gemeldet, mal eine Reduktion der iPhone Produktionsrate. Gerüchte um angeblich (aber nie offiziell bestätigte) geringe Verkaufszahlen der Apple Watch lassen uns Medienkonsumenten vollends meinungslos zurück.
