100 Tage Scope
Heute bin ich seit 100 Tagen bei Scope, eine gute Gelegenheit, Rückschau auf meine Arbeit der letzten Monate zu halten. Dabei sind mir drei Herausforderungen aufgefallen, mit denen ich bei meinem Übergang von UX-Design ins Produktmanagement konfrontiert worden bin:
1. Launch einer Web-App ohne Fixtermin
Im Rahmen unserer Strategie, weniger «App-zentriert» zu werden, war die erste grosse Aufgabe, die neue Web-App entwickeln und zu lancieren. Als ich meine Stelle antrat, waren Informationsarchitektur und visuelles Design bereits entwickelt worden.
Was fehlte, war ein klarer Starttermin. Wer mit dem Konzept des «Minimum Viable Produkt» (MVP) vertraut ist, kennt die Herausforderung zu entscheiden, wann und mit welchen Features man live gehen soll: Was sollte das Produkt von Anfang an können, um einen guten ersten Eindruck zu machen, und was können wir später nachschieben, basierend auf einer systematischen Priorisierung? In meinen UX-Jobs war ich oft damit beschäftigt, komplexe Features in User Stories herunterzubrechen und diese zu priorisieren , aber die Deadline «gehörte» immer jemand anderem. Also bauten wir immer mehr Features ein und wären wahrscheinlich noch heute am Finetuning des Designs – doch zum Glück sprang unser CEO Peter in die Bresche und legte ein Datum fest, an dem wir live gehen sollten, und so geschah es auch, siehe unseren Blogpost zum Launch.
Als Head of Product bin ich nun verantwortlich für die Planung und die Release-Termine, und wenn ich mir zu sehr auf das Design fokussiere, lenkt mich das wahrscheinlich ab.
2. Benutzer interviewen, wenn alles andere dringender scheint
Ich glaube an User-Centered Design. Und ich habe eine schwere Allergie entwickelt gegen UX Designer, die nie Benutzer beobachten, oder denken, sie seien schon Experte, wenn sie fünf Personen interviewt haben, von denen sie auch noch mit zweien verwandt sind. Daher wollte ich natürlich so bald wie möglich mit Benutzern unseres Produktes reden. Doch es gab so viel zu entwerfen und zu verbessern, und zudem arbeitete ich bis vor kurzem nur in einem Teilzeitpensum, so dass sich die Arbeit bei mir staute. Wie kann ich an einem besseren Sicherheitssystem forschen, während oben die Bank ausgeraubt wird?
Indem ich mich an das halte, was ich seit Jahren in Workshops und im Unterricht gelehrt habe: Funktionalität und Design müssen sich danach richten, was die Benutzer brauchen. Wenn wir nicht eines ihrer Probleme lösen, sind wir wahrscheinlich in der falschen Richtung unterwegs. Also müssen wir sie zuerst verstehen.
In unserem Fall begann ich mit der «Angebotsseite»: unsere klugen, oft originellen und immer vielbeschäftigten Kuratorinnen und Kuratoren.
Via Google Hangout «traf» ich mich mit neun ausgewählten Personen, die mich bei ihrer Kuratiertätigkeit zuschauen liessen und mir erklärten, welche Fragen und Probleme bei der Auswahl und Kommentierung von Artikeln auftraten. Die Gespräche liefern uns wertvolle Erkenntnisse über ihre Motivation und Probleme. Diese bilden die Grundlage für die weitere Arbeit an der «Kuratoren-Konsole», die Anwendung, die sie verwenden, um jeden Tag Artikel auszuwählen.
Als nächstes seid Ihr dran, User! (Ja, ja, vorher muss ich noch tausend andere Dinge liefern, die Bankräuber sind immernoch dran. Glücklicherweise hilft mir seit kurzem unsere neue Designpraktikantin Ioana, sie in Schach zu halten.)
3. Wir sind ein Start-up, aber unser Zeug hat jemand anders gebaut
Meine Ex-Kollegen down under bei der Bank würden schön staunen, wenn ich das Wort “Legacy” für 3 Jahre alte Software verwende. (“Legacy? Schau Dir mal unsere Green-Screen, Nicht-GUI-Systeme aus dem Jahr 1962 an, dann reden wir weiter.”).
Ich werde es trotzdem tun: Legacy-Anwendungen und -Schnittstellen zu übernehmen ist heikel, bei Scope habe ich
- komplexe Technik angetroffen – etwa ein Biest von einem Crawler, der die Artikel für unsere Kuratoren zusammenstellt. Die Software enthält viele unbekannte Funktionen und Code-Schnipsel, die genug Material für eine weitere Episode der X Files hergeben würden.
- Das visuelle Design für die neue Web-App und Entwürfe für eine Neugestaltung der mobilen App waren auch bereits fertig. Es ist etwas schwierig, als UX Designer in einer Situation anzukommen, wenn diverse Interaktions- und visuellen Design-Entscheidungen bereits getroffen wurden.
- Zwei mobile Anwendungen werden jeden Tag aus den App-Stores heruntergeladen – und sie sehen komplett anders aus als unsere Web-App…
- Mehrere Newsletter, zwischen denen die Unterscheidung schwer fällt.
Bei der Durchsicht aller Features und Designs haben wir uns zunächst vor allem darauf konzentriert, eine Menge davon zu beseitigen, statt neue zu bauen (“Killing the Zombies”, wie Zombies Run Gründerin Lisa Long es kürzlich am Produktmanagement-Festival in ihrem brillanten Vortrag nannte).
Die Herausforderung war – natürlich – zu entscheiden, welche wir eliminieren konnten. Dafür haben wir uns diese Grundregeln überlegt:
- Wenn wir vermuten, dass niemand es nutzt, verstecken wir es.
- Wenn wir nicht wissen, was es bewirkt, verstecken oder deaktivieren wir es.
- Wenn wir nicht glauben, dass es Nutzen bringt, schalten wir es ab.
Mein UX-Skillset kann viel zu meiner neuen Rolle beitragen, mich aber auch davon abhalten, dass ich einiges tue, was zu tun wäre.
Oder um es in einer Grafik auszudrücken:
Ich freue mich auf die nächsten Monate, in denen wir uns weiterhin auf Benutzerwachstum konzentrieren werden und hoffentlich weiter neue Firmenkunden gewinnen werden.
Willst Du mir helfen, unser Produkt weiter zu verbessern? Ich habe eine Mailing-Liste für «Scope Bessermacher» eingerichtet, auf der ich Aufrufe für Usability-Test-Teilnehmer oder Interviewpartner veröffentlichen werde.
Oder einfach mail uns einfach Dein Feedback an support@thescope.com.
