UX & PO'ing

Blog o nie do końca sprecyzowanym profilu.

Przerzucam się na angielski

Jak w temacie. Przez jakiś czas będę pisał wyłącznie w języku Shakespeare`a.

Nowy blog: www.mozyrko.com.

 

 

Polska edycja UX Storytellers

Podczas tegorocznej konferencji UX Poland ogłoszono wydanie polskiej edycji UX Storytellers – zbioru inspirujących opowieści z życia dwunastu osób związanych z branżą UX w naszym kraju. Wśród nich znalazła się również moja, krótka historia.

Publikacja dostępna do ściągnięcia na stronie uxstorytellers.pl.

Każda z historii składa się z kilku wątków, również wybranych w głosowaniu przez członków CHI Polska. Poprosiliście, żeby w każdej z opowieści znalazła się motywacja wyboru takiego właśnie zawodu oraz krótki opis ścieżki kariery, do dziś oczywiście, bo wszystkie te kariery nadal się rozwijają. Chcieliście też przeczytać o największych sukcesach w branży UX w Polsce a także o najciekawszych projektach, najtrudniejszych wyzwaniach i porażkach. Pojawiły się także życzenia, żeby UX Storytellerzy podzielili się z Wami projektami swoich marzeń. Każdy z naszych gości próbował też odpowiedzieć na pytanie, jaki był jego wpływ na branżę UX w Polsce. Było to chyba najtrudniejsze zadanie, ponieważ trudno jest z tak szerokiej perspektywy ocenić skuteczność własnych działań. Nieco łatwiejszym zadaniem okazało się wskazanie autorytetów i inspiracji. Na koniec każdy UX Storyteller spróbował przygotować kilka wskazówek dla młodych projektantów oraz zasugerował swoją ulubioną książkę z dziedziny User Experience.

 

Easy is hard

Johann Wolfgang Goethe napisał kiedyś do jednego z przyjaciół całkiem spory list. Na końcu w postscriptum dopisał jeszcze:

Szanowny panie hrabio, przepraszam za tak długi list, ale nie miałem czasu, żeby sformułować go krócej.

O wartości kończenia rzeczy

Rozmawiałem kiedyś z kolegą z pracy (G.) na temat wewnętrznego projektu IT. Projekt ciągnął się jak działacze PSL za posadami państwowymi. Nie mogliśmy dojść do miejsca w którym wszyscy zgodnie uznalibyśmy że udało nam się zamknąć jakiś znaczący etap.

Byliśmy wtedy jeszcze młodą firmą. Większość osób studiowała lub była świeżo po studiach. Nad projektem pracował niewielki zespół programistów. Jako świeżo upieczony manager produktu odnosiłem wrażenie, że inne firmy realizują swoje projekty szybciej. A my przecież tacy „młodzi” i „dynamiczni”. Ilość czasu „przepalanego” na realizację naszego projektu powiększała się z dnia na dzień.

Powiedziałem kiedyś G. co myślę. Porównałem nas do znanej nam obu firmy. G. popatrzył na mnie przez chwilę w skupieniu.

- Wiesz, Bartek, oni pewnie mają więcej zakończonych projektów. Nie ważne, że „mniej ambitnych”. Dlatego realizują kolejne szybciej. Z programistami jest tak, że dopóki nie skończysz projektu i nie otrzymasz feedbacku (w domyśle: nie dowiesz się co spieprzyłeś), to nie skillujesz.

G. miał rację.

Mieliśmy wtedy za mało doświadczenia i nie wiedzieliśmy jak optymalnie rozłożyć siły zespołu. Trudno nam było ustalić priorytety dla rzeczy ważnych a mniej istotne odsunąć na dalszy plan. Dzisiaj każdy wie czym jest minimum viable product, więc może byłoby nam łatwiej (?).

Experience is earned by killing monsters and finishing quests

Graliście kiedyś w gry RPG?

W grach RPG zawsze fascynował mnie uproszczony model rozwoju postaci. Na początku rozgrywki gracz dostaje ustawowe punkty, które rozdziela pomiędzy różne umiejętności. Każdy z graczy wybierze inny, preferowany przez siebie skillset. Liczba punktów, które możecie przyznać każdej postaci jest stała  (podobnie jak z prawem Beckhapa, gdzie uroda x rozum = constans ;).

Interesujący jest również mechanizm rozwoju postaci. Tutaj kluczowe jest zdobyte doświadczenie. Dopóki nie zbierzesz odpowiedniej liczby punktów doświadczenia, nie wskoczysz na kolejny poziom. Jest to swego rodzaju forma gratyfikacji dla gracza za wysiłek włożony w rozwój fabuły.

W przypadku gier komputerowych, mechanizm ten bardzo często przedstawiany jest za pomocą „paska doświadczenia”. Zdobyte punkty doświadczenia stopniowo wypełniają poziomą kreskę.

diablo_pasek_doswiadczenia_postaci

Diablo 3 – pasek doświadczenia

Gdy pasek wypełni się do końca, gracz osiąga kolejny poziom. Nierzadko bywa tak, że za ukończenie jednego z początkowych zadań dostaniemy więcej doświadczenia, niż w późniejszych etapach  rozgrywki. Może się również zdarzyć, że wpadając w wir walki,  nie zwrócimy uwagi, że osiągnęliśmy wyższy poziom. Przeważnie gra informuje nas jakie korzyści przyniósł nam postęp w grze. Zasada jest prosta – im więcej rzeczy zrobimy, tym większa czeka nas nagroda.

Prawie jak w życiu, co nie?

It’s All in How You Slice It

Trzeba jeszcze umieć mierzyć siły na zamiary. Przyrost dodatkowych umiejętności pojawia się stopniowo. Warto o tym pamiętać. Jeżeli w pierwszych minutach gry rzucimy się sami na hordę goblinów, najprawdopodobniej nie skończy się to dla nas najlepiej. First things first.

Żeby skończyć coś dużego, lepiej zacząć od małego. Taką sytuację dobrze opisuje poniższy obrazek – dwa podejścia do pieczenia tortu. Pierwszy scenariusz opisuje sytuację, gdy zaczynamy od upieczenia samego ciasta, potem zabieramy się za nadzienie, na końcu dekorujemy. Problem z tym podejściem jest taki, że po po kilku godzinach pracy nadal nie mamy niczego co nadawałoby się do zjedzenia (a już na pewno nie do sprezentowania innym).

Zamiast tego możemy zacząć od upieczenia czegoś mniejszego – babeczki. Zaletą podejścia jest krótki czas przygotowania wypieku oraz mniejsze zużycie mąki (zasoby). Oznacza to, że szybciej możemy dowiedzieć się, co o efekcie naszej pracy myślą inni. Ten cenny feeedback pomoże ocenić nam czy jest sens piec coś większego. Może się również okazać, że nikt w naszym otoczeniu nie ma ochoty na słodkości. Nic straconego, zaoszczędzony czas i mąkę możemy przeznaczyć na coś przyrządzenie innej potrawy, np. pizzy.

Jeżeli cały czas będziemy podążali pierwszym scenariuszem, rzadko kiedy uda nam się zrobić coś dobrze. Co więcej, czas potrzebny na uzyskanie feedbacku od otoczenia znacznie się wydłuży. Możemy poświęcić dużą ilość czasu, a i tak nie być w stanie dokończyć tortu. Dobrze jest zaczynać od rzeczy małych i uczyć się na (równie małych) błędach. Zdobyty experience przyda się potem. W rezultacie będzie nam łatwiej poradzić sobie z podobnymi czynnościami ale na większą skalę.

W branży software development`u wiele na ten temat już powiedziano.

