Wie Projekte untergehen, wenn Usability Engineering vernachlässigt wird

Der Artikel erschien zuerst bei FIT für Usability.


Bei dem Snow Cruiser handelte es sich um ein riesiges Schneemobil, mehr als 15 m lang, über 5 m breit und über 4 m hoch, das seine 34 t Gesamtgewicht auf bis zu 40 km/h beschleunigen konnte. Der Snow Cruiser wurde von 1937 bis 1939 konstruiert und gebaut mit dem Ziel, die Antarktis zu erforschen. Das Projekt scheiterte, da der Snow Cruiser im praktischen Anwendungsfall nicht in der Lage war, selbst kleinste Erhebungen zu überwinden und im tiefen Schnee einfach einsank. Der Snow Cruiser wurde aufgegeben und im ewigen Eis zurückgelassen. Was war schief gelaufen?

Die Geschichte des Antarctic Snow Cruisers

Dr. Thomas C. Poulter (1897–1978) war ein Wissenschaftler und Antarktisforscher und 1933–1935 leitender Wissenschaftler der zweiten Antarktis-Expedition des US-amerikanischen Generals und Polarforschers Richard E. Byrd. Dort erlebte er, wie schwierig es war, bei Temperaturen weit unter Null und teilweise bei Dunkelheit weite Strecken durch Schnee und Eis zurückzulegen. Daraufhin konstruierte er ein gewaltiges Schneefahrzeug für Byrds nächste große Antarktisexpedition: den Antarctic Snow Cruiser.

Die Geschichte des Antarctic Snow Cruisers ist sowohl Komödie, als auch Tragödie. Sie lässt sich am besten anhand der folgenden Bilder erzählen, sonst ist sie schwer zu glauben.

Dr. Poulter war selbst jahrelang in der Antarktis und entwickelte die Idee seines Transportfahrzeugs, das unter den widrigen Bedingungen im ewigen Eis bestehen konnte, direkt vor Ort und auf Basis seiner eigenen Erfahrungen. Dennoch scheiterte er mit seinem Projekt auf ganzer Linie.

Die Entwicklung des Snow Cruisers und die Geschichte seines Scheiterns lassen viele Parallelen erkennen zu aktuellen Softwareentwicklungsprojekten. Viele der Fehler, die Dr. Poulter und sein Team gemacht oder zugelassen haben, zeigen sich so oder so ähnlich in heutigen Projekten und führen auch dort regelmäßig zu Problemen. Welche Probleme sind das? Und wenn der Atlantic Snow Cruiser nach den Regeln des Usability-Engineering-Prozesses, wie er in DIN EN ISO 9241-210 beschrieben ist, entwickelt worden wäre, was wäre dann besser gelaufen?

Wenn Domänenexperten denken, ihr Fachwissen reiche aus

Dr. Poulter beschäftigte sich nach seinem Abschluss als Physiker am Iowa Wesleyan College mit verschiedenen Dingen. Er beobachtete Meteore, befasste sich mit seismischer Erkundung und unternahm Hochdruckexperimente. Als wissenschaftlicher Leiter der Armour Research Foundation entwickelte er seismische Verfahren zur Prospektion in der Arktis, um die Dicke von Gletschern zu messen. Am Stanford Research Institute gründete er ein Labor für Sprengstoffe und Hochdruckforschung, das spätere »Poulter Laboratory«. Im Laufe seines Lebens unternahm er insgesamt drei Reisen in die Antarktis und 15 in die Arktis. Wer, wenn nicht ein promovierter Physiker und ausgewiesener Antarktis-Experte, sollte dazu in der Lage, ein Fahrzeug für eine Antarktis-Expedition zu konstruieren?

Tatsächlich waren aber weit mehr und ganz andere Kenntnisse und Fähigkeiten vonnöten. Poulter glaubte, die Probleme zu kennen, die eine solche Expedition mit sich bringt, aber die Probleme zu kennen reicht nicht aus, um Lösungen entwickeln zu können.

Das ist der Grund, weshalb erfahrene Usability Engineers sich sehr lange im Problemraum aufhalten und viel Zeit für die Analyse verwenden, um zu versuchen, bis zum Kern eines Problems durchzudringen. Dazu beobachten und befragen sie Nutzer, gehen aber niemals so weit, sie nach ihren Wünschen zu fragen oder um Lösungen zu bitten. Die meisten Nutzer sind dazu schlichtweg nicht in der Lage. Entweder, weil sie nicht einen Schritt zurücktreten können, um unbefangen und unabhängig von existierenden Lösungen über ein Problem nachdenken zu können; oder aber, weil ihnen das nötige Fachwissen und Handwerkszeug fehlt, um geeignete, praktische und zugleich innovative und kreative Lösungen finden zu können.

Dr. Poulters Entwurf des Snow Cruiser war eine Variante der »eierlegenden Wollmilchsau« geworden, ein Fahrzeug, das alle Vorteile haben, alle Bedürfnisse befriedigen und allen Ansprüchen genügen sollte. Damit kommen wir zum zweiten Grund seines Scheiterns und zum nächsten Problem.

»Featureitis« und »Overengineering« – Alles und deshalb Nichts

Dr. Poulter entwickelte den Snow Cruiser nicht einfach nur als Transportfahrzeug, sondern legte ihn darüber hinaus als Forschungsstation und Mannschaftsquartier aus, das eine fünfköpfige Besatzung ausstatten und ein volles Jahr lang versorgen und unabhängig von der Umgebung machen sollte. Nicht zu vergessen das Flugzeug, das der Snow Cruiser auf seinem Rücken transportieren sollte. All dies sorgte letztlich dafür, dass der Snow Cruiser so groß und schwer und somit auch so schwergängig wurde, dass er seine Aufgaben nicht erfüllen konnte.

Das erinnert an eine Software, der mehr und mehr Funktionen hinzugefügt werden. Das bringt zwei Probleme mit sich. Zum einen wird die Softwarearchitektur immer komplexer und der Code immer unübersichtlicher, sodass die Stabilität und Wartbarkeit der Entwicklung nicht mehr gewährleistet sind; Kompromisse in Funktion und Design sowie eine größere Fehlerhäufigkeit sind die Folge. Zum anderen nimmt die Benutzerbarkeit der Anwendung ab; Benutzer finden sich nicht mehr so gut zurecht und sehen die Funktionen, die sie benötigen, nicht mehr vor all den Funktionen, die sie nicht benötigen. So wie der Snow Cruiser nicht in der Lage war, eine Schneewehe hinaufzufahren, so sind sie nicht mehr in der Lage, ihre Aufgaben zu erfüllen und ihre Ziele zu erreichen.

Poulter musste Investoren für sein Projekt finden, um die Finanzierung sicherzustellen. Insofern ist es nachvollziehbar, dass er – in der Nomenklatur des Kano-Modells gesprochen – mehr auf die Begeisterungsmerkmale gesetzt und darüber die Basismerkmale aus den Augen verloren hat. Diese Fehler umgehen Usability Engineers dadurch, dass sie auf den Nutzungskontext konzentrieren, siehe die Prozessphase »Nutzungskontext verstehen und beschreiben«, und daraus Erfordernisse und die tatsächlichen Nutzungsanforderungen ableiten. Diesbezüglich haben Poulter und sein Team noch weitere Fehler begangen.

Den Nutzungskontext berücksichtigen – vor allem beim Testen

Der Begriff »Nutzungskontext« steht für die Summe aller Benutzer eines interaktiven Systems mit ihren Arbeitsaufgaben und Arbeitsmitteln (Hardware, Software und Materialien) sowie der physischen und sozialen Umgebung, in der sie ihre Arbeitsaufgaben bearbeiten.

Ob eine Lösung eine hohe oder eine geringe Usability hat, muss stets im Nutzungskontext bewertet werden. Nehmen wir als Beispiel das interaktive System »Winterjacke«. Benutzer von Winterjacken sind alle Menschen, die Kleidung tragen, um sich gegen äußere Witterungsbedingungen zu wappnen. Die primäre Aufgabe einer Winterjacke ist der Schutz vor Kälte, wobei die physische Umgebung des Nutzungskontexts eingeschränkt ist auf einen niedrigen Temperaturbereich, der für jeden Benutzer individuell ist. Wahrscheinlich aber sind Temperaturen jenseits von 15 °C außerhalb des Nutzungskontexts. Daher würde niemand auf die Idee kommen, die Usability einer Winterjacke bei 25 °C zu bewerten. Sie wäre sehr gut (»Benutzer fühlt sich gut gewärmt«) oder sehr schlecht (»Benutzer fühlt sich überhitzt«), je nachdem, wie lange der Test dauert. Eine solche Evaluation wäre sinnlos.

Dafür, dass Dr. Poulter einige Jahre in der Antarktis verbracht hat, wurde zu wenig über die Arbeitsaufgabe Fortbewegung in der physischen Umgebung Antarktis mit Schnee und Eis und Temperaturen weit unter Null nachgedacht bzw. darüber, wie man nachweisen kann, dass der Snow Cruiser in dieser Umgebung funktioniert. Jedenfalls ist mir nicht bekannt, dass der Snow Cruiser – oder ein Modell des Snow Cruisers – jemals unter realistischen Bedingungen getestet worden wäre. Die Phase »Produkt evaluieren« hat nicht stattgefunden, jedenfalls nicht so, wie sie im Usability-Engineering-Prozess angelegt ist. Die mittlere Temperatur in Chicago im Oktober liegt über 20 °C und damit weit, weit oberhalb der Temperaturen, die den Nutzungskontext des Snow Cruisers definieren. Unter diesen freundlichen Bedingungen wurden Tests auf befestigten Highways, in Sandwüsten und Kuhwiesen durchgeführt. Das ist ähnlich wenig sinnvoll wie Tests einer Winterjacke bei diesen Temperaturen.

Zudem haben Dr. Poulter und sein Team mindestens einen weiteren Aspekt des Nutzungskontexts vergessen, nämlich die Arbeitsaufgabe Transport von den Fertigungshallen in Chicago zum Hafen nach Boston sowie von dort per Schiff in die Antarktis. Es ist zu bezweifeln, dass von Anfang an der Plan war, ein Schneefahrzeug auf eigener Achse über die Highways der USA fahren zu lassen, anschließend seinem Heck mit Schneidbrennern zu Leibe zu rücken, um es auf ein Schiff zu verladen, von dem es, angekommen am Zielort, kaum wieder entladen werden konnte.

All dies hat sicherlich auch damit zu tun, dass so wenig Zeit zur Verfügung stand. Der Snow Cruiser musste in kaum mehr als fünf Monaten gebaut und ausgeliefert werden, da eine harte Deadline eingehalten werden musste, nämlich der Einbruch des Polarwinters. Unterm Strich blieb damit keine Zeit, Konzepte oder gar Prototypen ausgiebig zu testen.
Kommen wir auf die Frage zurück, was besser hätte laufen können, wenn der Atlantic Snow Cruiser unter den Rahmenbedingungen des Usabiliy-Engineering-Prozesses entwickelt worden wäre. Der Prozess sieht Iterationen vor und damit »Rücksprungmöglichkeiten« von einer Phase in eine der vorigen Phasen, sofern Bedarf dafür besteht. In einem funktionierenden Prozess wird fortwährend mit Benutzerbeteiligung getestet, ob und inwieweit Gestaltungslösungen den Nutzungsanforderungen und den Anforderungen des Nutzungskontexts genügen.

Mit diesem Ansatz hätte den oben dargestellten Problemen begegnet werden können, von der Konzentration auf das Wesentliche bis hin zu Entwurf und Test unter Berücksichtigung des Nutzungskontexts. Natürlich wäre es vermessen, zu behaupten, mit Usability Engineering wäre der Atlantic Snow Cruiser ein voller Erfolg geworden. Dazu waren zu viele Rahmenbedingungen zu schlecht. Aber das Projekt hätte kein so plakativer Misserfolg werden müssen, dass noch fast 80 Jahre später Artikel darüber geschrieben werden.

Quellen

0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Kommentar verfassen