Jak spędzić pierwszy miesiąc na roli badacza UX (i zaprzyjaźnić się z nowymi kolegami z pracy)

Kiedy zaczynasz nową pracę jako badacz użytkowników, musisz zarówno oczarować swoich współpracowników (aby podejmowali działania w oparciu o twoje przyszłe wyniki badań), jak i rzucić im wyzwanie (aby stali się bardziej skoncentrowani na użytkownikach). Jak możesz to najlepiej osiągnąć w ciągu pierwszych 4 tygodni w nowej pracy?

Zdjęcie Charlotte Coneybeer na Unsplash

Jeden z moich ulubionych cytatów z doświadczeń użytkowników pochodzi od badacza użytkowników Harry'ego Brignulla, który pisze: „Badacz, który chce zadowolić zespół projektowy, jest bezużyteczny”.

Jednym z powodów, dla których podoba mi się ten cytat, jest to, że jako badacz użytkowników jesteś jak piasek w ostrydze. W ten sam sposób, w jaki grys podrażnia ostrygę, aby wyhodować perłę, badacz użytkowników ciągle znajduje problemy. Mogą to być problemy z pierwotną koncepcją projektową, problemy z późniejszymi projektami, a nawet problemy z podstawowym celem produktu. Twoim zadaniem nie jest zadowolenie zespołu programistów, ale popchnięcie ich do lepszej pracy poprzez zrozumienie użytkowników.

Istnieje jednak oczywiste ryzyko - podrażnienie może być za daleko posunięte. Kiedy zaczynasz nową pracę, ważne jest, aby nie wyglądać jak znośne spodnie i być zbyt krytycznym wobec tego, co już minęło. W końcu nie jesteś jeszcze świadomy ograniczeń, na jakie narażony jest zespół programistów. Być może niektóre z tych „złych” decyzji były w rzeczywistości „najgorszymi” decyzjami, które można było podjąć w danych okolicznościach.

Więc zacząłeś nową pracę. Jak możesz zirytować swoich kolegów i pozostać z nimi po pracy?

Tydzień 1: Mapuj terytorium

Jako badacz użytkowników będziesz wchodził w interakcje ze wszystkimi w zespole programistów i wieloma osobami spoza. Częścią twojego zadania jest łączenie tych ludzi i wspólne zrozumienie użytkowników i ich celów. Pomyśl o sobie jak o kleju, który zapewnia dobre wrażenia użytkownika. Dobrym sposobem na osiągnięcie tego jest zaangażowanie wszystkich współpracowników w badania użytkowników, zarówno poprzez obserwację, jak i udział w sesjach badawczych. A jeśli dopiero zacząłeś pracę, oznacza to spędzanie czasu na poznawaniu ludzi i pozwalaniu im poznać Ciebie.

Tak więc skutecznym sposobem na spędzenie pierwszego tygodnia jest zmapowanie terytorium. O czym jest produkt? Gdzie znajduje się w stosunku do innych produktów? Kto podejmuje decyzje i czyje opinie mają znaczenie?

Możesz uzyskać te informacje poprzez nieformalne wywiady i spotkania. Być może trzeba zaplanować niektóre z nich, szczególnie z bardziej zajętymi członkami zespołu programistów. Ale nie wszystkie muszą być formalne: rozmowy przy kawie lub lunchu, rozmowy w chłodni wodnej lub spotkania na korytarzu będą działać.

Twoim celem w tym tygodniu jest:

  • Zrozum ograniczenia, na jakie narażony jest zespół. Co można i czego nie można zrobić z technologią? Co napędza oś czasu?
  • Poznaj członków swojego zespołu. Jakie jest ich rozumienie UX i użyteczności? Czy w przeszłości poznali użytkowników lub zaobserwowali jakieś działania badawcze użytkowników? Jak oceniają znaczenie doświadczenia użytkownika z produktem? Jaka jest ich definicja sukcesu - zarówno dla produktu, jak i pod względem tego, czego oczekują od „doświadczenia użytkownika”?
  • Zidentyfikuj interesariuszy. Wyjdź poza zespół programistów i zidentyfikuj osoby w organizacji, które mogą sprawić, że Twój projekt odniesie sukces lub porażkę.
  • Odkryj ważne dane biznesowe. Wskazówka: „ważne wskaźniki biznesowe” zwykle zawierają znak waluty, niezależnie od tego, czy chodzi o zarabianie pieniędzy, czy obniżanie kosztów.
  • Weź lunch / kawę ze swoimi kolegami, ale staraj się nie robić tego codziennie z tymi samymi ludźmi. Musisz unikać stania się częścią wewnętrznej kliki.
  • Ostrzeż ludzi, że potrzebujesz 2 godzin czasu na warsztaty w przyszłym tygodniu (więcej tego później). Weź to do swojego pamiętnika.
  • Jeśli nie możesz prototypować, znajdź kogoś w zespole programistów, który może. Wkrótce staną się twoim najlepszym przyjacielem.
  • Na podstawie tego, czego się nauczyłeś, oszacuj dojrzałość UX zespołu.

Tydzień 2: Pomóż swojemu zespołowi zrozumieć ich użytkowników

Twoim najważniejszym obowiązkiem jako badacza użytkowników jest pomoc zespołowi w lepszym zrozumieniu ich użytkowników. Zespół musi docenić, że istnieją różne grupy użytkowników, że niektóre z tych grup są ważniejsze od innych i że jedna, a może dwie z tych grup będą celem projektu. Następnie musisz pomóc zespołowi w dogłębnym zrozumieniu celów, motywacji i umiejętności użytkowników.

Twoim celem w tym tygodniu jest:

  • Zacznij kompilować badania przeprowadzone z użytkownikami w przeszłości. Mogą to być badania przeprowadzone przez zespół lub organizację lub przez zewnętrznych badaczy, takich jak uniwersytety.
  • Poprowadź warsztat z zespołem i poproś, aby stworzyli osobowości. Nie ma znaczenia, czy są całkowicie błędne. To ćwiczenie jest delikatnym sposobem, aby pomóc zespołowi programistów uświadomić sobie, że nie są oni użytkownikami (a także pomóc ci odkryć rzeczy o użytkownikach, o których możesz nie wiedzieć).
  • Skorzystaj z tego warsztatu, aby spróbować również zrozumieć środowisko użytkowników: na przykład, z jakich urządzeń najczęściej korzystają?
  • Zbuduj ścianę badawczą. Zdobądź tablicę i zacznij pokazywać swoją pracę. Umieść osobiste założenia na tej ścianie.
  • Jeśli jest czas i budżet, spędzić 1–2 dni w tym tygodniu, odwiedzając garść użytkowników w kontekście.
  • Jeśli masz mało czasu lub mały budżet, spędź dzień na badaniach partyzanckich.
  • Jeśli nie ma czasu ani budżetu na badania użytkowników, rozważ przeniesienie do innej pracy. Tymczasem zapoznaj się z istniejącymi badaniami i przeanalizuj wszelkie dostępne dane użytkownika (takie jak analityka internetowa lub dane z centrum obsługi telefonicznej).

Tydzień 3: Pomóż swojemu zespołowi zrozumieć zadania swoich użytkowników

Zadania to czynności, które użytkownicy wykonują z produktem, aby osiągnąć swoje cele. Pomaganie zespołowi w myśleniu o zadaniach użytkowników, a nie o funkcjach systemowych, jest ważnym krokiem, aby zespół mógł zobaczyć ogólny obraz. Wynika to z faktu, że zadania użytkowników prawie zawsze wymagają użycia kilku funkcji do wykonania, co zapobiega wyciszeniu myślenia.

Twoim celem w tym tygodniu jest zidentyfikowanie czerwonych tras lub najważniejszych zadań, które użytkownicy wykonują z Twoim produktem. Zapobiega to traktowaniu przez zespół każdej funkcji jako równie ważnej i pomaga nadać priorytet rozwojowi.

Twoim celem w tym tygodniu jest:

  • Porozmawiaj z członkami zespołu i utwórz listę wszystkich możliwych zadań. Następnie poproś zespół, aby zidentyfikował 10 najważniejszych zadań użytkowników.
  • Weź swoją listę zadań i pokaż ją użytkownikom. Poproś użytkowników o nadanie priorytetu tym zadaniom. Możesz to zrobić albo w ramach wizyty w terenie wśród użytkowników, albo poprzez rozprowadzenie ankiety dotyczącej najważniejszych zadań wśród części odbiorców.
  • Porównaj i porównaj rankingi ważności zadania opracowane przez zespół programistów z rankingami użytkowników. Im bardziej podobne rankingi, tym lepiej zespół rozumie swoich użytkowników.
  • Przekształć garść zadań (ocenionych przez użytkowników) w scenariusze testów użyteczności.

Tydzień 4: Przeprowadź test użyteczności

Przeprowadzenie testu użyteczności jest zawsze dobrym początkowym działaniem, gdy dołączasz do nowego zespołu programistów, ponieważ pomoże ci pozbyć się wpływowych interesariuszy i ocenić ich podejście do angażowania użytkowników w swoją pracę. Pozwoli ci to również zorientować się, jaki budżet jest dostępny: czy istnieje laboratorium użyteczności, czy też możesz je zatrudnić? Jeśli nie, czy możesz przeprowadzić zdalne, moderowane testy użyteczności? Czy jesteś ograniczony do partyzanckich testów pop-up użyteczności w kawiarniach?

Pod względem tego, co powinieneś przetestować:

  • Przetestuj bieżący produkt lub prototyp - lub jeśli nie ma jeszcze produktu, przetestuj najlepszego konkurenta z około 5 użytkownikami.
  • Jeśli budżet jest niewielki, wykonaj jedną zdalną moderowaną sesję, a następnie wykonaj kilka zdalnych, niemoderowanych testów.
  • Jeśli nie ma budżetu, przeprowadź test użyteczności z przyjaciółmi i rodziną.

Twoim celem w tym tygodniu jest:

  • Poproś zespół, aby obserwował co najmniej jedną sesję, najlepiej na żywo. Jeśli nie jest to możliwe, poproś każdego członka zespołu o przejrzenie jednego z filmów z sesji. A jeśli nie jest to możliwe, stwórz szpulę z najważniejszymi ilustracjami przedstawiającymi główne ustalenia i zaprezentuj to w programie i opowiedz.
  • Zaangażuj zespół w analizę problemów związanych z użytecznością. Po pierwsze, poproś każdego członka zespołu, aby zidentyfikował problemy z obserwowanej sesji. Następnie, jako grupa, wykonaj sortowanie według powinowactwa, aby połączyć podobne obserwacje i zdecyduj, które problemy najpierw rozwiązać.
  • Zaplanuj następny kwartał: jeśli istnieją luki w zrozumieniu użytkowników i zadań, rozważ wizytę w terenie. Jeśli potrzebujesz prototypu, zaplanuj to. A jeśli Twoja organizacja w ogóle nie chce, abyś angażował użytkowników, rozważ znalezienie innej pracy.

Rozstanie myśli

Rozpoczynając nową pracę w UX, ludzie mają tendencję do zadawania sobie pytań (często domyślnie): „Jak tu się wszystko robi?” Następnie większość ludzi z czasem wkracza w krok lub dostosowuje swoje praktyki pracy, aby się dopasować - tym samym negując całość punkt ich zatrudnienia w pierwszej kolejności (ponieważ generalnie jesteś zatrudniony za to, co możesz przynieść na imprezę - nie dlatego, że możesz powtórzyć to, co organizacja już robi).

Z drugiej strony, zbyt szybkie ładowanie się i próba zmiany rzeczy to pewny sposób na to, aby twój zespół cię nienawidził. Musisz przejść cienką linię między drażnieniem swoich nowych kolegów a wyzwaniem, aby bardziej skupili się na użytkowniku. Wypróbuj niektóre pomysły zawarte w tym artykule, aby przekonać zespół programistów do stworzenia kilku pereł.

Pierwotnie opublikowany na www.userfocus.co.uk.