Reguła 10 tys. godzin (wersja uproszczona)

Nic w życiu nie przychodzi bez wysiłku. Żeby być w czymś dobrym, trzeba również zainwestować swój czas. W celu osiągnięcia poziomu eksperckiego w danym temacie, trzeba poświęcić w przybliżeniu 10 tysięcy godzin. Zagadnieniu przyjrzał się uważnie psycholog K. Anders Ericsson przeprowadzając badania których celem było określenie najważniejszych czynników warunkujących rozwój zawodowy profesjonalnych muzyków.

Do ukończenia 20 lat należący do elity artyści ćwiczyli łącznie przez 10 tys. godzin. Dobrzy uczniowie ćwiczyli przez 8 tys. godzin, a przyszli nauczyciele muzyki niewiele ponad 4 tys. godzin. Z tych badań wyłania się następujący obraz: aby osiągnąć poziom biegłości odpowiadający klasie światowej w dowolnej dziedzinie, należy zaliczyć 10 tys. godzin ćwiczeń. W licznych badaniach z udziałem kompozytorów, koszykarzy, pisarzy, łyżwiarzy, pianistów koncertowych, szachistów, słynnych przestępców i innych, liczba ta pojawia się nieustannie. 10 tys. godzin odpowiada z grubsza trzem godzinom ćwiczeń dziennie albo 20 godzinom tygodniowo przez 10 lat. Oczywiście nie wyjaśnia to, dlaczego niektórym osobom ćwiczenie daje znacznie więcej niż innym. Ale nikt jeszcze nie opisał przypadku osiągnięcia prawdziwej światowej klasy w krótszym czasie. Wydaje się, że nasz mózg potrzebuje tak długiego czasu, żeby przyswoić sobie wszystko co należy i osiągnąć prawdziwą biegłość w danej dziedzinie.

