Budget – keine Ausrede, um UI-Prototyping zu ignorieren
In vielen Softwareprojekten wird auf den Einsatz von UI Prototyping zu Gunsten des Budgets verzichtet. Meine Erfahrungen zeigen jedoch, dass dieses Verhalten eher Aufwände generiert als sie zu vermeiden.
Bei der Erstellung von Fach-/Designkonzepten für neue Softwarekomponenten wird sehr häufig ein nicht unwesentlicher Punkt vergessen oder übergangen: Das User Interface.
UI Prototyping
Es wird davon ausgegangen, dass die realisierende IT-Abteilung aus der fachlichen Beschreibung der einzelnen Softwarekomponenten herausliest, wie die manuelle Interaktion mit dem zu entwickelnden Programm stattfinden soll. Auf die Nachfrage, welche Ideen und Vorstellungen existieren, erntet man als Entwickler nicht selten fragende Blicke von der beauftragenden Fachabteilung. Es sei überhaupt nicht ihre Verantwortung an der Software mitzuarbeiten. Ihre Aufgabe besteht darin die fachlichen Anforderungen zu formulieren und später das Endprodukt zu bewerten, nichts weiter (Natürlich gibt es auch andere Beispiele, jedoch habe ich diese in meinen bisherigen Projekten sehr selten angetroffen).
Unterschiedliche Erwartungen in ein User Interface
Häufig bleibt einem Entwickler nichts and
eres übrig als ein SAP User Interface nach seinen eigenen Vorstellungen zu bauen. Das Problem hierbei sind die komplett unterschiedlichen Standpunkte von Entwicklern und Fachbereich. Eine Benutzeroberfläche, die für einen Entwickler ergonomisch, benutzerfreundlich, intuitiv etc. ist, kann für den Fachbereich genau das Gegenteil darstellen. Da können schon kleine Details wie das Ermöglichen von Tastenkombinationen wie STRG + C und STRG + V für das Kopieren und Einfügen von Texten Konfliktpunkte darstellen. Für einen Entwickler sind diese Tastenkombinationen ein essentielles Handwerkszeug, Kontextmenüs werden nur im absoluten Notfall benutzt. Beim Fachbereich sieht dies manchmal aber komplett anders aus.
Sie erhalten die Komplettlösung – Ihr Projekt machen wir zu unserem Projekt. Wir sind Ihr Dienstleiter für Ihr Entwicklungsprojekt, das den Anwender in den Mittelpunkt stellt.
Gerne spreche ich mit Ihnen über Ihre Ausgangslage und zeige Lösungsmöglichkeiten auf. Auf Wunsch unterbreite ich Ihnen im Anschluss ein unverbindliches Angebot.
Kontaktieren Sie mich: Telefon 0211.9462 8572-16 oder per E-Mail info@erlebe-software.de
Ingo Biermann, Fachbereichsleiter
Budget und UI-Prototyping
Dabei ist es einfach die verschiedenen Meinungen mit Hilfe eines UI-Prototyps zu vereinen. Es finden sich in Budget- und Projektplanung jedoch selten Ressourcen für eben diesen Prototyp. Schließlich ist es notwendig sowohl Fachbereichsressourcen, als auch Entwicklungsressourcen für die Erstellung abzustellen und das ist teuer. Dies würde sich durch konkrete Aufwände in den oben genannten Plänen wiederspiegeln. Budget und Zeit sind jedoch rare Ressourcen, die nur mit sehr genauer Prüfung bewilligt werden, auch wenn es sich dabei nur um vier Personentage handelt. Denn mehr ist meist gar nicht notwendig für die Erstellung eines UI Prototyps. Ich kann verstehen, dass Geld nicht auf Bäumen wächst und man Projekte nicht mit unendlich vielen Ressourcen versorgen kann. Budgetpläne zu erstellen ist keine einfache Aufgabe. Besonders wenn viele Parteien beteiligt sind, können interessante Großrechnungen entstehen. Doch trotz aller Integralrechnungen muss man berücksichtigen, dass sich manches Risiko in Form einer neuen Vorgehensweise auszahlen kann. Besonders dann, wenn die bisherige Vorgehensweise mehrfach gezeigt hat, dass sie Zusatzaufwände generiert.
Die Alternative sieht nicht besser aus, zumindest im Nachhinein. Ganz ohne fachlichen Input kann der Entwickler keine vernünftige UI bauen, daher muss er sowieso Details in Gesprächen mit dem Fachbereich klären. Jedoch werden hierbei immer nur einzelne Teile besprochen, nicht die Benutzeroberfläche im Allgemeinen (man hat ja schließlich keine Zeit). Dadurch fällt dem Fachbereich erst im Test auf, dass diverse Funktionen anders zu erreichen sind, als sie es sich vorgestellt haben, bzw. dass einige manuelle Arbeitsschritte zu umständlich sind. Das Resultat: Nacharbeit für den Entwickler.
Letztendlich werden die gleichen Gespräche geführt, die bei der Planung einer Benutzeroberfläche schon vor der Entwicklung hätten geführt werden können, mit dem Unterschied, dass der Entwickler bereits vergeblich Zeit für die Entwicklung einer UI verwendet hat, die nicht den Wünschen der Auftragsteller entsprechen. Im Idealfall werden die vier Personentage, die für die Planung des UI Prototypen hätten verwendet werden können in der Testphase für Nacharbeiten benötigt, meist sind es jedoch mehr.
Denn eins wird jeder Entwickler bestätigen: Es ist aufwändiger bestehende Software zu ändern, als neue Software zu schreiben.
Aus diesem Grund mein Rat an alle Projektleiter: Nutzen sie UI-Prototyping Mechanismen wie statische Wireframes, Interaktionsprototypen oder Klickdummies zum Planen der Bedienoberfläche.
Den Aufwand haben Sie sowieso, jedoch es besteht die Chance ihn zu minimieren.
