11 Dinge, die ich in meinem ersten Arbeitsjahr als UX/UI-Designer in einem Softwarehaus gelernt habe

Es ist tatsächlich mehr als ein Jahr her, seit ich meinen ersten Job als UX/UI-Designer bei einem Softwarehaus angetreten habe. Während einige Leute denken, dass dies aufgrund der Vielfalt der Projekte und der erforderlichen Unabhängigkeit nicht der beste Ort ist, um mit UX/UI-Erfahrungen zu beginnen, hatte ich damit keine großen Probleme. Ich arbeitete als Architekturassistentin für ein ziemlich großes Studio und war „freiberuflich“ für eine Studentenorganisation in den Bereichen Öffentlichkeitsarbeit und Grafikdesign tätig.

Allerdings gab es nicht nur Sonnenschein und Regenbögen . Zwischen der Entscheidung zur Umbenennung und dem Beginn meiner ersten Stelle vergingen weniger als vier Monate, sodass ich nicht alle für die Stelle erforderlichen Bereiche kennenlernen und verstehen konnte. Im Allgemeinen wird den Nachwuchskräften nicht viel über die Bedeutung der Zusammenarbeit zwischen verschiedenen Teams in Unternehmen beigebracht, vor allem über den geschäftlichen und vertrieblichen Teil des Projekts.

Hier sind einige Probleme, auf die ich in meinem ersten Jahr im UX/UI-Design gestoßen bin:

1.MVP und KPIs

Das waren fast völlig fremde Konzepte, die mir bei der Arbeit an meinem ersten Projekt begegnet sind. Zwar war es ein internes Projekt, aber die Arbeit war locker und ich konnte jeden Projektteilnehmer zu verschiedenen Themen befragen. Dabei lernte ich die Business-Analysten und ihre Rolle im Projekt kennen. Ich lernte die geschäftliche Seite von Produkten kennen, die, wie sich herausstellte, in Softwarehäusern der wichtigste Teil davon ist. MVPs und KPIs existierten aufgrund ihrer Erfahrung aus einer früheren Branche möglicherweise unter anderen Namen, aber ihre praktische Umsetzung in Workshops mit Kunden habe ich hier erlebt.

2. Geschäftsanforderungen, Anforderungen sammeln, mit dem Kunden bestätigen, Bestätigungen durchführen

Meiner Meinung nach ist dies der wesentlichste Teil der Arbeit eines Produktdesigners. Im Unternehmen war ich teilweise oder vollständig dafür verantwortlich, Anforderungen zu sammeln und sie mit dem Kunden zu bestätigen – manchmal in Zusammenarbeit mit einem Business-Analysten, der behutsam in die Struktur des Kunden eindrang und Geschäftsanforderungen sammelte. In dieser Phase ist es wichtig, sich über die Branche und die Prozesse des Kunden zu informieren, dem Kunden zu erklären, warum wir dies tun (falls er es nicht weiß) und diese Informationen über das zu entwerfende Produkt tatsächlich kontinuierlich zu sammeln. Dazu habe ich User Stories, Akzeptanzkriterien und potenzielle Risiken aufgeschrieben. Für den Kunden ist bereits in dieser Phase der visuelle Aspekt des von uns bestellten Produkts wichtig. Daher ist die Erstellung von Mid-Fi-Mockups die attraktivste Form der Erfassung solcher Anforderungen Modelle mit teilweise vorgeschlagenem Inhalt. Es ist wichtig zu bedenken, dass dies einer von vielen Vorschlägen ist, die vorgelegt werden können, sodass es sich nicht lohnt, sich auf eine solche Version des Projekts einzulassen. In dieser Phase müssen Sie auch die Klarheit des Informationsflusses im Auge behalten – also festlegen, wie Anforderungen erfasst und vom Kunden bestätigt werden. Ohne Abschluss dieser Phase können Sie die Entwicklung aufgrund potenzieller Risiken nicht vorantreiben – getroffene Entscheidungen ändern oder neue Anforderungen hinzufügen, was sich auf den Projektzeitplan auswirkt. Es kommt auch vor, dass wir ein Produkt erstellen, Anforderungen sammeln, vielleicht sind wir bereits in der Phase der Abnahme der Dokumentation oder sogar der Entwicklung, und plötzlich erklärt das Unternehmen (also die Benutzer), dass sie den Prozess nicht verstehen.

3. Zeit schätzen – unterschätzen oder überschätzen

Tatsache ist, dass die meiste Zeit damit verbracht wird, Mockups zu erstellen, bestehende oder benutzerdefinierte Bibliotheken anzupassen und Dokumentationen zu verfassen. Für unerfahrene Designer ist es oft sehr schwierig abzuschätzen, wie viel Zeit sie dafür aufwenden werden, und irgendwie müssen sie es auch. Mehrmals habe ich den Zeitaufwand für eine bestimmte Aufgabe unterschätzt und einmal sogar überschätzt, aber meiner Meinung nach ist diese Fähigkeit mit Erfahrung verbunden. In einer solchen Situation ist es gut, einen gewissen Zeitpuffer zu haben – es ist immer besser, etwas schneller als zu spät zu liefern.

4. Das Ruder, das Segel und das Schiff – Eigenständigkeit

Bisher musste ich meiner Erfahrung nach nur kleinere Teilaspekte von Projekten übernehmen, etwa die Koordination von Installationen in den Decken von Hotelzimmern und Fluren oder den sogenannten Back of House-Teilen. Als UX/UI-Designer war ich, nachdem ich offiziell meinem ersten Projekt zugewiesen wurde, viel stärker für das Produkt verantwortlich, da ich der einzige Designer im Projektteam war. Das war einerseits für mich eine Auszeichnung, andererseits aber auch eine große Verantwortung und ein umfassendes Vertrauen des Unternehmens. Ich weiß bis jetzt nicht, ob es zu mir passte, vielleicht war es viel zu früh, als jemand mit wenig Erfahrung in der Branche die volle Verantwortung für das Produkt zu übernehmen. Es war eine ziemliche Prüfung für mich, aber soweit ich weiß, waren sowohl der Kunde als auch das Team mit mir zufrieden, sodass ich diese Projektaufgaben für diesen Moment wohl doch gut bewältigen konnte

5. Recherche auf der UX-Stufe bzw. deren Fehlen

Kunden wissen oft nicht, welchen Sinn es hat, in der Entwurfsphase UX-Recherchen durchzuführen (und wenn doch, danken Sie Ihrer Vertriebsabteilung für einen so informierten Kunden!). Dies ist der allgemeine Nachteil von Softwarehäusern. Bei Produktunternehmen wurde aus meinen Gesprächen auf Meetups und Konferenzen deutlich, dass dies leider auch nicht der Standard ist, wenn es um den Designprozess geht. Dennoch lohnt es sich immer, die Präsentation vor dem Kunden über die UX-Forschung zu führen und darzulegen, warum sie wichtig ist und wie viel Zeit dadurch gespart werden kann. Das erste Beispiel von der Küste – ich habe ein Produkt entwickelt, dessen Geschäftsprozess, wie sich herausstellte, ziemlich kompliziert zu verstehen war – nicht nur für mich, weil die Benutzer es nicht gut verstanden haben. Gemeinsam mit dem Kunden mussten wir zur Anforderungserfassung zurückkehren, Sammeln Sie sie erneut, nachdem Sie mehr über den Prozess erfahren haben, verbessern Sie die Modelle und setzen Sie die Entwicklung fort. Dies hätte vermieden werden können, wenn wir einen Moment Zeit gehabt hätten, Prototypen der Modelle zu erstellen und Usability-Tests mit zukünftigen Benutzern (Mitarbeitern eines der Teams beim Kunden) durchzuführen. Selbst dann hätten wir die Probleme erkannt, die erst viel später auftraten.

6. Dokumentationserstellung

Dies ist wirklich ein Stück Arbeit, das der Kunde überprüfen muss. Zum Erstellen der UX-Dokumentation habe ich den ausführlichen Artikel von Autentika zum Vorbereiten der Dokumentation verwendet (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/auf Polnisch).

Es hat mir bei der Erstellung sehr geholfen, war aber nicht zu 100 % ausreichend. Die Prozessdiagramme in dem Produkt, das ich damals erstellte, waren SEHR kompliziert, also habe ich mich nicht ohne Grund an die Analysten gewandt und stattdessen mit ihrer Hilfe eine Anwendungsfallspezifikation und detailliertere Prozessanforderungen mit Akzeptanzkriterien erstellt. Natürlich würde ich eine solche Dokumentation jetzt etwas anders machen, aber zu dem Zeitpunkt war ich damit durchaus zufrieden.

7. Methoden? Existieren sie? (Nein)

Die meisten Softwarehäuser versuchen, iterativ zu arbeiten und individuell auf den Kunden einzugehen. In solchen Situationen ist es schwierig, Buchprozesse zu planen, zumal Board-to-Board-Recherchen selten durchgeführt werden, weil „keine Zeit“ ist oder man nur als Designer arbeitet. Letztendlich basiert die Designmethodik auf Agile, aber die Frameworks sind einander recht ähnlich und können eher in die Phasen Discover, Define, Design, Develop und Deliver/Deploy unterteilt werden (so ein erweitertes 5D mit einer Phase von Double Diamond). .

8. Den Kunden verstehen

Dies ist der Kern der Zusammenarbeit mit dem Kunden auf der Ebene des Anwendungsdesigns. Oftmals wissen Kunden (insbesondere aus Nicht-IT-Branchen) nicht, was UX ist, worum es geht und welche Probleme es bereits in den ersten Phasen des Projekts beseitigen kann. Ein gutes Beispiel aus meiner Erfahrung wäre die Präsentation von Lo-Fi-Modellen zur Erfüllung geschäftlicher Anforderungen. An dem Treffen nahm auch das Marketingteam des Kunden teil, das sehr unsicher war … über das Design der Lo-Fi-Mockups. Da nicht alle auf derselben Seite waren, habe ich noch einmal darauf hingewiesen, dass die Mockups nur der Gelegenheit dienten, über die Funktionalität und die Funktionsweise des Produkts zu sprechen. Leider hielt dies das Marketing nicht davon ab, Kommentare zu den in den Modellen verwendeten Schriftarten abzugeben, die zu diesem Zeitpunkt des Projekts keinen Einfluss auf das Design der Anwendung hatten . Schließlich, Das Thema hat sich relativ schnell gelöst und wurde verstanden, aber allein die Tatsache, dass es nicht sofort klar war, deutet darauf hin, dass das Thema UX in Unternehmen völlig unbekannt ist. Es lohnt sich, gleich zu Beginn der Entwurfsphase eine kurze Präsentation vor dem Kunden zu halten und zu besprechen, wie wir arbeiten, was wir präsentieren werden und inwieweit wir Input vom Kunden benötigen. Und natürlich, warum es ihm das wert ist.

9. Zusammenarbeit mit Entwicklern

Entwickler haben oft einen sehr guten Input, wenn es um Lösungen geht, und stellen sehr technische und logische Fragen, was mir oft einen guten Anlass zum Nachdenken über eine Lösung gab. Manchmal schlagen sie jedoch Lösungen vor, die für sie einfacher und aus Sicht des Benutzers nicht unbedingt gut sind. Daher muss hier genau abgewogen werden, was möglicherweise einen Änderungsvorschlag wert ist und wo es sich lohnt, sie anzuhalten und die getroffenen Entscheidungen zu erläutern.

10. API, JSON, LDAP, Orchestratoren und andere seltsame Wörter

Dies sind Schlüsselkonzepte für die Anwendungsentwicklung, die Sie als UX kennen sollten, da Entwickler und die gesamte IT-Community sie verwenden. Lernen Sie sie kennen und Sie können besser mit Ingenieuren sprechen. Sie wissen es nicht – fragen Sie am besten am Anfang, obwohl ich das Verständnis dieser Konzepte erst nach Durchsicht der von den Entwicklern erstellten Implementierungsdokumentation erlangte – die internen Kommunikationsdiagramme der Anwendung ermöglichten ein gutes Verständnis, wenn es darum geht Funktion.

11. Arbeit in Sprints, Projekttagebuch, Sprintplanung und Retro(spec)

Es handelt sich um wertvolle Meetings, die Ihnen die volle Kontrolle über das Geschehen im Projekt geben. Hier sind Projektmanager wichtig, die bei Bedarf eingreifen (z. B. wenn der Kunde versucht, die Vereinbarungen zu ändern), sowie Scrum Master, wenn wir agil arbeiten (fast alle Projekte).

Wie Sie vielleicht sehen, war das eine Menge Dinge, die ich erfahren habe, als ich in die IT kam. Ich hoffe, Sie finden sie interessant und vielleicht ist diese Liste hilfreich für diejenigen, die über eine UX/UI-Karriere nachdenken, oder sogar für Leute, die in dieser Branche arbeiten!