Źródło: http://coaching.focus.pl/2010/03/19/wrodzony-talent/

Praca to zbiór aktywności zmierzających do osiągnięcia celu w skończonym przedziale czasu

Wspomniane wcześniej 10 tys. godzin trzeba rozdzielić na małe zadania, które pozwolą na rozwój. Oczywiste jest, że im dłużej coś robimy tym stajemy się lepsi. Natomiast, to co mi wydaje się ciekawe i godne zauważenia, to fakt że nie wystarczy po prostu czegoś robić, trzeba to jeszcze być w stanie zakończyć. Zacząć od najmniejszej jednostki pracy niezbędnej do zebrania feedbacku, wyciągnąć wnioski, levelować. Zdarzyło mi się poznać bardzo „zabieganych” ludzi, którzy niczego nie kończą. Im więcej takich osób spotykam, tym bardziej analogia z grami RPG wydaje mi się wyraźniejsza. Warto rozważnie dobierać rzeczy w które chcemy się angażować. Nawet te małe. Ale kończyć.

PS
Skończenie tego wpisu zajęło autorowi 3 miesiące. Uff.

Czego może nauczyć się UX’owiec rozwijający własny startup

Prezentacja z wystąpienia UX Poland 2013, gdzie miałem okazję opowiedzieć o tym czego się nauczyłem w trakcie prowadzenia projektu UsabilityTools. Mówiłem z perspektywy badacza, który stał się managerem produktu (czyli jak z „adwokata użytkownika” przeszedłem na stronę „biznesu” ;).

Opowiedziałem w jaki sposób praca nad rozwojem własnego produktu polepszyła mój researcherski skillset, o wartości dzielenia pracy na małe części, o najmniejszej jednostce pracy potrzebnej do przeprowadzenia wartościowego badania, o tym jak testowaliśmy koncepty na wczesnym etapie rozwoju produktu, o miejscu UX’a w procesie developmentu (scrum). Opisałem co robiliśmy źle, co udało nam się poprawić i jakie z tego wnioski wyciągnęliśmy na przyszłość.

Biznesowa wartość prostoty

Wczoraj nauczyłem się czegoś nowego. W trakcie sprintu 80 odkryliśmy wadę w procesie rejestracji UsabilityTools. Okazało się, że nie wszyscy nowi użytkownicy są w stanie zalogować się do systemu tuż po rejestracji. Przyczyną błędu była wada aplikacji. W rezultacie, część użytkowników odpadła na wczesnym etapie lejka konwersji i (co jest bardzo prawdopodobne) nigdy nie powróciła.

