Immer komplexere Funktionalität, immer einfachere User Interfaces

Immer komplexere Funktionalität, immer einfachere User Interfaces

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.

Portraitfoto von Daniel Greitens

Daniel Greitens

Digital Pioneer

Daniel Greitens widmet sich dem Thema Digitale Innovation seit über 20 Jahren. Mit dem knapp 50-köpfigen Team seiner Firma MAXIMAGO konzipiert und entwickelt er Software-Innovationen auf Basis von WPF und HTML5, spricht auf den bekannten Konferenzen und ist Autor von Fachliteratur.

No Comments

Post a Comment

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.