Rolf B: Radiobuttons vorbelegen

Beitrag lesen

Hallo Jochen,

okay - du weißt, was da fachlich zu bauen ist und kannst damit von uns hier am besten beurteilen, ob das UI und sein Verhalten für die Anwender eine gute Lösung darstellt. Wir können nur grundsätzliche Maßstäbe beschreiben, an denen Du das messen kannst.

Aber das Argument "das ist die Vorlage, die muss 1:1 umgesetzt werden" ist ungültig. Es setzt nämlich voraus, dass die Vorlage von jemandem erstellt wurde, der sich mit sinnvollem UI Design auskennt. Und DAS ist längst nicht immer der Fall.

Die häufigere Vorgehensweise ist diese: Jemand im Fachbereich, der von IT, Usability und korrektem Design von UIs keine Ahnung hat, möchte einen Vorgang automatisieren. Anstatt den Gesamtprozess zu betrachten und zu überlegen, wie man ihn geeignet per IT umsetzt, nimmt dieser Mensch Excel her, malt damit die Papierformulare ab, benutzt dabei die UI Controls, die Excel für eigene Automatisierung anbietet und nennt das ein Mockup der zu realisierenden Oberfläche. Dazu noch eine oberflächliche Beschreibung dessen, was im Fachbereich gemacht wird, fertig ist die Vorgabe. Das geht dann an die Koordinationsabteilung. Dort sitzt irgendwer, der mangels anderweitiger Verwendbarkeit dorthin abgeschoben wurde, in der Annahme, dort würde er (oder sie - auch Frauen können unfähig sein) den geringsten Schaden anrichten, und gibt diesen Auftrag unreflektiert an die Programmierung.

Ein Projekt, an dem sich Prozess- und UI-Designer beteiligen, wird nicht aufgesetzt. Eine exakte Analyse dessen, was im Fachbereich gemacht wird, findet nicht statt. Ist doch "nur ein Kleinauftrag".

Der IT-Mensch, der mal auf der Uni was von Prozessen und Usability gehört haben mag, kommt mit Rückmeldungen wie "aber das könnte man so und so besser machen". Die werden vom Koordinator abgeschmettert mit der Begründung: der Fachbereich will das genau so haben. Der Versuch einer Klärung scheitert, weil der Koordinator dann zugeben müsste, keine Ahnung zu haben. Das direkte Gespräch mit dem Fachbereich ist verboten, bzw. der Fachbereich ist komplett unbekannt, wenn die IT extern ist.

Die erste Programmversion macht dann genau das, was in der Vorgabe stand. Leider ist das etwas ganz anderes, als der Auftraggeber sich vorgestellt hat. Mit Glück gibt es nun Klärungsrunden. Zumeist hagelt es aber dann Defect-Tickets, aus denen sich die tatsächlich gewünschte Fachlichkeit dann herauskristallisiert. Als externer Lieferant kann man sich dann die Hände reiben, weil man eine Menge Change Requests abrechnen kann.

Und am Ende steht eine halbwegs funktionale und schlecht bedienbare Anwendung, die aber immerhin genau so aussieht wie der Excel-Albtraum des Auftraggebers. Die User meckern über den Mist, den die IT mal wieder geliefert hat. Der Einkauf meckert über den teuren Lieferanten.

Phantasie? Nein, 35 Jahre Berufserfahrung...

Rolf

--
sumpsi - posui - obstruxi