Suche
Reports, Dashboards und Scorecards

Designing for Usability

Matthias Pietschmann
© Shutterstock/Dirk Ercken

Mit den technischen Details der Umsetzung von Reports, Dashboards und Scorecards für die Darstellung von Unternehmenskennzahlen beschäftigt sich die IT-Branche ausgiebig. Neue Versionen von Frontend-Tools bieten eine große Auswahl an Features für gesteigerte Performance, neue Diagrammtypen, die Möglichkeit, mehr Datenquellen anzubinden und vieles mehr. Nur die Benutzerfreundlichkeit von Reports wird immer noch stiefmütterlich behandelt, und das, obwohl sie für die Akzeptanz der Anwender so entscheidend ist.

Bei der Durchführung von Projekten zur Darstellung von Unternehmenskennzahlen in Reports, Dashboards und Scorecards gibt es viele Erfolgsfaktoren. Die Berichte müssen performant sein, das Design ansprechend, die Daten aktuell und fehlerfrei. Aber selbst wenn diese Punkte perfekt umgesetzt werden, erreicht das Projektteam noch nicht automatisch die Akzeptanz bei den Anwendern, die es sich wünscht. Oft ist die Lösung zwar technisch fehlerfrei, aber die Nutzer empfinden die Anwendung als mühselig und unübersichtlich. Hinzu kommt, dass das Projektteam die Kritikpunkte in seiner festgelegten Perspektive vielfach nicht sieht. In der Folge nutzen die Mitarbeiter weiterhin Altsysteme, bauen parallele Schattensysteme in Tabellenkalkulationsblättern auf oder nutzen die Berichte erst, nachdem das Management sie gegen großen Widerstand durchgesetzt hat. In jedem dieser Fälle kann das Entwicklerteam sein Projekt als gescheitert ansehen. Das Thema Bedienbarkeit wurde bei diesen Vorhaben von Anfang an nicht genügend berücksichtigt. Oder unerfahrenere Projektmitarbeiter konnten das Feedback der Anwender auch deshalb nicht ausreichend einbeziehen, weil sie es erst nach Projektende erhalten haben. Ein Fehler! Denn die Benutzbarkeit von Berichten ist für die spätere Nutzung ein zu wichtiger Punkt, um ihn entweder komplett zu vernachlässigen oder erst im Nachhinein anzugehen, wenn die Anwender bereits gegen die Anwendung Stimmung machen.

Was bedeutet eigentlich benutzerfreundlich?

Jacob Nielsen, als Experte für benutzerfreundliche Anwendungsentwicklung bekannt, verbindet mit den Begriffen Benutzerfreundlichkeit oder Usability mehrere Attribute: Learnability, Efficiency, Memorability, Errors und Satisfaction. Reports, Dashboards und Scorecards werden nach Nielsen also dann als benutzerfreundlich betrachtet, wenn die Bedienung einfach zu erlernen ist (Learnability), die Benutzung so effizient ist (Efficiency), dass der Nutzer bereits nach einer kurzen Lernkurve eine hohe Produktivität erreicht, und sich die Bedienungsschritte gut einprägen lassen (Memorability). Ebenfalls für die Bedienerfreundlichkeit eines Reports spricht, wenn nur selten „Errors“ ausgegeben werden. Sollten doch einmal Fehler auftreten, dann sollte der Bericht dabei in einem konsistenten Zustand bleiben, dem Benutzer ein neues Aufsetzen ohne Umstände ermöglichen und dazu die nötigen Informationen zur Fehlerbehebung liefern. Last but not least sollte die Oberfläche so angenehm zu bedienen sein, dass die Anwender die Arbeit mit dem Bericht als positiv empfinden (Satisfaction).