flow1

Proces rejestracji

Od dłuższego czasu nosimy się z zamiarem optymalizacji tego procesu. Pamiętając o tym, zagadnąłem jednego z programistów.

- Tomek, a gdybyśmy od samego początku mieli o jeden krok mniej w procesie, ten błąd nigdy by nie wystąpił?
- Nie wystąpiłby 
- Aha…

flow2

Proces rejestracji po zmianie

Upraszczając flow wcześniej nie tylko odciążylibyśmy użytkownika, zmniejszylibyśmy również koszty utrzymania naszego systemu (maintenance).

Upraszczać aplikacje/strony możemy na wiele sposobów:

  • zminimalizować liczbę kroków
  • zminimalizować czas potrzebny do realizacji celu
  • zminimalizować liczbę funkcjonalności
  • zminimalizować liczbę elementów na ekranie

Jako researcher zawsze postrzegałem taką optymalizację jako kwestię związaną z użytecznością interfejsu. Im prostsze GUI, tym lepiej dla użytkownika. Jako manager produktu doceniam przede wszystkim wartość biznesową takiego podejścia. W wyniku błędu mogliśmy stracić potencjalnych klientów, a jego naprawa zajęła cenny czas zespołu.

To prawda co mówią – wszystko trzeba robić tak prosto, jak to tylko jest możliwe.

Rola UX’a w zespole programistycznym

Interaktywna prezentacja dostępna pod adresem: http://naugtur.github.io/pres/ux/slides.html#/.

Warto przeklikać, chociażby ze względu na ciekawe efekty wizualne :)

Prezentację poprowadziliśmy wspólnie ze Zbyszkiem Tenerowiczem w ramach konferencji 4 Developers 2013. Opis wystąpienia poniżej.

Dobre produkty nie biorą się z „dobrze zdefiniowanych wymagań” ale z głębokiego zrozumienia potrzeb użytkowników, wiedzy o możliwościach/ograniczeniach technologicznych oraz umiejętności testowania wypracowanych konceptów na każdym etapie rozwoju produktu. Sukces produktu jest wynikiem współpracy zespołu z różnymi grupami interesariuszy. Podjęte podczas definiowania wymagań decyzje wpływają nie tylko na zadowolenie użytkowników, ale determinują wysiłek potrzebny do zrealizowania projektu. Nawet drobna zmiana w mockup-ie może zmienić czas trwania projektu o całe tygodnie.

W naszym wystąpieniu podzielimy się doświadczeniem zdobytym w trakcie prowadzenia projektu UsabilityTools.com. Uczestnicy wystąpienia dowiedzą się:
  • jak testować wczesne założenia
  • jak komunikować potrzeby użytkowników wewnątrz zespołu
  • czym jest minimum viable product i minimum viable research
  • co nazwaliśmy „effort centered design”
  • co zyskuje designer, gdy zrozumie kod
  • jaką władzę daje designerowi styleguide

SaaS is SEXY

Prezentacja z lutowego spotkania Startup Stage, na którym z Dawidem Wienerem opowiadaliśmy o drodze z agencji (Cogision) do SaaS-owego biznesu (UsabilityTools).

Mówi się, że rynek SaaS jest gotowy na eksplozję i zastąpienie tradycyjnego software’u nowym modelem opartym o chmurę. Podczas spotkania prelegenci próbowali odpowiedzieć sobie na pytanie czy rzeczywiście tak jest?

Dobry Product Manager, zły Product Manager

Dobry product manager zna rynek, produkt oraz wszystkie funkcjonalności na tyle dobrze żeby operować na bazie solidnej wiedzy i faktów. Dobry product manager jest CEO produktu. Dobry product manager bierze pełną odpowiedzialność za produkt i ocenia swoją pracę w kategoriach jego sukcesu. Jest odpowiedzialny za stworzenie właściwego produktu we właściwym czasie oraz za wszystko co się z tym wiąże. Dobry product manager zawsze wie co się dzieje dookoła niego (firma, źródła przychodów, konkurencja, etc.) i bierze pełną odpowiedzialność za egzekucję planu rozwoju produktu.

Zły product manager ma zawsze masę wymówek.

Finansowanie jest za małe, kierownik działu IT jest idiotą, Microsoft ma 10x więcej ludzi pracujących nad tym ficzerem. Jestem przepracowany. Nie otrzymałem dostatecznie jasnych wytycznych.

Dobry manager produktu nie pozwala by cały jego czas był zjadany przez różne podmioty pracujące nad rozwojem produktu. Nie marnuje czasu swojego zespołu. Nie skupia się nad rozwojem każdej z funkcjonalności. Nie jest od tego by zadowalać każdą zachciankę zespołu. Nie jest członkiem zespołu. On kieruje pracą zespołu. Dobry product manager nie jest od tego by „sprzedawać” marketingową wizję produktu wewnątrz zespołu. Dobry manager produktu jest marketingowym odpowiednikiem kierownika technicznego. Dobry manager produktu zwięźle opisuje cel, tak zwane „co” (w przeciwieństwie do „jak”) i kieruje dostarczeniem wszystkiego co weszło w jego zakres. Zły manager produktu lubi rozwodzić się nad tym „jak”. Dobry manager produktu komunikuje się zwięźle z osobami technicznymi zarówno w mowie jak i piśmie. Dobry manager produktu nie wydaje poleceń nieoficjalnie. Dobry manager produktu pozyskuje informacje nieoficjalnie.

Dobry product manager tworzy FAQ`i, prezentacje, analizy rynku które są zdatne do użycia. Zły product manager skarży się że przez cały dzień musiał odpowiadać na pytania działu sprzedaży i jest zawalony pracą. Dobry product manager jest w stanie przewidzieć znaczące wady produktu z wyprzedzeniem oraz być w stanie dostarczyć działające rozwiązanie. Zły product manager spędza cały dzień na gaszeniu pożarów. Dobry product manager przyjmuje pisemne stanowisko w ważnych kwestiach („pewniaki” zapewniające przewagę konkurencyjną, poważne decyzje techniczne, rynki na które warto wejść lub się wycofać). Zły product manager wyraża swoją opinię ustnie i lamentuje kiedy „siła wyższa” pokrzyżuje mu plany. Kiedy złemu product managerowi się nie powiedzie, przypomina wszystkim dookoła, że to wcześniej przewidział.

Dobry product manager skupia uwagę zespołu na przychodach i klientach. Zły product manager skupia uwagę zespołu na tym jak dużo nowych ficzerów wprowadziła konkurencja. Dobry product manager definiuje wymagania dla produktu, który można zbudować dużym nakładem pracy. Zły product manager definiuje wymagania dla produktu, którego nie da się skończyć na czas lub pozwala zespołowi budować co mu się żywnie podoba (np. rozwiązać najciekawszy technicznie problem).

Dobry product manager myśli w kategoriach dostarczenia produktu o najwyższej jakości przed rozpoczęciem prac oraz o procencie pokrycia rynku i wskaźnikach biznesowych po wypuszczeniu produktu. Zły product manager miesza pojęcia USP, unique value proposition, przewagi konkurencyjnej, ceny. Dobry product manager potrafi rozbić problemy na mniejsze części. Złemu product managerowi wszystkie problemy zlewają się w jedną całość.

Dobry product manager myśli o tym w jaki sposób chce żeby prasa napisała o jego produkcie. Zły product manager chce opisać każdy ficzer oraz być bardzo szczegółowy technicznie. Dobry product manager zadaje prasie pytania. Zły product manager odpowiada na każde pytanie prasy. Dobry product manager zakłada, że dziennikarze i analitycy to inteligentni ludzie. Zły manager produktu zakłada, że dziennikarze oraz analitycy są niepoważni ponieważ nie rozumieją różnicy pomiędzy akcją „push” a „simulated push”.

Dobry product manager potrafi rozróżnić klarowność wypowiedzi od wyjaśniania „rzeczy oczywistych”. Zły product manager nigdy nie wyjaśnia „rzeczy oczywistych”. Dobry product manager sam określa zakres swoich obowiązków i wie kiedy udaje mu się je wypełnić. Zły product manager chce żeby mówiono mu co ma robić.

Dobry product manager tworzy cotygodniowe sprawozdania ponieważ jest zdyscyplinowany. Zły product manager wysyła sprawozdania nieregularnie ponieważ nie ceni dyscypliny.

Good Product Manager, Bad Product Manager
Ben Horowitz
Director of Product Management
Wiosna 1996

Tłumaczenie własne.

The Elements of Trolling

Kolega z pracy przerobił mój ulubiony model. Kiedy poprosiłem go żeby wyświetlił oryginalną wersję w trakcie jednej z naszych dyskusji, nie zauważyłem że podmienił napisy. A ja sobie gadałem w najlepsze. Było zabawnie :)

the_elements_of_trolling

Cieszę się, że takie rzeczy powstają w naszej firmie. Tym bardziej, że osoba która przerobiła model jest developerem. W moim przekonaniu jest to znak, że myślenie w kategoriach UX weszło na stałe do kultury naszej organizacji.

Domowa architektura informacji

Dzisiaj przyłapałem znajomego na robieniu porządków w szafie. Z zawodowej ciekawości zapytałem, jak nazywa poszczególne kupki ubrań. Jego odpowiedź została pokazana na obrazku poniżej.

domowa_architektura_informacji

Architektura informacji, to dziedzina która za cel stawia sobie ułatwienie ludziom dotarcie i wykorzystanie informacji w różnego rodzaju systemach. Dla kolegi takim „systemem” jest jego szafa z ubraniami. W tym przypadku kolega jest jedynym użytkownikiem szafy. Zastanówmy się jednak, jakie to niesie przesłanki dla osób zajmujących się projektowaniem różnego rodzaju systemów bogatych w content jak np. serwisy internetowe.

Zawsze można poukładać te same elementy na wiele sposobów. Sposób połączenia elementów ze sobą powinien mieć sens dla twórcy ale przede wszystkim dla odbiorcy (można w tym celu posłużyć się metodą  sortowania kart – card sortingiem).

Powyższy przykład jest raczej przykładem skrajnym i nie rekomendowałbym nikomu umieszczania takich kategorii na swojej stronie e-commerce ;). Jednak w trakcie tworzenia takowych, każdy projektant powinien zadać sobie pytanie „Jak zamieszczone na stronie informacje będą wykorzystywane przez użytkowników?”. Erick Reiss miał rację twierdząc, że wszyscy jesteśmy architektami informacji.

Niby każdy wie, ale warto od czasu do czasu o tym sobie przypomnieć.

Zainteresowanych tematyką architektury informacji zachęcam do zapoznania się z książką Architektura Informacji autorstwa wspomnianego wcześniej Pana. Polskie tłumaczenie pierwszego rozdziału książki można znaleźć tutaj.

Aplikujesz? Stwórz sobie personę pracodawcy

Moja o kilka lat młodsza koleżanka aplikuje na staż. Poprosiła mnie niedawno żebym rzucił okiem na jej CV oraz list motywacyjny, który zamierzała wysłać do swojego potencjalnego chlebodawcy. Trudna rzecz do zrobienia. Wiem coś o tym. Napisanie mojego pierwszego listu motywacyjnego zajęło mi 4 godziny. Przez ten czas zapełniłem tekstem 1/3 kartki formatu A4. Rzucę okiem, a co. Poza tym, byłem żywo zainteresowany jak próbują się „sprzedać” na rynku pracy osoby niezwiązane z branżą UX.

Było źle.

Musisz wiedzieć drogi czytelniku, że w naszej firmie to właśnie ja zajmuję się rekrutacją ludzi na stanowiska UX`owe. Mam więc całkiem niezły punkt odniesienia (dwie setki przeczytanych listów motywacyjnych i CV, kilkadziesiąt przeprowadzonych rozmów). Zacząłem od listu. Moje oczy zobaczyły jedno wielkie lorem ipsum. Tekst zajmował ponad stronę. Było coś o wyzwaniach,  samodzielności, odpowiedzialności. Gdybym nie znał koleżanki, po przeczytaniu samego listu, miałbym problem z określeniem kto i dlaczego do mnie pisze. A ona jest przecież naprawdę fajną osobą.

