Als Fortsetzung des Blogs “Von der Lösung zum Problem” möchte ich hier in regelmäßigen Abständen über unsere Erfahrungen berichten, die wir im Projektmanagement bei der Beratung unserer Kunden gemacht haben.

Jeder Kunde macht sich erst einmal selbst viele Gedanken zu einem Problem und entwickelt Lösungen, deren Umsetzung er dann an einen externen Dienstleister abgibt. Dabei erhält dieser dann nur das Ende der gedanklichen Entwicklungsphase in Form eines Lastenheftes mit sehr konkreten Anforderungen. Oft als exakter Umsetzungsplan formuliert, damit Zeit und Geld gespart wird. Wer möchte sein Problem nochmal mit seinem beauftragten Dienstleister diskutieren und erläutern. Es ist doch alles klar, oder nicht?

Der Auftraggeber möchte seine Lösung auch gar nicht rechtfertigen oder gar anzweifeln lassen. Das ist verständlich, aber es versperrt oft den Weg zu einer besseren Lösung. Das folgende kleine Beispiel zeigt, wie eine Lösung zum Problem hätte werden können…

Wie eine Lösung…

Neulich bekam ich eine Spezifikation von unserem Kunden, die eine technische Schnittstelle beschrieb. Viele verschiedene Parameter wurden beschrieben und erläutert, die notwendig waren, eine einzige neue Funktion in einer bestehenden Anwendung zu realisieren. Nun ja – technisch gesehen jedenfalls. Dagegen ist nichts einzuwenden, der Autor war Techniker – sogar ein sehr guter Softwareentwickler in embedded systems.

Um schnell zu einem Ergebnis zu kommen – oder um mir das Leben leichter zu machen – hat er sich offensichtlich auch Gedanken darüber gemacht, wie der ein oder andere neue Parameter denn in das System gelangt. Also folgte in der Spezifikation auch prompt der Entwurf, wie ein bestehender Dialog um den entsprechenden Parameter erweitert werden sollte.

Bei der Betrachtung des Dialog-Entwurfes wurde ich stutzig. Etwas war nicht stimmig. Was war es? Der Steuerung des Parameter, der nur zwei Zustände annehmen konnte, wurde als Checkbox dargestellt. Grundsätzlich eine sehr gute Wahl. Also was war falsch? Der Ort? Nein, auch dieser passte erstaunlich gut, da er in den Kontext des Anwenders passte und nicht wie ein fünftes Rad am Wagen wirkte.

Es lag am Default – oder anders ausgedrückt an der Bezeichnung der Checkbox, was auf das Gleiche hinausläuft.

… zum Problem hätte werden können

Der Default beschrieb nicht die Regel sondern die Ausnahme!

In unserem Fall ging es um die Erweiterung einer Funktion, die die Anwender von mehr als 700 Mandanten des Kunden nutzen sollten. Der Dialog mit der Checkbox betraf etwa 150 Objekte pro Mandant. Die gewünschte Funktion sollte der Anwender pro Objekt einmalig optimal einstellen. Als ich den Kunden darauf ansprach, dass mit seinem vorgeschlagenen Dialog und dessen Default alle Anwender die Checkbox für etwa 95% ihrer Objekte ändern müssen, um die optimale Einstellung vorzunehmen, wurde ihm sehr schnell die Problematik klar: Die vorgeschlagene Lösung war nicht nützlich.

Wir änderten in der Spezifkation den Default entsprechend, damit dieser den Regelfall vorgibt, und setzen die Funktionalität um. Durch diese eine Stunde Diskussion konnten die Anwender der Software vor mehreren Stunden Arbeit bewahrt werden. Ebenso blieb dem Kunden erspart, den Usability-Fehler mit Aufwand und Image-Schaden rückgängig zu machen.

Die richtige Lösung

Bei der Lösungsfindung muß der Anwender und dessen Arbeitskontext bei der Nutzung der Software betrachtet werden, damit eine richtige, effiziente Lösung entsteht, Geht man nicht so vor, ist der Erfolg eher zufällig. Was kostet der Blick auf den Sinn eines Defaults einer Checkbox im Vergleich zu einer schlechten Benutzbarkeit der Software?

Die Akzeptanz einer Anwendung steht und fällt mit der Begeisterung, wie ein Anwender die Software nutzt. Die Akzeptanz einer Anwendung ist verantwortlich dafür, dass Prozesse beim Anwender optimal funktionieren. Software wird ja extra entwickelt und dafür eingeführt, um Prozesse zu optimieren.

Die akquinet tech@spree hat ein Competence Center für User Experience. Dieses ist in unseren Projekten maßgeblich eingebunden, um eine benutzbare Software mit hoher Akzeptanz bei den Anwendern zu konzipieren. Als Projektleiter mit dem Wunsch, unsere Kunden optimal zu beraten, bin ich froh, mit diesem Competence Center zusammen zu arbeiten und dessen Ideal – den Anwenderfokus – in unsere Lösungen für unsere Kunden zu bringen.

Fazit

Die Entwicklung einer Losung, deren Einsatz der Kunde maßgeblich benötigt, um sein Geschäftsmodell erfolgreich umzusetzen, bedarf eines besonderen Fokusses auf die tatsächlichen Anwendergruppen. Ist die Software schlecht bedienbar und vermittelt den Anwendern das Gefühl, zusätzliche Arbeit zu erzeugen, sinkt die Akzeptanz. Damit steigt die Gefahr, dass sich Anwender umorientieren. Ineffiziente Software kostet erfahrungsgemäß viel Geld (1). Die Herausforderung liegt in der Entwicklung von effizienter Software.

 

Tassilo Kubitz

akquinet tech@spree

 

 

Referenzen

(1) Ineffiziente Software kostet Mittelständler viel Geld – heise online http://heise.de/-2193205