Dave Akins hat im Verlauf seiner Karriere die Laws of Spacecraft-Design formuliert. (Bild: <a href="https://www.shutterstock.com/de/image-illustration/spacecraft-orbiting-earth-3d-illustration-540775171?src=qUJeMtmQ89qxfv0ytD9_4Q-1-30">Shutterstock</a>)
Dave Akins hat sein Leben damit verbracht, Raumfahrzeuge zu entwickeln. Im Verlauf seiner Karriere war er außerdem als Dozent am MIT sowie an der University of Maryland tätig. Die Laws of Spacecraft-Design sind größtenteils Resultat seiner eigenen Verfehlungen, wie er es selbst ausdrückt, vereinzelt fußen sie auch auf den Erfahrungen anderer. Heute hängen sie im Gebäude des Nasa Johnson Space Center’s Mission Control. Einige dieser Gesetze gelten nicht nur für die Entwicklung von Raumfahrzeugen, sondern auch für den Design- und Entwicklungsprozess von Software.
Law No. 3: Fertig? – Noch lange nicht
Design ist ein iterativer Prozess. Die notwendige Anzahl an Iterationen ist eine mehr als die zum aktuellen Zeitpunkt durchgeführte. Dies ist zu jedem Zeitpunkt gültig. Auf Software gemünzt bedeutet das: Die Entwicklung einer Software ist nie vollständig abgeschlossen, zumindest nicht, solange die Software eingesetzt wird. Solange sie im Einsatz ist, ist es wichtig, mit technologischen Entwicklungen und neuen Anforderungen Schritt zu halten. Dazu gehört beispielsweise auch, regelmäßig auf neue Versionen von Programmiersprachen oder Frameworks zu migrieren.
Law No. 12: Falsch machen kann man viel
Es gibt nie nur eine richtige Lösung. Es gibt aber immer mehrere falsche. Dieser Punkt trifft vor allem auf die Webentwicklung zu. Elemente in einer Web-App lassen sich auf verschiedene Arten darstellen – oft ohne, dass Endnutzer:innen einen Unterschied bemerken würden. Mit einer Ausnahme: Menschen, die beispielsweise auf assistive Technologien angewiesen sind. Für sie macht es einen Unterschied, ob sie es mit semantischem HTML oder mit mehrfach verschachtelten divs statt passenden, strukturierenden Elementen zu tun haben – alle möglichen Lösungen, die das nicht berücksichtigen, sind demnach die falschen.
Law No. 15: Die UX muss sitzen
Nirgends gibt es mehr Raum für Design-Verbesserungen als an der Benutzeroberfläche. Hier ist gleichzeitig die Prime Location, um es zu vermasseln. Wer beispielsweise eine neue App installiert und nicht binnen weniger Momente versteht, wie sie funktioniert, wird sie schnell wieder deinstallieren. Für Software, die sich an Expert:innen richtet, gilt dasselbe zwar nicht, aber auch hier kann eine gute UX wettbewerbsentscheidend sein.
Law No. 20: Der erste Eindruck zählt
Eine Weisheit, die sich vor allem Produktmanager:innen und Menschen in verwandten Tätigkeitsfeldern hinter die Ohren schreiben sollten: „Ein schlechtes Design mit einer guten Präsentation ist irgendwann zum Scheitern verurteilt. Ein gutes Design mit einer schlechten Präsentation ist sofort dem Untergang geweiht.“ Daraus abzuleiten ist zwar nicht, dass die Präsentation eines Produkts wichtiger ist, als das Produkt selbst, wohl aber, dass die Präsentation – zumindest in einem frühen Stadium – mindestens genauso erfolgsentscheidend ist wie das Produkt selbst.
Law No. 40: Die Notwendigkeit eines MVP
Die Definition des zentralen Konzepts der agilen Softwareentwicklung, eines sogenannten Minimum Viable Products oder MVP, fasst Akin wie folgt zusammen: „Ein Produkt kann erst verbessert werden, wenn es funktioniert.“
Die vollständige Liste aller Spacecraft-Design-Laws findet sich auf den Websites der University of Maryland.