Zaczęliśmy zmieniać

W międzyczasie wpadł do nas z wizytą mój korpokolega. Jest on odpowiedzialny za rekrutację w swoim dziale. Zaproponowałem, żeby ocenił niezależnie zawartość listu z jego perspektywy. Ja już swoje zdanie miałem wyrobione. Ponieważ list kierowany był do korporacji, kolega nadawał się do tego wręcz idealnie. Przed jego przyjściem padło stwierdzenie, że aplikacja jest kierowana do korporacji i taki język jest OK. Że w dużych firmach na pewno nie szukają takich ludzi jak w naszej, małej. Byłem ciekawy czy nasze punkty widzenia będą ze sobą zbieżne.

Zaczął czytać.

- Ej, a dlaczego tutaj są takie okrągłe zdania? Zapytał korpokolega.

- Co to znaczy „okrągłe”? Odparła koleżanka.

- No wiesz, takie że jak czytam to zanim dojdę do jakiejś informacji o Tobie, muszę przebrnąć przez te wszystkie niepotrzebne słowa. Przecież jak to zobaczą Panie z HR`u, to będą się zastanawiały czy Ty też tak gadasz na żywo.

Koleżanka nie wytrzymała.

- Ale oni uczą nas tak pisać na studiach!

Jeżeli tak uczą na studiach, to z mojej perspektywy, uczą źle.

List motywacyjny jest dla mnie bardzo ważnym elementem rekrutacji. Cefałki na pewnym poziomie abstrakcji są do siebie bardzo podobne. Pokazują czy kandydat miał okazję otrzeć się o obszary wewnątrz których będzie się poruszał w firmie do której aplikuje. List motywacyjny pozwala ocenić czy ktoś rozumie dlaczego chce u mnie pracować oraz czy poświęcił choć chwilę na zapoznanie się z działalnością firmy.

Bardzo nie lubię „masówek”, czyli maili z zapytaniem o staż/pracę, które można wysłać za jednym zamachem do 50 różnych firm. Mam taką fajną zasadę, która pozwala sprawdzić czy komuś naprawdę zależy na pracy w naszej firmie. Podmieniam jej nazwę w miejscach w których występuje i patrzę czy list się klei. Jeżeli po takim zabiegu list nadal jest składny, to źle. Gdybym to ja oceniał list koleżanki jako pracodawca, byłoby źle. Zabrakło sprofilowania przekazu. Persony. O co konkretnie mi chodzi?

Trafiliście kiedyś na taką reklamą że pomyśleliście „Łał, ten przekaz naprawdę MNIE kręci!”? Jeżeli tak, to nadawca doskonale wiedział do kogo mówi oraz wykonał kawał dobrej pracy formułując komunikat.  Jednym ze sposobów dopasowania przekazu do grupy odbiorców jest stworzenie persony – hipotetycznego, acz reprezentatywnego  odbiorcy. Uwzględnienie perspektywy odbiorcy pozwala na personalizację i weryfikację swoich pomysłów na przekaz. Rzecz często stosowana w projektach z zakresu: user experience, designu, marketingu. Rzecz, która mojej koleżance pozwoliłaby na stworzenie listu skierowanego do kogoś… a nie do każdego.

Przy spotkaniu twarzą w twarz można oddziaływać na drugą osobę na wiele sposobów (tak samo jak strona internetowa oddziałuje na użytkownika na kilku płaszczyznach). Można się ładnie ubrać, uśmiechnąć, zażartować i nawiązać do wspólnych zainteresowań. W momencie kontaktu z wydrukowaną kartką papieru, to wszystko znika. 

Ja z kolei zacząłem się zastanawiać, jakie cechy u kandydata cenię najbardziej. Doświadczenie? Kierunek studiów? Ukończone kursy?

Hobby

Branża UX jest patchworkiem ludzi z różnym bagażem doświadczeń oraz kompetencji. Doświadczenie zawodowe jest ważne. Z drugiej strony, jakiego doświadczenia można oczekiwać od juniorów (koleżanka z początku wpisu jest młoda). Ukończony kierunek studiów jest chyba najsłabszym wyznacznikiem tego czy ktoś „się nadaje”. Zarysowuje jedynie obszar wiedzy teoretycznej, którą może posiadać kandydat.

Zawsze zwracam uwagę na rubrykę „zainteresowania”. Rubrykę przez wiele osób ignorowaną (zarówno piszących, jak i czytających). Im dziwniejsze pozycje tam znajdę tym lepiej. Jeszcze lepiej, jeżeli hobby uprawiane jest z dala od komputera.

Dlaczego?

Bo to wybrałeś sam, nikt Ci nie kazał. Bo to pokazuje, że potrafisz się w coś zaangażować. Bo mogę wnioskować, że jesteś osobą samodzielną. Bo mogę się domyślać, że nie robisz tego co wszyscy dookoła i masz własne zdanie. Kiedy próbuję zbudować sobie obraz osoby, która do mnie aplikuje (tak, personę, i wiem że to „płytkie”, ale umieszczenie zdjęcia w CV bardzo mi w tym pomaga) zastanawiam się, jakie są jej motywacje do pracy. Bazując na tym co znajdę w liście, staram się dociec czy jest to odpowiedni „materiał” na członka naszego zespołu. Informacje o zainteresowaniach są tutaj bardzo pomocne.

W przypadku naszej firmy sprawdzili się ludzie z pasją, którzy swoje zaangażowanie potrafią przenieść na grunt zawodowy. Często uzewnętrznieniem takiej pasji jest prowadzenie bloga (uwielbiam ludzi z blogami, ich właściciele komunikują się z reguły sprawniej niż reszta świata). Jeżeli ktoś jest w stanie poświęcić godziny swojego wolnego czasu na szlifowanie jakiejś umiejętności, ma u mnie dużego plusa. Jeżeli masz to „coś” i widzę że rozumiesz dlaczego chcesz pracować właśnie w naszej firmie, najprawdopodobniej przyłożysz się do tego żeby być dobrym w tym czym będziesz się u nas zajmował.

Poza tym, posiadanie hobby zmniejsza ryzyko nudzenia się ;)

What, How, Why

Simon Sinek twierdzi, że większość z nas komunikuje się mało chwytliwy sposób. Mówimy „co robimy”, czasami mówimy „w jaki sposób”, bardzo rzadko natomiast „dlaczego”. Jeżeli komunikat ma być interesujący dla odbiorcy, powinniśmy zaczynać właśnie od drugiej strony. Zdaniem Sineka, zmiana tego kierunku wyjaśnia przewagę pomiędzy średnimi, a wyjątkowymi ludźmi i firmami. Znaczenie przekazu o charakterze „dlaczego” odgrywa tutaj kluczową rolę.

CV mówi „co”, list motywacyjny odnosi się do sfery „dlaczego”. I dlatego jest on dla mnie tak istotny.

Podsumowując. Zaadresowanie przekazu pod konkretną firmę może zwiększyć jego skuteczność. Warto zastanowić się, kto będzie odbiorcą każdego przekazu i jaką reakcję u niego wywoła. Każdy pracodawca będzie cenił sobie bardziej inny zestaw cech, a kandydat powinien włożyć trochę pomyślunku w odpowiednie zaprezentowanie swojej osoby.

A jeśli ktoś jeszcze nie jest przekonany, zachęcam do zapoznania się z tym wpisem, w którym autor w bardzo dosadnej formie wyjaśnia czego powinno się unikać tworząc list motywacyjny i CV.

Post Navigation

Follow

Otrzymuj każdy nowy wpis na swoją skrzynkę e-mail.

%d bloggers like this: