Die Rolle der Benutzer im Softwaredesign

„Das ist doch keine Rocket-Science“ – Was Software-Entwicklung von der Weltraumforschung lernen kann

Jan Weddehage

© Shutterstock / ImageFlow

In der Software-Entwicklung fällt oft der Spruch: „Das ist keine Rocket-Science“. Gemeint ist damit, dass die Programmierung bestimmter Komponenten nicht so schwierig ist, wie es auf den ersten Blick scheint. Aber womöglich haben die beiden Bereiche doch mehr gemeinsam als allgemein angenommen wird. Wie wäre es zum Beispiel, wenn wir die Folgen einer schlecht designten Anwendung genau so ernst nehmen würden, wie die fatalen Konsequenzen einer fehlerhaften Rakete?

Lassen wir uns also einen Moment lang auf den Vergleich ein, den Josh Anderson in seinem Artikel „Designing Software like Building a Rocket: Ready for Launch?“ zieht. Anderson sieht die Schnittstelle zwischen der Raketen-Wissenschaft und der Softwareentwicklung im Design.

Softwaredesign und Weltraumforschung

Bei der Beförderung von Objekten in den Weltraum müssen zunächst physikalische Gesetze überwunden werden, damit der Austritt aus der Erdatmosphäre gelingt. Ist das bewältigt, ist die Frage zu klären, wie in einer absolut menschenfeindlichen Umgebung Verhältnisse geschaffen werden können, die das Überleben der entsandten Crew sichern.

Diese nahezu unmögliche Aufgabe wurde in den 50ern und 60ern gemeistert; sie war jedoch verbunden mit einem enormen Verschleiß und Verbrauch von Ressourcen. Signifikante Verbesserungen in diesem Bereich, die auf eine nachhaltige Raumfahrt zielen, zeichnen sich erst jetzt, knapp 60 Jahre später, ab.

So hat vor Kurzem das private US-amerikanische Raumfahrtunternehmen SpaceX einen kommerziellen Kommunikationssatelliten mithilfe einer Falcon-9-Rakete in die niedrige Erdumlaufbahn befördert. Die sichere und selbstständige Landung der Rakete nach erfolgreichem Abschluss der Mission mag zwar einfach aussehen; dem Unterfangen gingen allerdings jahrelange Forschungsarbeiten mit teilweisen starken Rückschlägen voraus.

Elon Musk, Gründer von SpaceX, vergleicht die Herausforderungen beim Bau einer Weltraumrakete mit seinen Erfahrungen als Softwareingenieur. Hier wie da ist man mit dem Problem konfrontiert, dass Komponenten in einem künstlichen Raum entwickelt werden, der sich von der späteren „Auführungsumgebung“ unterscheidet:

The best analogy for rocket engineering is if you wanted to create a really complicated bit of software. You can’t run the software as an integrated whole, you can’t run it on the computer it’s intended to run on, but the first time you put it all together and run it on that computer it must run with no bugs.

Die Frage nach der Benutzerfreundlichkeit

Aus Musks Vergleich lassen sich Rückschlüsse auf ein erfolgreiches Softwaredesign schließen. Insbesondere bei Entwicklungen im Business- und Enterprise-Bereich wird die Frage nach dem richtigen Design häufig auf die Implementierung möglichst vieler Features und Funktionen reduziert. Mithilfe der so realisierten Programme sollen Arbeitsabläufe innerhalb von Unternehmen verbessert und effizienter gestaltet werden – nur ist das oft nicht der Fall.

Statt für eine Arbeitserleichterung zu sorgen, werden die Anwender in der Regel von der überwältigenden Anzahl von Optionsmöglichkeiten förmlich erschlagen. Die Softwarelösungen sorgen derart nicht für den nötigen Überblick, sondern verwirren die Nutzer unnötig. In Designfragen scheint die featuregetriebene Entwicklung davon auszugehen, dass die User die implementierten Funktionen schon im Laufe der Zeit erlernen werden, da sie schlicht keine andere Wahl haben.

Das kommt Unternehmen üblicherweise teuer zu stehen. Die Plattformen sind nicht nur in ihrer Anschaffung teuer, sondern sie verursachen darüber hinaus auch noch ungeahnte Mehrkosten (Trainings für die Belegschaft, Einsatz von Experten) und führen zu starken Zeiteinbußen. Warum die Vorstellung, dass ein featuregetriebenes Softwaredesign automatisch in einer guten Benutzerfreundlichkeit resultiert, katastrophale Folgen haben kann, zeigt sich wiederum besonders deutlich mit Blick auf die Weltraumforschung: Raketen passen sich schlechten Konstruktionen nicht einfach an, weil sie es müssen. Bei mangelnder Ausführung explodieren sie und sorgen so für das Scheitern eines Projekts.

Die Rolle der Nutzer im Softwaredesign

Der Vergleich von Elon Musk verdeutlicht, warum in der Softwareentwicklung bei Designfragen nicht einem featuregetriebenen, sondern einem benutzerorientierten Ansatz der Vorrang eingeräumt werden sollte. Wie beim Bau einer Rakete sollten bei Designentscheidungen die Instanzen im Mittelpunkt stehen, welche letzten Endes von fehlerhaften Entscheidungen am stärksten betroffen sind: die Nutzer.

Im Interfacedesign hat sich dieser Trend bereits durchgesetzt und spiegelt sich im Wandel vom UI- zum UX-Design wider. Auch im Softwaredesign sollten die Wünsche und Bedürfnisse die wichtigsten Entscheidungen leiten, um nützliche und bedienbare Applikationen zu schaffen. Die Funktionen dürfen den Anwendern nicht einfach vorgesetzt, sondern sie müssen auf ihre Ansprüche abgestimmt werden. Erst so können Applikationen die Arbeit der Betroffenen wirklich erleichtern und für eine gesteigerte Effizienz und Produktivität bei gleichzeitiger Reduzierung der Kosten sorgen.

Fazit

Der Erfolg einer Anwendung bemisst sich an der Benutzerakzeptanz und –produktivität. Diese beiden Messwerte können deutlich gesteigert werden, wenn in Designfragen nicht die unterschiedlichen Funktionen und Features, sondern die Anwender im Vordergrund stehen. Auch Unternehmen profitieren von einem benutzerorientierten Ansatz: Durch intuitiv zu bedienende Anwendungen entfallen notwendige Schulungskosten oder Experteneinsätze. Generell gilt: Ein schlechtes Softwaredesign sollte nicht auf dem Rücken der User ausgetragen werden.

Aufmacherbild: Start up concept with businessman via Shutterstock / Urheberrecht: ImageFlow

Verwandte Themen:

Geschrieben von
Jan Weddehage
Jan Weddehage
Jan Weddehage studiert an der Goethe Universität Frankfurt am Main und arbeitet seit März 2015 als Werkstudent bei Software & Support. Kontakt: jan[at]janweddehage.de
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: