Martin Seehase
30. August 2013

Budget – keine Ausrede, um UI-Prototyping zu ignorieren

coding code program compute coder develop developer development

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

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.

Budget – keine Ausrede, um UI-Prototyping zu ignorieren
Nutzen Sie unser Know How im Bereich SAP User Experience!
Wir beraten sie zu Vor- und Nachteilen der SAP UI-Technologien und unterstützen Sie bei Planung und Design Ihrer Applikationen.

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.

Martin Seehase

Martin Seehase

Mein Name ist Martin Seehase und ich bin begeisterter Salesforce Consultant bei mindsquare. Wie meine Kollegen habe ich mein Hobby zum Beruf gemacht.

Sie haben Fragen? Kontaktieren Sie mich!



Das könnte Sie auch interessieren

Alle Beteiligten (oder Neudeutsch "Stakeholder"), die am Entstehungsprozess einer Software teilhaben oder sie am Ende des Prozesses in ihrem Arbeitsalltag benutzen, haben unterschiedliche Vorstellungen und Anforderungen an das User Interface. […]

weiterlesen

Je später ein Fehler gefunden wird, umso teurer ist es ihn zu beheben. Dieser Leitspruch hat sich in der Softwareentwicklung auf allen Ebenen eines Projektteams manifestiert wie kein anderer. Dies […]

weiterlesen

"Je größer der Nutzen ist, den Unternehmen und Mitarbeiter aus ihrer SAP-Software ziehen, desto besser können sie am Markt agieren." (Deutschsprachige SAP-Anwendergruppe e.V., DSAG) Wir haben die größten Hebel zur Verbesserung […]

weiterlesen

Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.





Kontaktieren Sie uns!
Alexander Koessner-Maier
Alexander Kössner-Maier Kundenservice