In der agilen Entwicklung drehen sich die Themen vor sowie im Umsetzungsverlauf überwiegend um Funktionen. Usability und Design lassen sich nur im Zusammenspiel mit diesen Funktionen verkaufen.
Ein Bericht aus der Praxis
Vor Projektanfang steht die Idee. Diese ist mehr als großartig und damit vielversprechend. Sie hat das Potential eine große Nutzerzahl ansprechen zu können. Doch wie jede Idee, ist sie nur eine Idee. Sie hat noch keinen Rumpf und damit weder Hand noch Fuß. In unserer Branche generieren schlaue Produktmanager ständig Ideen dieser Art. Gänzlich unklar ist, inwieweit diese Ideen sich umsetzen lassen und Bestand auf dem Markt haben werden. Damit diese Ideen dennoch alle möglichst schnell und kosten(los)günstig umgesetzt werden, bedienen wir Projektmanager uns der Softwareentwicklung zugeschriebenen Begriffe wie agil. Damit meinen wir jedoch schnell und unkompliziert. Schlecht ist diese Zweckentfremdung jedoch keines Falls. Sie hilft den leitenden Architekten und Teamleitern ihre Methoden mit einfachen marketingtechnischen Mitteln an den Mann, hier den Geschäftsführer, zubringen. Dass aber aufgrund der gänzlich unterschiedlichen Auffassungen des Wortes agil viele Dinge schief gehen, sieht man in der Praxis. Wir reden über die Umsetzung einer Idee. Sofern sich bis Dato keiner die Mühe gemacht hat auch nur eine Zeile zu Papier zu bringen, ist diese Idee am Tag sieben noch genau so eine Idee wie am ersten Tag. Gesprochenes Wort kann jedoch nicht unterschrieben werden. Damit haben wir auch keinen Projektauftrag. Wir starten also, auch wenn wir agil arbeiten, immer erst dann, wenn wir eine Zieldefinition aufgeschrieben haben. Diese muss kein Roman sein. Aber zumindest ist dann klar, dass wir eine Schaukel zwischen zwei Bäumen mit einem Brett als Sitzgelegenheit und keinen Gummireifen, angebracht an einem Ast, haben wollen. Mit der Zieldefinition kommen die Userstories. Diese zu formulieren, fällt den meisten Produktmanagern in ihrer Rolle als Productowner nicht mehr schwer, so dass sie wie Twitter-Kurznachrichten nur so ins Backlog purzeln. Hier gilt der Grundsatz, lieber zu viele als unklare oder gar fehlende Anforderungen. Damit sind das Projekt und seine Anforderungen definiert. Das Ziel ist im groben klar und durch die Priorisierungen wissen alle, was zuerst gemacht wird. So wird sichergestellt, dass der Kunde einen möglichst frühen und dabei hohen Nutzen eines ersten Releases hat. Unabhängig von der dennoch fehlenden Umsetzungsdauer in exakten Minuten ist der Steakholder und sein in die Verantwortung gezogener Productowner bis hier hin sehr zufrieden. Jetzt liegt es nur noch an den Entwicklern. Diese schrauben und drehen was das Zeug hält und liefern an der einen oder anderen Ecke sogar etwas mehr oder bessere Software als angefordert. Dann kommt der Tag X, an dem der Productowner in der Review einen ersten Prototypen der Software visuell präsentiert bekommt. Hier ist oftmals die Überraschung groß. „Hübsch ist das Formular nicht gerade!“. Die Reaktion der Entwickler überrascht allerdings kaum jemanden, denn „hübsch war kein Akzeptanzkriterium!“. An dieser Stelle wird das Design zum Thema.
Sicherheit, Qualität und Aussehen
In der schnelllebigen Welt von Mini-Applikationen ist es nicht verwunderlich, dass das Design zurücktreten muss. Neue Funktionen müssen möglichst schnell und sicher bereitgestellt werden. Dabei ist der Punkt Sicherheit heute viel relevanter als noch vor wenigen Jahren. Kaum ein Kriterium ist so kritisch wie offene Tore bei Backend-Anwendungen besonders in Bezug auf APIs. Im Grunde heißt dies, wir legen heute unser Augenmerk auf Dinge, die uns vor wenigen Jahren extrem auf die Füße gefallen sind. Sei es die Sicherheitslücke durch XSS, SQL-Injection oder CSRF beziehungsweise das Brechen von Codemetriken und die damit entstehenden technischen Schulden. Jetzt haben wir Software auf gutem Niveau. Jedoch bleibt die große Anzahl an Nutzern aus, da die Software nicht ansprechend designed oder nicht zu bedienen ist. Dank der modernen Frameworks sind grundlegende Einstellungen an dem GUI bereits vor der ersten Zeile Code vorgenommen und sollten in vielen Fällen auch aufgrund der Wiedererkennbarkeit nicht angepasst werden. Nehmen wir den Style Guide von Apple für das iPhone oder den von Microsoft für das Windows Phone. Hier sind die Parameter ganz klar definiert und Frameworks zum Erstellen solcher Applikationen lassen dem Entwickler auch wenig Spielraum sich davon zu entfernen. Das Einhalten der Richtlinien macht die Anwendung aber keinesfalls bedienbar noch „hübsch“. Warum also kommt das Aussehen erst an dritter Stelle? Software wird doch in den allermeisten Fällen nicht für einen selber, sondern für einen Dritten geschrieben. Dieser soll sich direkt mit dem Programm wohlfühlen und es aufgrund schlechter Anordnung, grausamer Farben oder überladenen Bildschirmen nicht abstoßen!
Zeit ist Geld
In jedem Planungsteam gibt es einen Spielverderber. Dieser hört sich alle Ideen aufmerksam an und lässt das Team alle Anforderungen ausgiebig zusammentragen. Zum Schluss kommt er dann mit dem stumpfen Messer und zerreißt all die ordentlich aufeinander aufbauenden Teilpunkte zu einem Salat von Anforderungen, welche eine Software hinterher erfüllen muss. In dieser Phase spielt fast ausschließlich das Geld eine Rolle. Projektbudgets sind immer knapp und zunächst brauchen wir Funktionen, um den Kunden abholen zu können. Damit ist klar, warum Aussehen plötzlich weit in die Ferne gerät. Wir alle wissen, dass gerade im Punkt Layout viel Zeit investiert werden kann, um alle Kriterien der Nutzbarkeit und Ordnung auf dem Bildschirm zu erfüllen. Diese Zeit kostet Geld. Und diese Investition bringt dem Steakholder zunächst kein Return-of-Investment. So denkt er zumindest, aber falsch gedacht. Eine ausgiebig eingeplante Designphase in einem Projekt scheint erst mal nicht notwendig. Eine Verabschiedung von Templates für wiederkehrende Sichten allerdings schon. In agilen Projekten wird der Kunde zum Tester. Dieser Nutzer sollte in die Gestaltung des Designs einbezogen werden. In der Prototypphase kann mit dem Benutzer zusammen die logische Aufbereitung von Bildschirmen erarbeitet werden. Diese Vorgehensweise erspart nicht nur Zeit, sondern verhindert auch die sich wiederholenden Arbeitsprozesse in der Abnahme eines vollständig erstellten Designkonzeptes.
Freie Hand
Während der Erstellung der First-Alpha-Version kommen auf den Entwickler aufgrund neuer Produktideen auch meist neue technologische Hürden zu. Mit diesem Hintergrund begrüßen viele den lockeren Umgang mit dem Layout. Wichtig für den Architekten oder das selbst kontrollierende Team ist, dass die Entwicklung nicht in eine statische Einbahnstraße getrieben wird. Dazu gibt es Technologien mit denen Layoutanpassungen programmiertechnisch jeder Zeit anpassbar sind. In der Webwelt zählen die Cascading Style Sheets (CSS) in Verbund mit View-Templates zu den angesagtesten Methoden. Das Zusammenspiel erlaubt es, Layoutvorlagen für verschiedene Sichten zu erstellen, welche im Programmablauf ständig recycelt werden können. Mit Hilfe der Klassen in CSS lassen sich zunächst die Elemente sinnvoll auf dem Bildschirm platzieren, ohne auf ihre Erscheinung Rücksicht nehmen zu müssen. Im Nachgang fällt es den Designern sowie den Productownern um einiges leichter, die detaillierten Layoutentscheidungen anhand der klickbaren GUIs zu treffen. Hierbei geht es schlussendlich um die genaue Positionierung von Fenstern oder die Fenstergröße für bestimmte Inhalte. Besonders bei Fenstern mit dynamischem Inhalt lässt sich vorab nur schwer bestimmen, welche Größe notwendig für den Inhalt aber minimal für den stilistischen Charme ist. In der Praxis zeigt sich gerade bei diesen Entscheidungen der Teufel im Detail. Viele Ehrenrunden muss der Designer drehen bis der Productowner zufrieden ist und schlussendlich muss das Fenster beispielsweise doch die ganze Breite des Bildschirmes einnehmen.
Fazit
Während eines Projektes ist der Entwickler am nächsten an der Software und hat damit auch die innovativsten Ideen zur erstmaligen Gestaltung von Bildschirmen. Sofern die richtigen technologischen Entscheidungen getroffen wurden, kann das Layout im Nachgang solange angepasst werden bis die Software im Uhrwerk und im Ziffernblatt perfekt abgestimmt ist. Ein vorab erstelltes Design hingegen ist statisch und lässt sich nur schwerfällig an veränderte Softwareeigenschaften angleichen. Halten wir fest: so genannte Mockups retten uns auch nicht vor der Katastrophe. Der ständige Kontakt zum Productowner und die Einhaltung von Style Guides hingegen vermeiden Überraschungen und bilden das Fundament für nachhaltige Softwareentwicklung.
Geschrieben im Jahr 2012
Top comments (0)