Der Begriff Usability ist übrigens von Accessibility und Corporate Design abzugrenzen. Der Begriff Accessibility beschreibt ein zugängliches Design, im Sinne von barrierefrei. Hiermit ist gemeint, dass Menschen mit Behinderungen (z. B. Farbblindheit) einen Bericht ebenso uneingeschränkt nutzen können wie der Rest der Zielgruppe. Corporate Design dagegen beschreibt das einheitliche visuelle Erscheinungsbild eines Unternehmens. Die Einhaltung des Corporate Designs ist nicht mit Usability gleichzusetzen. Im Idealfall vereint ein Report Accessibility, Usability und Corporate Design in sich, in Ausnahmen kann jeder dieser Aspekte aber auch alleine auftreten. Reports, Scorecards und Dashboards stellen besondere Anforderungen an die Usability, da sie interaktive Elemente enthalten. Navigationspfade in OLAP-Systemen sind ein nicht gerade triviales Beispiel. Einen ausgedruckten Bericht zu verwenden, stellt dagegen für die meisten Anwender kein Problem dar. Im Business-Intelligence-Bereich kommt hinzu, dass Reports meist vollständig durch Tools erstellt werden. Der Tooleinsatz bringt dabei oft Beschränkungen mit sich (z. B. die Vorgabe bestimmter Interaktionspfade), die ein benutzerfreundliches Design erschweren. Trotzdem ist eine benutzerfreundliche, leicht bedienbare Oberfläche kein hehres Ideal, sondern lässt sich schon mit der Beachtung von einfachen Grundsätzen erreichen. Unter den Begriff Usability fallen viele, teils banal anmutende Maßnahmen beim Design von Reports, Dashboards und Scorecards. Dennoch ist Usability kein reines Buzzword, mit dem sich Berichte, Produkte usw. besser verkaufen lassen. Usability zahlt sich für den Projekterfolg aus, ohne zusätzliche Kosten zu verursachen. Ein benutzerfreundliches Berichtsdesign gestaltet sich für den Entwickler nicht unbedingt aufwändiger, er ist allerdings gefordert, es von Anfang an besser zu durchdenken. Der Nutzer wird ihm dies später mit seiner Sympathie für die Berichtsumgebung danken, die ihn über evtl. anfänglich auftretende Bugs leichter hinwegsehen lässt.

Uneingeschränkte Möglichkeiten trotz Usability

Die Beschäftigung mit dem Thema Usability trifft bei vielen Designern auf Vorurteile. Weit verbreitet ist zum Beispiel die Annahme, dass benutzerfreundliches Design Einschränkungen bei der Umsetzung mit sich brächte oder visuelle Aspekte darunter leiden würden. Das ist nicht der Fall. Das Corporate Design (CD) und die Corporate Identity (CI) können und sollten weiterhin volle Anwendung finden. Auf Usability beim Design zu achten, verlangt auch keine unansehnliche Schwarzweiß-Gestaltung ohne jegliche Formen und Farben. Die Beispiele für benutzerfreundliches und benutzerunfreundliches Design in diesem Artikel zeigen vielmehr, dass keine Einschränkungen nötig sind, wenn nur die bisherigen Gestaltungsmittel richtig eingesetzt werden. Eine weitere Fehleinschätzung ist, das sich Benutzerfreundlichkeit mit einer zusätzlichen Bedienungsanleitung erreichen ließe. Das ist natürlich falsch. Eine Bedienungsanleitung über mögliche Navigationswege ersetzt niemals eine intuitive Benutzeroberfläche.

Die Perspektive wechseln

Viele Entwickler machen den Fehler, die Anwendung nach ihren eigenen Kriterien zu gestalten und vergessen dabei, dass ihre Kunden unter Umständen ganz andere Anforderungen an die Nutzbarkeit haben. Um diesen Anforderungen gerecht zu werden, brauchen die Projektmitarbeiter zunächst eine konkrete Vorstellung über den späteren Anwendungskreis. Ein Handbuch wird durch ein optimales Design natürlich nicht überflüssig, aber es sollte zu dem genutzt werden, wofür es auch wirklich geeignet ist, nämlich die Fachlichkeit detailliert zu erläutern, und nicht, um den Anwender in gewisser Weise durch die Navigationsstruktur zu führen. Im späteren Produktiveinsatz fristet das Handbuch erfahrungsgemäß nur ein Schattendasein, sodass grundlegende Informationen wie die zur Navigation dort mit hoher Wahrscheinlichkeit verlorengingen.  Für ein möglichst benutzerfreundliches Dashboard, eine Scorecard oder einen Report ist es wichtig, von Anfang an einen Fokus auf die Benutzerfreundlichkeit zu setzen. Damit lassen sich Mehrkosten für ein Re-Design schon im Vorfeld vermeiden.

Für die Gestaltung von benutzerfreundlichen Oberflächen sind seitenlange Checklisten oder komplizierte, genau zu beachtende Regelwerke eher nicht das richtige Instrument. Hier sind der gesunde Menschenverstand und die Sichtweise der Entwickler entscheidende Kriterien. Und die richtige Sichtweise lässt sich mit ein paar einfachen Grundsätzen und ein bisschen Übung entwickeln. Die Perspektive des Anwenders liegt gar nicht so fern, wie viele denken. Im Grunde weiß jeder Einzelne ziemlich sicher, wie benutzerfreundliches Design nicht aussehen sollte. Drei bekannte Beispiele:

• Buttons, die auf jeder Seite an anderer Stelle sind
• Begrifflichkeiten, die nicht durchgängig verwendet werden
• Suchvorgänge, bei den man immer wieder aufs Neue raten muss, wo etwas zu finden sein könnte

Da wünschte man sich als Nutzer, dass die Entwickler so einfache Prinzipien befolgt hätten, wie dieselben Funktionalitäten immer an derselben Stelle zu platzieren oder, dass man sich zu Anfang des Projekts auf ein Vokabular geeinigt hätte, das später durchgängig verwendet wird.

Warum also nicht gleich so?

Viele Entwickler haben bei der Gestaltung von Dashboards zu allererst den visuellen und den technischen Aspekt im Blick und merken dabei zu spät, dass sie Fehler ihrer Vorgänger wiederholen. Häufig kommt dann sehr spät, am Ende der Entwicklungsphase, wenn sich Zeit und Budget schon längst dem Ende zuneigen, der Wunsch auf, die Berichte noch umzugestalten und zu verschönern. Zu spät! Es ist also wichtig, Usability von Anfang an als Designaspekt zu berücksichtigen – insbesondere, da für Usability-Maßnahmen fast nie ein Change Request beauftragt wird, geschweige denn, dass diese im Projektbudget fest eingeplant würden. Eine spätere Korrektur ist meist gar nicht mehr möglich oder sehr teuer.

Abb. 1: Negativbeispiel für Usability: 1. Nicht erläuterte Abkürzungen 2. Nicht selbstsprechende Icons 3. Verwendung von kaum zu unterscheidenden Farben 4. Verwendung von Grafiken mit wenig Mehrwert 5. Gleicher Informationsgehalt mit unterschiedlichen Einheiten (in Mio. und Td. Euro)

Aufmacherbild: usability user friendly and accessibility test or audit for a website design von Shutterstock / Urheberrecht: Dirk Ercken

[ header = Seite 2: Dem Anwender das Denken abnehmen ]

Dem Anwender das Denken abnehmen

Als zentraler Leitsatz für benutzerfreundliches Design kann die Aussage „Don’t make me think“ von Steve Krug angesehen werden. Krug formulierte sein „First law of usability“ zwar ursprünglich im Zusammenhang mit Websitedesign, aber es lässt sich auch 1:1 übertragen. „Don’make me think“ meint, dass ein Design für den Anwender vom ersten Moment an selbsterklärend und intuitiv sein sollte. Beispielsweise sollte der Nutzer Buttons mit derselben Funktionalität immer an derselben Stelle finden und einen Schalter zum Aktualisieren der Daten sofort als solchen erkennen. Eigentlich eine Selbstverständlichkeit. Und dennoch scheint die Verwendung von nichtssagenden Icons, die ihre Funktion erst mittels Tooltip preisgeben, wenn man mit der Maus darüber fährt, in Reports fast schon zur Gewohnheit geworden zu sein. Ein Icon alleine spricht fast nie für sich und kann bei den Nutzern unterschiedliche Assoziationen hervorrufen (Abb. 1). Daher sollte das Bildchen im Normalfall mit einer Beschriftung versehen werden. Der Text sorgt für die Klärung der Funktionalität, das Icon dient nur dem visuellen Reiz. Vielen Funktionen lassen sich ohnehin nur mit viel Fantasie passenden Symbolen zuordnen. Das Diskettensymbol für das Speichern hat sich zwar inzwischen weitestgehend durchgesetzt, aber wie illustriert man in einem Geschäftsbericht zum Beispiel das Filtern von Datensätzen?

„Don’t make me think“ in der Benutzerfreundlichkeit ist also dann erfüllt, wenn sich der Anwender über die Navigation, die Funktionen usw. keine Gedanken machen muss und er zu keiner Zeit ins Stocken gerät, weil er zum Beispiel überlegen muss, wo etwas zu finden ist oder welche Funktionalität sich hinter einem Button verstecken könnte. Neben uneinheitlich verwendeten Icons können auch redundante Funktionen der Grund für die Zeitverzögerung sein (z. B. mehrere Buttons, die auf die vorherige Seite zurückführen). Intuitives Design ist also das Ziel.  Ein bereits bestehender Report oder ein Dashboard in der Entwicklung kann in jeder Phase dahingehend analysiert werden, ob der Benutzer ohne Umwege durch den Bericht navigiert. Getestet werden kann die Usability am besten, indem man dem Anwender kommentarlos über die Schulter blickt. Für einen ersten Test reicht es schon, einem Projektkollegen bei der Benutzung über die Schulter zu blicken. Dabei könnten Datenbankentwickler oder Businessanalysten die Maus übernehmen – und schon entsteht eine ganz neue Perspektive. Diese Kurztests ersetzen aber natürlich nicht das Feedback der eigentlichen Anwender, die später in der Praxis mit dem Bericht arbeiten sollen.

Die üblichen Fehler vermeiden

Beliebte Fehler sind vor allem bei Geschäftsberichten die bereits genannten uneinheitlich verwendeten Begrifflichkeiten, die hier gerne auch bei Skalierungen und Einheiten in der Repräsentation von Zahlen vorkommen. Bei diesen Berichten empfiehlt es sich daher besonders, pro Report mit den gleichen Einheiten zu arbeiten. Ein Dashboard, dass auf der linken Seite den Umsatz in tausend Euroschritten zeigt, rechts hingegen in Millionen Euro, zwingt den Anwender, grundsätzlich über die Darstellung nachzudenken. Vor allem, wenn Darstellungen so nah beieinanderliegen, verwirren sie. Ebenso empfiehlt es sich auf einem Dashboard, Berichte nur dann nebeneinander darzustellen, wenn sie auch zusammen gelesen werden sollen. Andernfalls kann es passieren, dass Scheinkorrelationen in die Darstellungen hineininterpretiert werden.

Abkürzungen sollten zugänglich dokumentiert sein. Gerade für neue Mitarbeiter stellen die vielen Abkürzungen im Projektalltag ein großes Problem dar. Hier sind auch die vielen nicht gebräuchlichen Abkürzungen bzw. solche zu nennen, die vermeintlich aus Platzmangel entstehen und selbst für erfahrene Mitarbeiter eine große Hürde darstellen. Ein reales Beispiel aus dem Projektalltag: Der Kunde kürzt die Spaltenüberschriften einer Tabelle, um alle Informationen bei einer Bildschirmauflösung von 1 280 x 1 024 Pixel ohne Scrollbalken darstellbar zu machen. Am Ende waren vier Spalten nur noch mit „S“, „F“, „H“ und „M“ betitelt. Schon wenige Wochen später wusste keiner der Beteiligten mehr, welche Informationen diese Spalten darstellen sollten. Helfen können hier einfaches HTML und CSS (ohne den Einsatz von JavaScript, soweit das Tool den Zugriff auf HTML nicht kapselt): Das HTML-Element <abbr> hinterlegt für einen Text die Syntax einer Abkürzung. Alle gängigen Browser unterstützen die Verwendung dieses Elements und zeigen beim Darüberfahren mit der Maus die ausgeschriebene Bedeutung an. Mittels CSS kann diese beispielsweise beim Ausdrucken automatisch abgebildet werden (Abb. 2).

Weitere Beispiele für gängige Unsitten sind Menügruppierungen oder Navigationseinträge, die nicht für sich selbst stehen und damit nicht gedeutet werden können. Sehen sie doch einmal in einem beliebigen Softwareprodukt nach, welche Funktionalitäten unter der Gruppierung „Extras“ zu finden sind, nur weil der Entwickler nicht lange nach einem passenderen Oberbegriff suchen wollte…Auch Farben sollten entsprechend ihrer Konvention eingesetzt werden, d. h. rot steht in der westlichen Welt für Stop oder Gefahr und sollte dementsprechend verwendet werden. Dem Anwender mit Farben visuelles Feedback geben, z. B. durch Hover-Effekte in Menüs oder bei der Darstellung von Kennzahlen, ist an und für sich ein gutes Stilmittel. Nur sollte man zum Beispiel für die Ampeldarstellung in einer Scorecard keinesfalls schwarz, grau und braun verwenden, nur weil dies zum Beispiel die Farben des Corporate Designs sind, sondern immer das übliche rot, gelb und grün.

Informationen kontextabhängig darzustellen, ist ein wichtiges Hilfsmittel, um die Benutzbarkeit von Oberflächen zu verbessern. Dazu gehört auch, dem Benutzer immer nur jene Aktionen anzubieten, die im aktuellen Kontext auch Sinn machen: Kann der Anwender die Daten im aktuellen Zustand nicht aktualisieren, sollte also auch kein Button für diese Aktion angezeigt werden. Eine saubere Anforderungs- und Designspezifikation, beispielsweise mithilfe von UML, bildet hierfür bereits alle Interaktionsmöglichkeiten im nötigen Zustand ab. In der Umsetzung sollten die Entwickler allerdings weiterhin auf eine konsistente Oberfläche achten, also darauf, dass Informationen für den Benutzer immer an denselben Stellen dargestellt werden. Ebenfalls wichtig: Führt ein Anwender eine Aktion aus, sollte er hierfür auch immer eine Rückmeldung erhalten. Ein Button, der nach der Betätigung nicht reagiert, weil die Aktion im Hintergrund eine längere Laufzeit hat, sorgt für Verwirrung beim Anwender.

Abb. 1: Positivbeispiel: 1. Abkürzungen vermieden oder Bedeutung hinterlegt (unterstrichen) 2. Icons durch Beschreibung ergänzt 3. Deutliche farbliche Unterscheidung plus Prozentzahlen 4. Darstellung mit mehr Informationsgehalt 5. Gleiche Informationen mit derselben Einheit (in Mio.) dargestellt

Besondere Herausforderungen

Benutzerfreundliches Design ist übrigens grundsätzlich unabhängig vom Vorgehensmodell. Egal ob Wasserfallmodell oder agiles Vorgehen – mit beiden lässt sich benutzerfreundlich arbeiten. Beim klassischen Wasserfallmodell, bei dem jede Projektphase linear durchlaufen wird, benötigen Designer allerdings etwas mehr Erfahrung. Sie sollten sich schon sehr früh in die Rolle des Anwenders versetzen können, um zu erahnen, an welchen Stellen in der Oberfläche er ins Stocken geraten könnte. Denn der Report trifft bei diesem Konzept schließlich erst am Projektende auf den Anwender und bietet somit während des Verlaufs keinen Raum für Korrekturen. Agiles Vorgehen unterstützt ein benutzerfreundliches Design zwar sehr gut, wenn nach jeder Iteration das Feedback der Anwender eingeholt wird, aber auch das ist kein Garant für benutzerfreundliches Design. Wie in jeder Phase der agilen Softwareentwicklung zählt auch hier die Einbeziehung der Anwender über das gesamte Projekt hinweg. Die Anwender sollten dabei zu einem frühen Zeitpunkt eigenständig mit dem Report arbeiten können. Eine Vorführung des aktuellen Stands der Iteration durch den Entwickler bietet nicht dasselbe Nutzungserlebnis wie eine selbstständige Navigation.

Kompliziert wird die Umsetzung eines benutzerfreundlichen Designs, wenn es im Zuge einer Migration stattfindet. In solchen Fällen sind die Altberichte häufig auf Experten ausgerichtet und wimmeln nur so von unzähligen Abkürzungen, nichtssagenden Symbolen, vielen Tastenkombinationen und umständlichen Bedienvorgängen. Trotz dieser Hindernisse finden sich die Anwender mit diesen Reports gut zurecht, weil sie schon seit Jahren mit ihnen arbeiten. Beim Redesign ist daher Fingerspitzengefühl gefragt und es empfiehlt sich ggf. nur wirkliche Usability-Katastrophen zu korrigieren. Hilfreich kann es sein, im ersten Schritt die Anwender zu fragen, welche Gestaltungen sie im Report tatsächlich stören, und in einem zweiten Schritt eigene Vorschläge zu unterbreiten. So riskieren Entwickler keine Veränderungen, die vielleicht aus ihrer Sicht richtig sein können, aber von den Anwendern aufgrund der Macht der Gewohnheit nicht gut angenommen werden. Gleichzeitig vermeiden sie die Rolle eines klischeehaften Beraters, der nach einem kurzen Blick alles vermeintlich besser beurteilen kann als ein langjähriger Kundenmitarbeiter.

Fazit

Der wichtigste Schritt zur Gestaltung eines durchdachten, benutzerfreundlichen Designs ist immer der erste: sich der Bedeutung dieses Themas bewusst zu werden und einen Willen zu seiner Umsetzung zu entwickeln. Ein Artikel wie dieser bringt natürlich keine Experten auf diesem Gebiet hervor. Das soll er auch gar nicht. Wenn es gelungen sein sollte, Impulse für die richtige Sichtweise zu geben, wäre schon viel gewonnen. Entwickler, die ihren Fokus beim nächsten Design stärker als bisher auf die Usability richten, werden es Schritt für Schritt schaffen, Reports, Dashboards oder Scorecards so zu gestalten, dass die Anwender sie jedes Mal ein kleines bisschen mehr lieben als zuvor.

Geschrieben von
Matthias Pietschmann
Matthias Pietschmann
Matthias Pietschmann studierte Wirtschaftsinformatik (M.Sc.) und arbeitet seit mehreren Jahren in der IT-Beratung, seit 2012 als Consultant im Bereich Business Intelligence bei OPITZ CONSULTING. Dort beschäftigt er sich schwerpunktmäßig mit den Themen Anwendungsentwicklung, Oracle Data Warehouse, ETL und Business Intelligence.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: