Goulasz

Weiß gar nicht, ob es der Thread hier oder ein anderer war, aber @Nopp hat recht.
Zum einen ist es auf Vollzeit gerechnet insgesamt mehr Geld, zum anderen bin ich aber mit dem Initiieren eines Startup Weekends in Kassel und der Gründung einer Sudbury-Schule (ebenfalls in Kassel) ganz gut ausgelastet. Da meine Frau Montags auch immer frei hat ist MiDoFr für uns perfekt für mehr Zeit miteinander und für mich Dienstags mehr Zeit für Projekte, Gemüseanbau, etc.
Ganz davon abgesehen habe ich extrem Bock auf das Aufgabenfeld. Der Chef hätte mich auch direkt in Vollzeit genommen, aber das überlege ich mir nächstes Jahr dann.  
Gruß, Goulasz  

Update weil Jobwechsel zum 01.09.

Weiß gar nicht, ob es der Thread hier oder ein anderer war, aber @Nopp hat recht.
Zum einen ist es auf Vollzeit gerechnet insgesamt mehr Geld, zum anderen bin ich aber mit dem Initiieren eines Startup Weekends in Kassel und der Gründung einer Sudbury-Schule (ebenfalls in Kassel) ganz gut ausgelastet. Da meine Frau Montags auch immer frei hat ist MiDoFr für uns perfekt für mehr Zeit miteinander und für mich Dienstags mehr Zeit für Projekte, Gemüseanbau, etc.
Ganz davon abgesehen habe ich extrem Bock auf das Aufgabenfeld. Der Chef hätte mich auch direkt in Vollzeit genommen, aber das überlege ich mir nächstes Jahr dann.  
Gruß, Goulasz  

Hallo in die Runde!
Spannend finde ich da ja, dass meistens die Personalabteilungen die Zeugnisse erstellen. 
Die haben oft abseits der arbeitsvertraglich festgehaltenen Tätigkeiten (die sich, man möchte es kaum glauben, im Laufe eines Arbeitsverhältnisses tatsächlich mal ändern sollen) wenig bis gar keine Ahnung, was der Mitarbeitende eigentlich tatsächlich an Tätigkeiten im Unternehmen ausgeführt hat, geschweige denn in welcher Qualität dies geschah.
Grade in größeren Unternehmen kommt da noch hinzu, dass oft selbst die direkten disziplinarischen (laut Organigramm) Vorgesetzten keinen direkten Kontakt zu den Mitarbeitenden haben.
Die einzigen, die einen wirklich relevanten Input für so ein Zeugnis geben könnten, wären Kollegen im Peer Feedback. Aber auch hier gilt: Da das Arbeitszeugnis "wohlwollend formuliert und berufsfördernd" sein muss, kann da eigentlich nur schwammiger Mist bei rauskommen, selbst wenn man die stets zu unserer vollsten Genervtheit ausgelutschten Phrasen kennt, deren Vermissen wir übrigens nicht Bedauern würden und ihnen auch nicht viel Erfolg auf dem weiteren Berufsweg wünschen.  
Gruß, Goulasz  

Guten Morgen!
Meine Frau, unsere 3 Kinder (♂ 5, ♀3, ♀3) und ich wohnen in einer Kleinstadt in der Nordspitze Hessens(~16.000 Einwohner) in einem freistehenden 4-Zimmer Haus mit 105m² Wohnfläche und ~400m² Grundstück.
Die Kosten teilen sich wie folgt auf:
700€ Kaltmiete 130€ NK 170€ Strom&Gas Für die Region ist das ein leicht über Durchschnitt liegender Preis, aber allgemein sind freistehende EFH zur Miete hier eine Rarität. Und nicht zuletzt wegen der Kinder war ein Stück eigener Garten mitsamt "Lärm-Komfortzone" doch ein MUSS-Kriterium.
Wohneigentum war vor einem Jahr noch das absolute Non-Plus-Ultra bei uns (da in der Region auch finanzierbar, die Grundstückspreise liegen laut Geoportal Hessen zwischen 40€ und 100€ pro Quadratmeter).
Mittlerweile wollen wir uns aber nicht mehr so sehr an etwas so teures binden und überlegen nach Alternativen, z.B. in Wohngemeinschaften mit gemeinsamem Ackerbau, Tiny Houses, etc.
Gruß, Goulasz  

Also quasi keinerlei Vorkenntnisse. Aber das muss auch nicht sein. Dafür ist eine Ausbildung/Betriebliche Umschulung ja da. Immerhin sind dir dadurch die Werkzeuge schon einmal bekannt.
Ich würde mich an deiner Stelle direkt an Firmen wenden, welche in dem Bereich Tätig sind, indem du später arbeiten möchtest.  Ich vermute jetzt einfach mal, es ist im Webbereich. Da bieten sich Werbeagenturen, Internetagenturen und Unternehmen die selbständig höherwertige Webseiten betreiben an.
Um dir eine Menge Arbeit und Frust zu ersparen, würd ich bei deinen Bewerbungen in 2 Schritten vorgehen. Im 1. Schritt würde ich einen kleinen formlosen Text verfassen, der sich nur darum dreht die betreffenden Unternehmen über die Förderung zu informieren. Wenn Interesse besteht, würdest du ihnen umgehend eine vollständige Bewerbung zukommen lassen.  An diese Anfrage würde ich dann nur den Flyer anhängen.
So sonderst du bereits alle Unternehmen aus, die an einer solchen Umschulung kein Interesse zu haben. Da du hier, bis auf deinen Namen, keine Informationen über dich Preis gibst, liegen die Absagen (oder Unternehmen, welche diese Anfrage einfach ignorieren) wirklich nur der Tatsache geschuldet, dass sie keine solche Stelle anbieten. Und du ersparst es dir etliche Bewerbungen zu schreiben, die bereits im Vorfeld zum Scheitern verurteilt waren.
Im 2. Schritt verfasst du dann persönliche und auf das Unternehmen zurechtgeschnittene Bewerbungen. Hier musst du dann die Förderung nicht mehr erklären, sondern nur noch erwähnen. Das spart dir viel Platz für ein persönliches Anschreiben, indem du dich mehr das Wesentliche konzentrieren kannst.
Ich habe z.B. so nach meinen Praktikumsplatz gesucht und dadurch letztendlich nur 1 Bewerbung schreiben müssen um eine Zusage zu erhalten.

Lass es mich so ausdrücken: auch 70k rechtfertigen nicht Verstösse gegen gesetzliche Vorgaben.
Wenn die IT so business critical ist muss Bereitschaft geregelt sein.

Hallo Goulasz,
vielen Dank auch dir für die netten Worte! Ich sehe keinen großen Grund, mich hier für etwas zu rechtfertigen, wovon andere offensichtlich mehr Ahnung haben, weswegen auch immer das der Fall sein mag. Immerhin suche ich hier nach Hilfe, und ohne ein gewisses Mindestmaß an Einsichtsbereitschaft wäre ich damit sicher nicht erfolgreich!
Viele Grüße,
Niklas

Ich würde mir bei dieser Projektbeschreibung erstmal die Frage stellen, warum die 7324. "Projektverwaltung" selbst programmiert werden muss und das Unternehmen nicht einfach ein Standardprodukt kauft.
Und das sollte auch in der Projektdokumentation sehr gut begründet werden. Denn wirtschaftlich ist das wahrscheinlich nicht

Nach längerem Überlegen und intensiver Beratung durch @Sullidor habe ich mich auch dazu entschieden, mir eine Smartwatch, konkret, eine Gear 2 Classic anzuschaffen.
Abgesehen davon, dass ich meine Termine damit irgendwie viel besser auf die Kette kriege als mit "Papierkalender und Stift" oder "Nur Smartphone" nutzt mir die Schlafaufzeichnung (ich trage sie Nachts) relativ viel, um mein Schlafverhalten rückwirkend zu analysieren und mein "ins Bett gehen" so anzupassen, dass ich zu dem Zeitpunkt, zu dem meine Kinder meistens unruhig werden, schon die erste Tiefschlafphase hinter mir habe.
Davon abgesehen hat mich dieses Watchface hier einfach überzeugt.

Nach längerem Überlegen und intensiver Beratung durch @Sullidor habe ich mich auch dazu entschieden, mir eine Smartwatch, konkret, eine Gear 2 Classic anzuschaffen.
Abgesehen davon, dass ich meine Termine damit irgendwie viel besser auf die Kette kriege als mit "Papierkalender und Stift" oder "Nur Smartphone" nutzt mir die Schlafaufzeichnung (ich trage sie Nachts) relativ viel, um mein Schlafverhalten rückwirkend zu analysieren und mein "ins Bett gehen" so anzupassen, dass ich zu dem Zeitpunkt, zu dem meine Kinder meistens unruhig werden, schon die erste Tiefschlafphase hinter mir habe.
Davon abgesehen hat mich dieses Watchface hier einfach überzeugt.

Muss ein echter Post sein, so eine Vita denkt sich doch keiner aus...oder?

Das krasse an diesem Beispiel ist, dass solche Sachen schon in so "Einsteiger"-Büchern wie "Don't Make Me Think" ausdrücklich behandelt werden. Hatte mir das Buch gekauft um Ideen zu sammeln wie ich meine Frontends ein bisschen freundlicher gestalten kann, das Feedback seit dem ist unglaublich^^
Wenn man die kleinen Dinge, die kaum Aufwand erfordern, ein bisschen anders umsetzt wird das Produkt gleich so viel verständlicher.
Jedenfalls bin dafür, dass du noch ein paar Blog-Einträge schreibst

Hallo @StefanE
Da hast du aber recht, genau sowas ist unter anderem der Job eines Usability Engineers. Eine der wichtigsten Aufgaben ist es, vor der Entwicklung eines interaktiven Systems Benutzer in ihrem Benutzungskontext zu beobachten und Nutzungskontextbeschreibungen zu erstellen.
Ich hole mal etwas aus und gebe Beispiele dazu.
---
(Fiktives) Beispiel 1: Eine Hersteller medizinischer Geräte konzipiert ein neues Monitoring-System für OP-Säle. Die Maschine wird am Reißbrett entworfen, ist mit modernster Technologie ausgestattet. Der Herstellter beschäftigt sich nicht mit Usability und geht ohne große Praxistests durchzuführen in die Produktion. Nach dem Ausrollen wird festgestellt, dass der kapazitive Touchscreen des Geräts nicht mit den im OP üblicherweise verwendeten Handschuhen nutzbar ist und ein resistiver Touchscreen hätte verwendet werden müssen.
Die Firma geht pleite.
(Fiktives) Beispiel 2: Eine Firma entwirft eine neue Wecker-App. Die Firma beobachtet und interviewt Nutzer, die üblicherweise Wecker benutzen und stellen fest, dass neben dem pünktlichen Signalisieren der Weckzeit häufig die Funktionalität gewünscht wird, anstelle der "aktuellen Zeit" und der "Weckzeit" die "Restzeit bis zum Wecksignal" ausgegeben wird. So könnte man beim nächtlichen Aufwachen ohne groß rechnen zu müssen, wonach man erst mal wach ist, erkennen, wie lange noch "Zeit" ist. Das folgende Erfordernis wird identifiziert:
"Der Benutzer muss wissen, wie viel Zeit er noch bis zum Wecksignal hat, um entscheiden zu können, ob er sich noch einmal hinlegt oder nicht."
Die App wird häufig genutzt und das Unternehmen wird von einem Smartphonehersteller aufgekauft. Die Funktionalität geht in das Betriebssystem des Telefons über.
---
Ihr wärt überrascht, wie viele Hersteller es gibt, die aufgrund ihrer Größe und Expertise eigentlich genau wissen müssten, worauf sie in Sachen Usability achten müssten, es dennoch nicht tun, und damit bares Geld und/oder Reputation einbüßen. Ein Beispiel aus der echten Welt. 
"Die Funktionssuche in Microsoft Office 2016-Produkten"
Eigentlich ein gutes Feature. Man gibt dort Dinge ein, z.B. "Drucken" und erhält dann eine Liste aller Funktionen, die mit dem Thema "Drucken" zu tun haben. Wird aber selten genutzt oder ist gar nicht bekannt. Wie kommt das?

Das Steuerelement dazu verbirgt sich hinter "Was möchten Sie tun?". Das Element, das eigentlich ein Suchfeld ist, ist nicht unmittelbar als solches erkennbar. Das Dialogprinzip der "Erwartungskonformität" ist verletzt. Ebenso hat das Element keinen "Aufforderungscharakter". Es ist nicht unmittelbar erkennbar, das hier eine Eingabe möglich ist. Zuletzt ist das Dialogprinzip der "Selbstbeschreibungsfähigkeit" verletzt, da nicht klar ist, was man mit dem Element eigentlich tun kann.
Sehen wir uns meinen eben dazu im besten Mockup-Tool der Welt (MSPAINT FUCK YEAH!) erstellen Gegenentwurf an:

Das Element sieht aus wie ein Suchfeld. Es ist weiß, enthält eine Lupe, einen Textcursor und mein erster Textentwurf aus der Hüfte "Funktionssuche" ist zumindest für mich aussagekräftiger als "Was möchten Sie tun?". Der nächste Schritt nun wäre, mit mehreren Entwürfen des Designs und des Textes Usability-Tests durchzuführen und die größte Akzeptanz zu ermitteln. Papier oder Screenshot reicht hier in der Regel schon. 5 Nutzer befragen, was sie sich unter dem Element vorstellen und dann ggfs. basierend auf dem Feedback anpassen. Je mehr, desto besser.
Ich hoffe, es ist etwas klarer geworden, worum es hier geht.
Gruß und einen guten Arbeitstag euch, Goulasz  
P.S.: Wer sich damit und besonders mit "Do it yourself Usability Testing" (also ohne teuren Profi, sondern mit den Mitteln, die man in der Firma zur Verfügung hat) auseinandersetzen möchte, dem sei das folgende Buch wärmstens ans Herz gelegt. Und bitte, bitte in Englisch bestellen. Die deutsche Übersetzung ist imho nicht zu empfehlen.
Don't Make Me Think: A Common Sense Approach to Web Usability (Amazon, kein Affiliate-Link)

Hallo @StefanE
Da hast du aber recht, genau sowas ist unter anderem der Job eines Usability Engineers. Eine der wichtigsten Aufgaben ist es, vor der Entwicklung eines interaktiven Systems Benutzer in ihrem Benutzungskontext zu beobachten und Nutzungskontextbeschreibungen zu erstellen.
Ich hole mal etwas aus und gebe Beispiele dazu.
---
(Fiktives) Beispiel 1: Eine Hersteller medizinischer Geräte konzipiert ein neues Monitoring-System für OP-Säle. Die Maschine wird am Reißbrett entworfen, ist mit modernster Technologie ausgestattet. Der Herstellter beschäftigt sich nicht mit Usability und geht ohne große Praxistests durchzuführen in die Produktion. Nach dem Ausrollen wird festgestellt, dass der kapazitive Touchscreen des Geräts nicht mit den im OP üblicherweise verwendeten Handschuhen nutzbar ist und ein resistiver Touchscreen hätte verwendet werden müssen.
Die Firma geht pleite.
(Fiktives) Beispiel 2: Eine Firma entwirft eine neue Wecker-App. Die Firma beobachtet und interviewt Nutzer, die üblicherweise Wecker benutzen und stellen fest, dass neben dem pünktlichen Signalisieren der Weckzeit häufig die Funktionalität gewünscht wird, anstelle der "aktuellen Zeit" und der "Weckzeit" die "Restzeit bis zum Wecksignal" ausgegeben wird. So könnte man beim nächtlichen Aufwachen ohne groß rechnen zu müssen, wonach man erst mal wach ist, erkennen, wie lange noch "Zeit" ist. Das folgende Erfordernis wird identifiziert:
"Der Benutzer muss wissen, wie viel Zeit er noch bis zum Wecksignal hat, um entscheiden zu können, ob er sich noch einmal hinlegt oder nicht."
Die App wird häufig genutzt und das Unternehmen wird von einem Smartphonehersteller aufgekauft. Die Funktionalität geht in das Betriebssystem des Telefons über.
---
Ihr wärt überrascht, wie viele Hersteller es gibt, die aufgrund ihrer Größe und Expertise eigentlich genau wissen müssten, worauf sie in Sachen Usability achten müssten, es dennoch nicht tun, und damit bares Geld und/oder Reputation einbüßen. Ein Beispiel aus der echten Welt. 
"Die Funktionssuche in Microsoft Office 2016-Produkten"
Eigentlich ein gutes Feature. Man gibt dort Dinge ein, z.B. "Drucken" und erhält dann eine Liste aller Funktionen, die mit dem Thema "Drucken" zu tun haben. Wird aber selten genutzt oder ist gar nicht bekannt. Wie kommt das?

Das Steuerelement dazu verbirgt sich hinter "Was möchten Sie tun?". Das Element, das eigentlich ein Suchfeld ist, ist nicht unmittelbar als solches erkennbar. Das Dialogprinzip der "Erwartungskonformität" ist verletzt. Ebenso hat das Element keinen "Aufforderungscharakter". Es ist nicht unmittelbar erkennbar, das hier eine Eingabe möglich ist. Zuletzt ist das Dialogprinzip der "Selbstbeschreibungsfähigkeit" verletzt, da nicht klar ist, was man mit dem Element eigentlich tun kann.
Sehen wir uns meinen eben dazu im besten Mockup-Tool der Welt (MSPAINT FUCK YEAH!) erstellen Gegenentwurf an:

Das Element sieht aus wie ein Suchfeld. Es ist weiß, enthält eine Lupe, einen Textcursor und mein erster Textentwurf aus der Hüfte "Funktionssuche" ist zumindest für mich aussagekräftiger als "Was möchten Sie tun?". Der nächste Schritt nun wäre, mit mehreren Entwürfen des Designs und des Textes Usability-Tests durchzuführen und die größte Akzeptanz zu ermitteln. Papier oder Screenshot reicht hier in der Regel schon. 5 Nutzer befragen, was sie sich unter dem Element vorstellen und dann ggfs. basierend auf dem Feedback anpassen. Je mehr, desto besser.
Ich hoffe, es ist etwas klarer geworden, worum es hier geht.
Gruß und einen guten Arbeitstag euch, Goulasz  
P.S.: Wer sich damit und besonders mit "Do it yourself Usability Testing" (also ohne teuren Profi, sondern mit den Mitteln, die man in der Firma zur Verfügung hat) auseinandersetzen möchte, dem sei das folgende Buch wärmstens ans Herz gelegt. Und bitte, bitte in Englisch bestellen. Die deutsche Übersetzung ist imho nicht zu empfehlen.
Don't Make Me Think: A Common Sense Approach to Web Usability (Amazon, kein Affiliate-Link)

Hallo @Crash2001!
Basierend auf der ISO-9241 und diversen Fachpublikationen zur Gestaltung interaktiver Systeme ergeben sich folgende Rollen, die ein Usability Professional im Laufe des Prozesses zur Gestaltung gebrauchstauglicher Systeme einnehmen kann:
TL;DR:
Usability Engineer: Managt den UX Prozess User Requirements Engineer: Beschreibt Nutzungskontext und Nutzungsanforderungen Usability-Tester: Führt Usability-Tests aus Informationsarchitekt: Kreiert die Informationsarchtitektur und die Navigationsstruktur Interaktionsdesigner: Definiert die Interaktion zwischen Mensch und System User Interface Designer: Implementiert das Benutzererlebnis Mittelfassung:
Usability Engineer: Betreut in einer Querschnittsfunktion den menschzentrierten Gestaltungsprozess, quasi der "SCRUM Master" des Prozesses. Idealerweise hat er bereits Erfahrung in der Ausfüllung der anderen Rollen. Mindestens jedoch User Requirements Engineer und Usability Tester. User Requirements Engineer: Identifiziert und beschreibt den Nutzungskontext, leitet daraus Erfordernisse und Nutzungsanforderungen ab. Er priorisiert die Nutzungsanforderungen, damit die Erfordernisse erfüllt werden können Usability-Tester: Evaluiert die Benutzungsschnittstellen und erstellt für die verschiedenen Stadien im Gestaltungsprozess die entsprechenden UX Lieferungen, z.B. einen Usability-Testbericht, quantitative/qualitative Umfragen und Ähnliches Informationsarchitekt: Er kreiert und organisiert die Struktur für das effiziente Auffinden von Informationen im interaktiven System durch den Benutzer Interaktionsdesigner: Er konzipiert und definiert die Interaktion zwischen Mensch und interaktivem System auf Basis der Nutzungsanforderungen und der zu erledigenden Aufgaben. Die für die Erstellung der Interaktion genutzten Szenarien werden gemessen an der Effektivität, Effizienz und dem Grad der Zufriedenstellung im Verlauf der User Experience User Interface Designer: Er implementiert letztendlich das konkrete Benutzererlebnis anhand von Gestaltungsregeln, Styleguides und den Ergebnissen des Informationsarchitekten, des Interaktionsdesigners und des User Requirements Engineers. Langfassung:
Setz dich mit der ISO auseinander und/oder besuch entsprechende Weiterbildungen zu dem Thema, bevor du hier mit Begriffen wie "heiße Luft" um dich wirfst. Nur weil es Menschen gibt, die keine Ahnung haben und Begriffe "buzzwordig" verwenden, trifft das nicht auf alle zu. 
Gruß, Goulasz  
P.S.: Zum besseren Verständnis hier der Prozess zur Gestaltung interaktiver Systeme. Wer Anleihen an William Edwards Deming erkennt, darf sie behalten:

 

Hallo @Crash2001!
Für mich klingt das abwertend. Aber sei's drum, ich will mal nicht so sein.   
UX heißt hier übrigens "User Experience". "User Experience Lieferungen" sind hier also die Ergebnisse der einzelnen Teilprozesse.
Als Usability Engineer bin ich Schnittstelle zwischen den Projektverantwortlichen auf Kunden- bzw. Anwenderseite und den Umsetzenden auf der Auftragnehmerseite. Zum einen unterstütze ich alle anderen Rollen bei ihrer Arbeit, zum anderen sehe ich als Verantwortlicher zu, dass alle Rollen die Mittel zur Verfügung haben, die sie zur Erfüllung ihrer Tätigkeiten benötigen.
Ich organisiere also für den User Requirements Engineer Interviewpartner und schaffe Situationen, in denen er Anwender beim Lösen des  Problems, bei dem das Produkt, das entwickelt werden soll, helfen soll, beobachten kann. Ich kümmere mich um die Erstellung von Listen relevanter Zielgruppen für die Rekrutierung von Usability Testenden, rekrutiere diese ggfs. direkt oder gebe diese Informationen an eine Agentur weiter. Ich diene dem Informationsarchitekten und dem Interaktionsdesigner sowie dem User Interface Designer als ständiger Sparrings- und Reviewpartner und gleiche als Gesamtverantwortlicher zusätzlich die Ergebnisse mit den Nutzungsanforderungen ab.  So gesehen bin ich in der Rolle des "Usability Engineers" eine Art Projektmanager für den gesamten Teil eines Projekts, in dem es in Gesamtverantwortung um "Usability" geht.
Schwammig ist das nicht unbedingt. Zumindest nicht nach meiner Sicht.
Das "Hochgestochene", das du meinst, rührt daher, dass es, wenn man die formalen Inhalte der ISO kennt, eine sehr trennscharfe und spezifische Sprache mit spezifischen Begriffen gibt, damit sich die verschiedenen Usability Professionals eben nicht darüber streiten müssen, ob ein Kunde jetzt etwas "will" oder "braucht", sondern dass klar zwischen Erfordernissen und Anforderungen unterschieden wird.
Am Agile Monday Kassel habe ich dazu einen Vortrag gehalten. Die begleitenden Slides dazu findest du hier:
https://de.slideshare.net/secret/lgsDzRLiNVREp7
Eine Videoaufnahme, auf der man die Erläuterungen dazu findet, existiert leider nicht. Würde ich das alles so im Detail erläutern, müsste ich dafür aber vermutlich schon fast eine Rechnung schreiben. 
Gruß, Goulasz  

Hallo @Crash2001!
Für mich klingt das abwertend. Aber sei's drum, ich will mal nicht so sein.   
UX heißt hier übrigens "User Experience". "User Experience Lieferungen" sind hier also die Ergebnisse der einzelnen Teilprozesse.
Als Usability Engineer bin ich Schnittstelle zwischen den Projektverantwortlichen auf Kunden- bzw. Anwenderseite und den Umsetzenden auf der Auftragnehmerseite. Zum einen unterstütze ich alle anderen Rollen bei ihrer Arbeit, zum anderen sehe ich als Verantwortlicher zu, dass alle Rollen die Mittel zur Verfügung haben, die sie zur Erfüllung ihrer Tätigkeiten benötigen.
Ich organisiere also für den User Requirements Engineer Interviewpartner und schaffe Situationen, in denen er Anwender beim Lösen des  Problems, bei dem das Produkt, das entwickelt werden soll, helfen soll, beobachten kann. Ich kümmere mich um die Erstellung von Listen relevanter Zielgruppen für die Rekrutierung von Usability Testenden, rekrutiere diese ggfs. direkt oder gebe diese Informationen an eine Agentur weiter. Ich diene dem Informationsarchitekten und dem Interaktionsdesigner sowie dem User Interface Designer als ständiger Sparrings- und Reviewpartner und gleiche als Gesamtverantwortlicher zusätzlich die Ergebnisse mit den Nutzungsanforderungen ab.  So gesehen bin ich in der Rolle des "Usability Engineers" eine Art Projektmanager für den gesamten Teil eines Projekts, in dem es in Gesamtverantwortung um "Usability" geht.
Schwammig ist das nicht unbedingt. Zumindest nicht nach meiner Sicht.
Das "Hochgestochene", das du meinst, rührt daher, dass es, wenn man die formalen Inhalte der ISO kennt, eine sehr trennscharfe und spezifische Sprache mit spezifischen Begriffen gibt, damit sich die verschiedenen Usability Professionals eben nicht darüber streiten müssen, ob ein Kunde jetzt etwas "will" oder "braucht", sondern dass klar zwischen Erfordernissen und Anforderungen unterschieden wird.
Am Agile Monday Kassel habe ich dazu einen Vortrag gehalten. Die begleitenden Slides dazu findest du hier:
https://de.slideshare.net/secret/lgsDzRLiNVREp7
Eine Videoaufnahme, auf der man die Erläuterungen dazu findet, existiert leider nicht. Würde ich das alles so im Detail erläutern, müsste ich dafür aber vermutlich schon fast eine Rechnung schreiben. 
Gruß, Goulasz  

Hallo @Crash2001!
Für mich klingt das abwertend. Aber sei's drum, ich will mal nicht so sein.   
UX heißt hier übrigens "User Experience". "User Experience Lieferungen" sind hier also die Ergebnisse der einzelnen Teilprozesse.
Als Usability Engineer bin ich Schnittstelle zwischen den Projektverantwortlichen auf Kunden- bzw. Anwenderseite und den Umsetzenden auf der Auftragnehmerseite. Zum einen unterstütze ich alle anderen Rollen bei ihrer Arbeit, zum anderen sehe ich als Verantwortlicher zu, dass alle Rollen die Mittel zur Verfügung haben, die sie zur Erfüllung ihrer Tätigkeiten benötigen.
Ich organisiere also für den User Requirements Engineer Interviewpartner und schaffe Situationen, in denen er Anwender beim Lösen des  Problems, bei dem das Produkt, das entwickelt werden soll, helfen soll, beobachten kann. Ich kümmere mich um die Erstellung von Listen relevanter Zielgruppen für die Rekrutierung von Usability Testenden, rekrutiere diese ggfs. direkt oder gebe diese Informationen an eine Agentur weiter. Ich diene dem Informationsarchitekten und dem Interaktionsdesigner sowie dem User Interface Designer als ständiger Sparrings- und Reviewpartner und gleiche als Gesamtverantwortlicher zusätzlich die Ergebnisse mit den Nutzungsanforderungen ab.  So gesehen bin ich in der Rolle des "Usability Engineers" eine Art Projektmanager für den gesamten Teil eines Projekts, in dem es in Gesamtverantwortung um "Usability" geht.
Schwammig ist das nicht unbedingt. Zumindest nicht nach meiner Sicht.
Das "Hochgestochene", das du meinst, rührt daher, dass es, wenn man die formalen Inhalte der ISO kennt, eine sehr trennscharfe und spezifische Sprache mit spezifischen Begriffen gibt, damit sich die verschiedenen Usability Professionals eben nicht darüber streiten müssen, ob ein Kunde jetzt etwas "will" oder "braucht", sondern dass klar zwischen Erfordernissen und Anforderungen unterschieden wird.
Am Agile Monday Kassel habe ich dazu einen Vortrag gehalten. Die begleitenden Slides dazu findest du hier:
https://de.slideshare.net/secret/lgsDzRLiNVREp7
Eine Videoaufnahme, auf der man die Erläuterungen dazu findet, existiert leider nicht. Würde ich das alles so im Detail erläutern, müsste ich dafür aber vermutlich schon fast eine Rechnung schreiben. 
Gruß, Goulasz  

Hallo @Crash2001!
Für mich klingt das abwertend. Aber sei's drum, ich will mal nicht so sein.   
UX heißt hier übrigens "User Experience". "User Experience Lieferungen" sind hier also die Ergebnisse der einzelnen Teilprozesse.
Als Usability Engineer bin ich Schnittstelle zwischen den Projektverantwortlichen auf Kunden- bzw. Anwenderseite und den Umsetzenden auf der Auftragnehmerseite. Zum einen unterstütze ich alle anderen Rollen bei ihrer Arbeit, zum anderen sehe ich als Verantwortlicher zu, dass alle Rollen die Mittel zur Verfügung haben, die sie zur Erfüllung ihrer Tätigkeiten benötigen.
Ich organisiere also für den User Requirements Engineer Interviewpartner und schaffe Situationen, in denen er Anwender beim Lösen des  Problems, bei dem das Produkt, das entwickelt werden soll, helfen soll, beobachten kann. Ich kümmere mich um die Erstellung von Listen relevanter Zielgruppen für die Rekrutierung von Usability Testenden, rekrutiere diese ggfs. direkt oder gebe diese Informationen an eine Agentur weiter. Ich diene dem Informationsarchitekten und dem Interaktionsdesigner sowie dem User Interface Designer als ständiger Sparrings- und Reviewpartner und gleiche als Gesamtverantwortlicher zusätzlich die Ergebnisse mit den Nutzungsanforderungen ab.  So gesehen bin ich in der Rolle des "Usability Engineers" eine Art Projektmanager für den gesamten Teil eines Projekts, in dem es in Gesamtverantwortung um "Usability" geht.
Schwammig ist das nicht unbedingt. Zumindest nicht nach meiner Sicht.
Das "Hochgestochene", das du meinst, rührt daher, dass es, wenn man die formalen Inhalte der ISO kennt, eine sehr trennscharfe und spezifische Sprache mit spezifischen Begriffen gibt, damit sich die verschiedenen Usability Professionals eben nicht darüber streiten müssen, ob ein Kunde jetzt etwas "will" oder "braucht", sondern dass klar zwischen Erfordernissen und Anforderungen unterschieden wird.
Am Agile Monday Kassel habe ich dazu einen Vortrag gehalten. Die begleitenden Slides dazu findest du hier:
https://de.slideshare.net/secret/lgsDzRLiNVREp7
Eine Videoaufnahme, auf der man die Erläuterungen dazu findet, existiert leider nicht. Würde ich das alles so im Detail erläutern, müsste ich dafür aber vermutlich schon fast eine Rechnung schreiben. 
Gruß, Goulasz  

Hallo @Crash2001!
Für mich klingt das abwertend. Aber sei's drum, ich will mal nicht so sein.   
UX heißt hier übrigens "User Experience". "User Experience Lieferungen" sind hier also die Ergebnisse der einzelnen Teilprozesse.
Als Usability Engineer bin ich Schnittstelle zwischen den Projektverantwortlichen auf Kunden- bzw. Anwenderseite und den Umsetzenden auf der Auftragnehmerseite. Zum einen unterstütze ich alle anderen Rollen bei ihrer Arbeit, zum anderen sehe ich als Verantwortlicher zu, dass alle Rollen die Mittel zur Verfügung haben, die sie zur Erfüllung ihrer Tätigkeiten benötigen.
Ich organisiere also für den User Requirements Engineer Interviewpartner und schaffe Situationen, in denen er Anwender beim Lösen des  Problems, bei dem das Produkt, das entwickelt werden soll, helfen soll, beobachten kann. Ich kümmere mich um die Erstellung von Listen relevanter Zielgruppen für die Rekrutierung von Usability Testenden, rekrutiere diese ggfs. direkt oder gebe diese Informationen an eine Agentur weiter. Ich diene dem Informationsarchitekten und dem Interaktionsdesigner sowie dem User Interface Designer als ständiger Sparrings- und Reviewpartner und gleiche als Gesamtverantwortlicher zusätzlich die Ergebnisse mit den Nutzungsanforderungen ab.  So gesehen bin ich in der Rolle des "Usability Engineers" eine Art Projektmanager für den gesamten Teil eines Projekts, in dem es in Gesamtverantwortung um "Usability" geht.
Schwammig ist das nicht unbedingt. Zumindest nicht nach meiner Sicht.
Das "Hochgestochene", das du meinst, rührt daher, dass es, wenn man die formalen Inhalte der ISO kennt, eine sehr trennscharfe und spezifische Sprache mit spezifischen Begriffen gibt, damit sich die verschiedenen Usability Professionals eben nicht darüber streiten müssen, ob ein Kunde jetzt etwas "will" oder "braucht", sondern dass klar zwischen Erfordernissen und Anforderungen unterschieden wird.
Am Agile Monday Kassel habe ich dazu einen Vortrag gehalten. Die begleitenden Slides dazu findest du hier:
https://de.slideshare.net/secret/lgsDzRLiNVREp7
Eine Videoaufnahme, auf der man die Erläuterungen dazu findet, existiert leider nicht. Würde ich das alles so im Detail erläutern, müsste ich dafür aber vermutlich schon fast eine Rechnung schreiben. 
Gruß, Goulasz  

Hallo @Crash2001!
Basierend auf der ISO-9241 und diversen Fachpublikationen zur Gestaltung interaktiver Systeme ergeben sich folgende Rollen, die ein Usability Professional im Laufe des Prozesses zur Gestaltung gebrauchstauglicher Systeme einnehmen kann:
TL;DR:
Usability Engineer: Managt den UX Prozess User Requirements Engineer: Beschreibt Nutzungskontext und Nutzungsanforderungen Usability-Tester: Führt Usability-Tests aus Informationsarchitekt: Kreiert die Informationsarchtitektur und die Navigationsstruktur Interaktionsdesigner: Definiert die Interaktion zwischen Mensch und System User Interface Designer: Implementiert das Benutzererlebnis Mittelfassung:
Usability Engineer: Betreut in einer Querschnittsfunktion den menschzentrierten Gestaltungsprozess, quasi der "SCRUM Master" des Prozesses. Idealerweise hat er bereits Erfahrung in der Ausfüllung der anderen Rollen. Mindestens jedoch User Requirements Engineer und Usability Tester. User Requirements Engineer: Identifiziert und beschreibt den Nutzungskontext, leitet daraus Erfordernisse und Nutzungsanforderungen ab. Er priorisiert die Nutzungsanforderungen, damit die Erfordernisse erfüllt werden können Usability-Tester: Evaluiert die Benutzungsschnittstellen und erstellt für die verschiedenen Stadien im Gestaltungsprozess die entsprechenden UX Lieferungen, z.B. einen Usability-Testbericht, quantitative/qualitative Umfragen und Ähnliches Informationsarchitekt: Er kreiert und organisiert die Struktur für das effiziente Auffinden von Informationen im interaktiven System durch den Benutzer Interaktionsdesigner: Er konzipiert und definiert die Interaktion zwischen Mensch und interaktivem System auf Basis der Nutzungsanforderungen und der zu erledigenden Aufgaben. Die für die Erstellung der Interaktion genutzten Szenarien werden gemessen an der Effektivität, Effizienz und dem Grad der Zufriedenstellung im Verlauf der User Experience User Interface Designer: Er implementiert letztendlich das konkrete Benutzererlebnis anhand von Gestaltungsregeln, Styleguides und den Ergebnissen des Informationsarchitekten, des Interaktionsdesigners und des User Requirements Engineers. Langfassung:
Setz dich mit der ISO auseinander und/oder besuch entsprechende Weiterbildungen zu dem Thema, bevor du hier mit Begriffen wie "heiße Luft" um dich wirfst. Nur weil es Menschen gibt, die keine Ahnung haben und Begriffe "buzzwordig" verwenden, trifft das nicht auf alle zu. 
Gruß, Goulasz  
P.S.: Zum besseren Verständnis hier der Prozess zur Gestaltung interaktiver Systeme. Wer Anleihen an William Edwards Deming erkennt, darf sie behalten:

 

Die Gestaltung interaktiver Systeme ist sicherlich nicht mein Fachgebiet.
Was ich aber sicher sagen kann ist, dass ich viele Anwendungen, Tools kennengelernt die für mich eine grauenvolle Usibility hatten. Beispielsweise genannt sei der HP Service Manager, ein hochpreisiges ITSM Tool, das es schaffte auch unter mit hohen Screen-Auflösungen mehrere Seiten srollen zu müssen um an der entsprechenden Stelle ein Aufklappmenu betätigen zu müssen, damit die relevante Incident Information ausfindig gemacht werden konnte. Grauenvoll!
Ohne mich näher mit der Thematik beschäftigt zu haben, stelle ich mir vor das ein Usability Engineer so etwas verhindern kann. Wenn das so ist, gebt dem Mann mehr Geld :).

Hallo @Crash2001!
Basierend auf der ISO-9241 und diversen Fachpublikationen zur Gestaltung interaktiver Systeme ergeben sich folgende Rollen, die ein Usability Professional im Laufe des Prozesses zur Gestaltung gebrauchstauglicher Systeme einnehmen kann:
TL;DR:
Usability Engineer: Managt den UX Prozess User Requirements Engineer: Beschreibt Nutzungskontext und Nutzungsanforderungen Usability-Tester: Führt Usability-Tests aus Informationsarchitekt: Kreiert die Informationsarchtitektur und die Navigationsstruktur Interaktionsdesigner: Definiert die Interaktion zwischen Mensch und System User Interface Designer: Implementiert das Benutzererlebnis Mittelfassung:
Usability Engineer: Betreut in einer Querschnittsfunktion den menschzentrierten Gestaltungsprozess, quasi der "SCRUM Master" des Prozesses. Idealerweise hat er bereits Erfahrung in der Ausfüllung der anderen Rollen. Mindestens jedoch User Requirements Engineer und Usability Tester. User Requirements Engineer: Identifiziert und beschreibt den Nutzungskontext, leitet daraus Erfordernisse und Nutzungsanforderungen ab. Er priorisiert die Nutzungsanforderungen, damit die Erfordernisse erfüllt werden können Usability-Tester: Evaluiert die Benutzungsschnittstellen und erstellt für die verschiedenen Stadien im Gestaltungsprozess die entsprechenden UX Lieferungen, z.B. einen Usability-Testbericht, quantitative/qualitative Umfragen und Ähnliches Informationsarchitekt: Er kreiert und organisiert die Struktur für das effiziente Auffinden von Informationen im interaktiven System durch den Benutzer Interaktionsdesigner: Er konzipiert und definiert die Interaktion zwischen Mensch und interaktivem System auf Basis der Nutzungsanforderungen und der zu erledigenden Aufgaben. Die für die Erstellung der Interaktion genutzten Szenarien werden gemessen an der Effektivität, Effizienz und dem Grad der Zufriedenstellung im Verlauf der User Experience User Interface Designer: Er implementiert letztendlich das konkrete Benutzererlebnis anhand von Gestaltungsregeln, Styleguides und den Ergebnissen des Informationsarchitekten, des Interaktionsdesigners und des User Requirements Engineers. Langfassung:
Setz dich mit der ISO auseinander und/oder besuch entsprechende Weiterbildungen zu dem Thema, bevor du hier mit Begriffen wie "heiße Luft" um dich wirfst. Nur weil es Menschen gibt, die keine Ahnung haben und Begriffe "buzzwordig" verwenden, trifft das nicht auf alle zu. 
Gruß, Goulasz  
P.S.: Zum besseren Verständnis hier der Prozess zur Gestaltung interaktiver Systeme. Wer Anleihen an William Edwards Deming erkennt, darf sie behalten:

 

Hallo @Crash2001!
Basierend auf der ISO-9241 und diversen Fachpublikationen zur Gestaltung interaktiver Systeme ergeben sich folgende Rollen, die ein Usability Professional im Laufe des Prozesses zur Gestaltung gebrauchstauglicher Systeme einnehmen kann:
TL;DR:
Usability Engineer: Managt den UX Prozess User Requirements Engineer: Beschreibt Nutzungskontext und Nutzungsanforderungen Usability-Tester: Führt Usability-Tests aus Informationsarchitekt: Kreiert die Informationsarchtitektur und die Navigationsstruktur Interaktionsdesigner: Definiert die Interaktion zwischen Mensch und System User Interface Designer: Implementiert das Benutzererlebnis Mittelfassung:
Usability Engineer: Betreut in einer Querschnittsfunktion den menschzentrierten Gestaltungsprozess, quasi der "SCRUM Master" des Prozesses. Idealerweise hat er bereits Erfahrung in der Ausfüllung der anderen Rollen. Mindestens jedoch User Requirements Engineer und Usability Tester. User Requirements Engineer: Identifiziert und beschreibt den Nutzungskontext, leitet daraus Erfordernisse und Nutzungsanforderungen ab. Er priorisiert die Nutzungsanforderungen, damit die Erfordernisse erfüllt werden können Usability-Tester: Evaluiert die Benutzungsschnittstellen und erstellt für die verschiedenen Stadien im Gestaltungsprozess die entsprechenden UX Lieferungen, z.B. einen Usability-Testbericht, quantitative/qualitative Umfragen und Ähnliches Informationsarchitekt: Er kreiert und organisiert die Struktur für das effiziente Auffinden von Informationen im interaktiven System durch den Benutzer Interaktionsdesigner: Er konzipiert und definiert die Interaktion zwischen Mensch und interaktivem System auf Basis der Nutzungsanforderungen und der zu erledigenden Aufgaben. Die für die Erstellung der Interaktion genutzten Szenarien werden gemessen an der Effektivität, Effizienz und dem Grad der Zufriedenstellung im Verlauf der User Experience User Interface Designer: Er implementiert letztendlich das konkrete Benutzererlebnis anhand von Gestaltungsregeln, Styleguides und den Ergebnissen des Informationsarchitekten, des Interaktionsdesigners und des User Requirements Engineers. Langfassung:
Setz dich mit der ISO auseinander und/oder besuch entsprechende Weiterbildungen zu dem Thema, bevor du hier mit Begriffen wie "heiße Luft" um dich wirfst. Nur weil es Menschen gibt, die keine Ahnung haben und Begriffe "buzzwordig" verwenden, trifft das nicht auf alle zu. 
Gruß, Goulasz  
P.S.: Zum besseren Verständnis hier der Prozess zur Gestaltung interaktiver Systeme. Wer Anleihen an William Edwards Deming erkennt, darf sie behalten: