Warum scheitert das Projekt, obwohl erfahrene Entwickler involviert sind? Inwiefern gefährden Eitelkeit und Ignoranz den Projekterfolg und worauf sollte von Beginn an geachtet werden, um problematische Entwicklungen verhindern zu können? Wir geben euch eine praktische Hilfestellung dazu, wie Probleme vermieden werden können, die durchaus häufiger auftreten, als uns lieb ist.
»Ich muss die Nutzer nicht fragen, ich kenne mich bestens mit dem Produkt aus und weiß, was wir wie umsetzen.«
Das ist ein Satz, den man in Softwareentwicklungsprojekten oder bei der Produktentwicklung leider immer wieder zu hören bekommt, vor allem von Personen, die sich schon länger mit einem Thema oder Produkt befassen. Sie sind der Meinung, ihr gesamtes Wissen sei allumfassend, sodass sie genau wissen, welche Anforderungen in einer Software umgesetzt werden müssen, damit diese die Bedürfnisse der Nutzer erfüllt. Sie stellen sich quer, wenn (ihrer Meinung nach unnötiger) Aufwand investiert werden soll, um die tatsächlichen Anforderungen und Bedürfnisse der Nutzer zu erfassen. Die eigenen Ideen werden ohne Rücksicht auf andere Informationsquellen durchgesetzt und die Anwendung im schlimmsten Fall anschließend auch noch selbst getestet. Sie kennen die Nutzer schließlich so gut, dass sie auch selbst die Software testen können – Usability-Probleme werden so natürlich direkt vollständig eliminiert. Und bei der Gestaltung der Oberfläche wissen sie sowieso, was der beste Weg ist (lest hierzu auch gerne: Woran ein Design scheitern kann). Andere etablierte Lösungen, wie Design Patterns, interessieren nicht, man hat doch schon eine Top-Idee. Kurz gesagt: Sie sind der Experte, nur ihre Meinung zählt.
Eitelkeit und Ignoranz lassen ein Projekt scheitern
Das alles klingt natürlich sehr sarkastisch und überzogen, aber es ist leider Fakt, dass es immer wieder Personen gibt, die die eigene Meinung bevorzugen und somit den Projekterfolg gefährden, insbesondere, wenn es sich bei den Personen um Entscheider handelt. Leider führt eine solche Sichtweise schlichtweg dazu, dass ein Projekt vollständig scheitern kann – weil komplett an den tatsächlichen Bedürfnissen der Nutzer vorbei entwickelt wird. Es wird niemand anderes dazu befragt, was denn die tatsächlichen Anforderungen an das Produkt sind, sondern diese werden auf Basis der eigenen Meinung gesammelt.
Dies führt im schlimmsten Fall zu einer »Featureitis«: Es kommen immer mehr und mehr Features in die Anwendung, die die späteren Nutzer aber zum Teil gar nicht brauchen, die die Anwendung aber unnötig komplex machen. Und schlimmer noch: die wirklich benötigten Features sind gar nicht enthalten, das heißt, die Nutzer können ihre Ziele gar nicht erreichen. Da die Anwendung nicht mit realen Nutzern getestet wurde, kommt noch hinzu, dass das als super empfundene Design alles andere als nutzerfreundlich ist.
Lasst Ignoranz und Eitelkeit nicht zu!
Wenn ihr ein Projekt wirklich erfolgreich durchführen wollt, stellt sicher, dass niemand im Team ein solches Denk- und Entscheidungs-Monopol auslebt. Ignoranz anderer Ideen und Lösungen und vor allem der Nutzer bringt gar nichts. Stellt vielmehr sicher, dass die Anforderungen, die umgesetzt werden, auch diejenigen sind, die die wirklichen Erfordernisse der Benutzer befriedigen. Dies könnt ihr zum Beispiel über eine Anforderungserhebung mittels Kontextinterviews realisieren. So senkt ihr die Kosten der Entwicklung, denn es wird nur das umgesetzt, was auch wirklich vom Endnutzer benötigt wird. Gleichzeitig vermeidet ihr somit auch eine unnötige Komplexität.
Bezieht auch andere Lösungen mit ein: Orientiert euch an etablierten Design Patterns; sie sind nicht ohne Grund als »Pattern« deklariert und werden häufig eingesetzt.
Wichtig ist auch, immer über den eigenen Tellerrand zu blicken und den eigenen Horizont zu erweitern. Um dann auch sicherzustellen, dass die gestaltete Anwendung nutzerfreundlich ist und einfache, verständliche Interaktionskonzepte beinhaltet, führt regelmäßig Usability-Tests mit realen Endnutzern durch – so erlebt ihr nicht am Ende bei der Produkteinführung die böse Überraschung, dass die Konzepte nicht so verständlich sind, wie ihr dachtet.
Die Anwendung des Usability-Engineering-Prozesses erlaubt euch gar nicht, dass bestimmte Personen ihr Wissens-Monopol ausleben – die tatsächlichen Meinungen der Nutzer werden sie relativ schnell auf den Boden der Ernüchterung zurückholen.
Kommentare