From Software to UX

Usability? Was zum Teufel ist Usability? Wie bin ich überhaupt zum Thema UX und Usability gekommen? Und warum sind Softwareentwickler per se eigentlich weiter von UX entfernt als der Bäcker vom Metzger, würden sich dies aber selbst nie eingestehen? Softwareentwickler gehen die Sache von Natur aus technisch an. Für den Programmierer mag das noch in Ordnung sein, für den Full-Stack-Developer oder den Frontend-Developer jedoch nicht mehr.

 

Programmierst Du noch oder reflektierst Du schon?

Ich muss gestehen, ich habe von den 15 Jahren als Softwareentwickler die ersten Jahre regelrecht verschlafen was den Bereich angeht. Dass Software für den Kunden geschrieben wird, war in meinem Kopf lange Zeit nicht existent. Im Alltag des Entwicklers gibt es Vorgaben der Geschäftsleitung, Vorgaben des Vertriebs und technische Rahmenbedingungen. Nur sind all diese Vorgaben und Rahmenbedingungen wirklich auch das was der Kunde möchte und braucht? Auf welche Grundlagen stützen sich die Anforderungen an das Produkt? Ich habe es oft erlebt, dass Entwickler Sprüche fallen lassen wie

der Kunde ist zu doof – ich weiß selbst am Besten was der Kunde will –  das Formular muss so sein, weil es so richtig ist – die Suchmaske mache ich dort hin, weil sie dort noch Platz hatte

Bei dieser in meinen Augen falschen Herangehensweise habe ich mich schon vor vielen Jahren immer wieder hinterfragt, ob es denn wirklich so ist. Ist der Kunde wirklich doof? Und nutzt ein Kunde die Software tatsächlich so, wie wir Entwickler uns das vorgestellt haben? Schon immer wollte ich einmal dem Kunden über die Schulter blicken bei der Bedienung meiner Oberfläche. Leider ließ sich das nie realisieren, weil dieser Wunsch oft als Spinnerei abgetan wurde. Aus diesem Grund bewarb ich mich vor einigen Jahren einmal an einer Eye-Tracking-Studie und nahm einige wertvolle Erkenntnisse daraus mit.

Wissen wir denn wirklich immer, was der Kunde will, wie der Kunde tickt und vor allem wie der Kunde die Software bedient? Ich kann dazu eine klare Antwort geben: NEIN, wir wissen es nicht. All die Jahre habe ich mich über schlechte Bedienkonzepte von Software geärgert, ohne jedoch auf offene Ohren gestoßen zu sein. Das war aber alles zu einer Zeit in der ich ebenfalls noch in der Entwicklersicht dachte.

 

Usability matters

Eines Tages, es war auf einer Wochenendreise nach Tschechien, blätterte ich im Buch Web Usability: Rocket Surgery Made Easy von Steve Krug herum und konnte es nicht mehr aus der Hand legen. Zu dem Buch werde ich separat noch eine Rezension schreiben. Wen es interessiert findet es z.B. hier auf Amazon .

In dem Buch ging es unter anderem um Tests für und mit dem Benutzer. Den Usability-Tests. Ich hatte das Gefühl, endlich hat jemand ein Buch über all die Dinge geschrieben, die mir seit Jahren im Kopf herum schwirrten, ich aber keinen fachlich fundierten Beweis gefunden hatte. Ich fühlte einerseits Bestätigung, andererseits ein Gefühl des Aufbruchs in eine benutzerorientiertere Welt der Software. Mir war zwar klar, dass einige Softwareentwickler bereits lange so dachten und auch arbeiten, mein Umfeld jedoch nicht.

Ich las das Buch binnen zwei Tagen und machte mir viele Notizen. Mit diesen Dingen belästigte ich Kollegen und Vorgesetzte und brachte die ein oder andere Idee auf den Tisch. Leider war die Reaktion anders, als ich es mir erhofft hatte. Vielleicht hätte ich besser Schlangenöl verkaufen sollen.

Leicht demotiviert warf ich das Buch in die Ecke, fing aber sporadisch an, Blogs zum Thema Usability zu lesen. Meine Herangehensweise beim Entwickeln änderte sich jedoch zunächst nicht. Sie war immer noch nicht benutzerbezogen. Und dann kam eines Tages ein weiteres Schlüsselerlebnis. Ich erfuhr, dass sogar Kunden aufgrund schlechter Bedienkonzepte Kritik äußerten. Die Bedienbarkeit einiger Teile der Software war nicht gut. Es mag hart klingen, aber ich fühlte mich bestätigt. Software wird an vielen Stellen einfach am Kunden vorbei entwickelt. Das Wichtigste war immer die tadellose Funktionalität der Software. Der intuitive Teil, das Benutzererlebnis kommt zu kurz.

 

Studium, Zertifikate & Kurse

Ich machte Nägel mit Köpfen und suchte mir einen 2-Tageskurs  um die Grundlagen UX und Usability zu erlernen. Glücklicherweise wurde der Kurs als Fortbildungsmaßnahme gewährt.

In dem Kurs, der in einem hauseigenen Zertifikat mündete, wurde mir noch viel klarer, dass unsere und meine Art zu arbeiten, der falsche Ansatz ist. UX ist kein böhmisches Dorf sondern essentiell für Software. Der Kurs hatte neben viel Theorie (ISO-Normen, Begrifflichkeiten) auch viele gute Alltagsbeispiele zu bieten. Gleich nach dem Kurs kontaktierte ich einen ehemaligen Schulkollegen der bei Google in München arbeitet, wie deren Herangehensweise an dieses Thema ist. Ich war schockiert, wie wichtig benutzerorientierte Software in den großen Softwarehäusern doch ist und dass das Thema seit ein paar Jahren einen extremen Aufwind erfahren hat. Sogar in der Automobilindustrie arbeiten Heerscharen von Inhouse-UX oder Agentur-UX`ler.

Für mich war nun klar: ich möchte UX und Usability von Grund auf erlernen um das fehlende Puzzlestück in der Softwareentwicklung zu finden. Dazu bewarb ich mich auf eigene Kosten um einen Studienplatz an der Technischen Hochschule Deggendorf , um dort fundiert das Hochschulzertifikat als Usability-Engineer zu erlangen. Ich wurde aufgenommen und habe nun noch ein paar Monate Vorbereitungszeit, die ich mit dem Lesen von Blogs und Beiträgen, dem Besuch von UX-Stammtischen und der Lektüre verschiedenster Bücher überbrücke. Das Studium geht 9 Monate und läuft nebenberuflich. Das wird eine schwere Aufgabe, aber ich empfinde das Thema UX/Usability als so schwerwiegend, dass ich mich als Softwareentwickler dazu regelrecht verpflichtet fühle besser zu verstehen wie mein Kunde denkt. Zeitgleich bereite ich mich auf die Basis-Zertifizierung UXQB® Certified Professional for Usability and User Experience – Foundation Level (CPUX-F) vor.

Ich werde über die Zeit an der Technischen Hochschule und den Zertifizierungen zum CPUX-F begleitend berichten.

Das breite Feld der Usability (ISO 9241-11 ) und der UX (ISO 9241-210 ) hat neben reinen Oberflächen so viel mehr zu bieten. Wir sprechen hier von einer Menge Kognitionspsychologie des Benutzers über die Bedienung von modernen Navigationssystemen in Fahrzeugen bis hin zur AI (artificial intelligence, Künstlichen Intelligenz).

Nach mehreren Monaten Selbststudium und der Erfahrung als Entwickler kann ich die eingangs gestellte Frage jedoch schon jetzt klar beantworten.

Softwareentwickler wissen nicht was der User will und sollten eigentlich keine Designentscheidungen treffen

Ausnahmen bestätigen natürlich wie immer die Regel.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.