play_arrow
036 – Największy zespół UX w Polsce tomaszskorski
W piątym, spóźnionym odcinku rozmawiam z Michałem Aleksandrem, kierownikiem działu UX w międzynarodowym koncernie edukacyjnym Pearson. Rozmawiamy między innymi o:
Podcast jest dostępny w iTunes, TuneIN i Sticher.
play_arrow
005 – User Experience I projektowanie w dużej korporacji
tomaszskorski
Podcast: Play in new window | Download (Duration: 1:24:42 — 77.7MB) | Embed
Niniejszy tekst jest zredagowaną wersją rozmowy, zawierającą niewielkie uproszczenia i skróty w stosunku do zapisu dźwiękowego.
TS: Cześć Michale. Miło Cię widzieć i słyszeć.
MA: Wzajemnie.
TS: Czy możesz się przedstawić? Opowiedzieć czym się obecnie zajmujesz, jak się nazywasz, i skąd się wziąłeś w User Experience.
MA: Nazywam się Michał Aleksander. I UX zajmuję się od prawie siedmiu lat. Początkowo projektowałem dla Allegro. Od ponad roku jestem w Pearsonie, gdzie stworzyłem i zajmuję się zespołem projektantów UX. Pearson to jest firma, która o tyle różni się od Allegro, że skupia się na głównie na druku. Natomiast ma kilka takich firm, które są przedsionkami technologicznymi. Jedna taka firma jest właśnie w Poznaniu. Pracuje tam w tej chwili około 150 osób. Można powiedzieć, że jest to średniej wielkości firma w której staramy się robić UX-y.
TS: Świetnie. A Ty skąd się wziąłeś w UX? Zanim zacząłeś pracować w Pearsonie, pracowałeś w Allegro. I o ile mnie pamięć nie myli (a sprawdziłem to wczoraj na Twoim LinkedInie), skończyłeś studia dziennikarskie.
MA: Tak. W ogóle w tym czasie, kiedy kończyłem studia i myślałem o swojej karierze zawodowej, byłem święcie przekonany o tym, że będę dziennikarzem. Z gazetami miałem do czynienia już od szkoły średniej, gdzie współpracowałem z lokalnym dziennikiem. Z wiekiem, na studiach, uderzałem do wojewódzkich gazet, gdzie starałem się też złapać więcej doświadczenia. W miarę mi się to podobało. Ale im bardziej byłem bliski skończenia studiów, tym bardziej wiedziałem, że to nie jest ten kierunek w którym chcę iść.
Takim wydarzeniem, które wtedy najbardziej odcisnęło się na tej decyzji to była praca w pewnym dzienniku wrocławskim, w którym zobaczyłem, że dziennikarstwo w praktyce mocno się różni od tego co sobie wyobrażałem, czyli od szukania tematów, robienia fajnych rzeczy. Bardziej jest to walka o czołówkę nie zawsze fair. I w tej gazecie wytrzymałem jakieś trzy tygodnie, po czym doszedłem do wniosku, że moja psychika na pewno nie powinna być spaczona takim miejscem.
TS: Najpierw dziennik i próba pracy we Wrocławiu…
MA: … a później przeprowadzka do Poznania. Dostanie się do Allegro w momencie, kiedy ta firma miała chyba około 150 osób, czyli podobnie jak Pearson teraz. Kiedy tak naprawdę nie było potężnie ukształtowanej struktury. To znaczy, wszyscy się znali, zwracając się do siebie po nickach “allegrowych”. Nie było obcych osób z którymi się pracowało. Była taka rodzinna atmosfera, którą myślę że mocno wprowadzał Arjan Bakker, który wtedy Allegro zarządzał.
TS: Struktura, jak zgaduję, była też relatywnie płaska? Bo przy 150 osoba ciężko, żeby to było nadmiernie rozbudowane.
MA: To był rok 2005, czyli prawie już 10 lat temu. Więc sporo się zmieniło w tym czasie. Wtedy w Allegro nie miałem na początku kwestii związanych z UX-em. Bardziej moja praca szła w kierunku bezpieczeństwa i przestępczości internetowej, co było dosyć ciekawe.
Natomiast wtedy były duże możliwości migracji wewnętrznej, w zależności od tego co Cię interesowało, w czym byłeś dobry. Byłeś w stanie skorzystać z szansy i wylądować w zupełnie innym dziale. I tak dawać firmie trochę więcej, zajmując się tym co Cię bardziej interesuje. W ten sposób właśnie trafiłem do zespołu projektantów użyteczności, który powstał i który składał się na początku z, bodajże, czterech osób. Dawał szansę osobom, które interesowały się optymalizacją, użytecznością, które w jakiś sposób rozumiały czy wyczuwały ten temat. Dawał szansę na to, aby stać się projektantem i wesprzeć projekt Allegro od tej strony.
Tak trafiłem do zespołu projektantów w którym byłem jakieś sześć lat.
TS: Strasznie długo!
MA: Strasznie długo. Zespół mocno się rozwijał. W tej firmie jest to pewien, być może, standard. W tej chwili około 20 osób. Dosyć fajnie to wszystko wyglądało, jeśli chodzi o wsparcie zespołu.
Na początku pracowaliśmy w waterfallu, więc specyfika była zupełnie inna. W momencie w którym został wprowadzony SCRUM, zostaliśmy przydzieleni do konkretnych obszarów, zespołów, to wtedy to stało się bardziej dynamiczne. Generalnie było sporo pracy.
TS: Robiąc króciutką dygresję – widzę teraz, że Allegro często poszukuje projektantów mobile UX. Czy w Twoim odczuciu takie rozróżnienie na projektantów, którzy się zajmują aplikacjami i serwisami mającymi działać głównie na desktopach i takich projektantów, którzy się specjalizują w mobile’u, jest sensowne, czy raczej mimo wszystko powinniśmy iść w stronę tego, że my zajmujemy się medium a interfejs bądź touchpoint jest wtórny?
MA: Właśnie się zastanawiam z czego to może wynikać. Czy to chodzi o doświadczenie w produktach mobilnych, które przyspieszy proces adaptacji danego projektu? Różnica między mobilem, a desktopem to tak naprawdę to są standardy, to są styleguidy, to są przypadki użycia…
TS: Jakieś minimalnie inne interakcje, dodatkowe przyciski bądź ich brak.
MA: Trochę sobie nie wyobrażam, aby ktoś potrafił aplikację mobilną, a nie miał świadomości jak zrobić stronę internetową. Wydaje mi się, że to jest ze sobą koniec końców powiązane. Mimo wszystko, użytkownik ma dotrzeć do produktu różnymi ścieżkami. Dobrze by mieć świadomość i wiedzę jak się projektuje produkt, a nie tylko jak się projektuje aplikację mobilną.
TS: Czy na konkretne typy platform.
MA: Myślę, że tutaj chodzi o kwestię doświadczenia i szybkość adaptacji. Zgadując.
TS: Brzmi bardzo prawdopodobnie. Swoją drogą, ja nie mam bardzo religijnego stosunku do Wróblewskiego, a mam wrażenie że na tym wczorajszym spotkaniu w UX BookClubie bardzo mocno to wyglądało, że tutaj Luke Wróblewski powiedział to, Luke Wróblewski powiedział tamto.
MA: Ja Luka Wróblewskiego polubiłem, bo na samym początku, kiedy zaczynałem projektowanie, to już był problem w którym kierunku iść i co czytać. Są gdzieś takie klasyczne pozycje jak “Don’t make me think”, ale pamiętam że Luke Wróblewski był taką pierwszą osobą, która najbardziej na mnie wpłynęła.
Bardzo mi się podobało to w jaki sposób na swoich warsztatach, które oglądałem na video, wyrażał się na temat interfejsu, w jaki sposób argumentował pewne rzeczy i rozkładał je na czynniki pierwsze.
Pomyślałem wtedy, że to jest sposób mówienia o tym, który mi się podoba, i że chciałbym kiedyś mieć podobne umiejętności do tego, żeby mówić o interfejsie.
TS: Zgadzam się z Tobą, że on jest absolutnie wybitnym komunikatorem. Ja sobie myślę o Luke Wróblewskim, który też w dużej mierze podąża za jakimiś modami w branży UX. Tak uważam. Najpierw to były formularze, potem to było mobile, potem to były start-upy. A teraz jak Luke sprzedał start-up to już nic nie musi robić. Teraz tylko może.
MA: Wiesz, z drugiej strony, kiedy zaczynałem pracować jako projektant to desktop był czymś, co było taki dogmatem. Jak ktoś przychodził i mówił „okej, teraz zajmiecie się tym i tym” to każdy wiedział, że będzie robił coś desktopowego.
TS: Dla mnie Wróblewski jest rodzajem takiego agregatora. To jest taki trochę UX-owy Malcolm Gladwell, czyli że on sam z siebie, mam wrażenie, relatywnie niewiele bada, bardzo niewiele projektuje, ale zbiera te rzeczy, przez to że uczestniczy w bardzo dużej liczbie konferencji i dużo czyta. Prawdopodobnie ma też researcherów, bo nie jesteś w stanie przetworzyć, będąc normalnym człowiekiem, aż tyle. Zwłaszcza uczestnicząc w tylu społecznych eventach. On sie zajmuje tym zbieraniem i taką kondensacją. I też, jeśli chodzi o komunikację, to jest doskonałe sprzedawanie tez i wizji.
MA: Wydaje mi się, że w naszej branży ludzie potrzebują kondensacji. Książek jest już tyle, wiele z nich ma po 300 – 500 stron. Jak patrzę nawet na te książki, które masz u siebie w pokoju. Znajdź kogoś, kto zaczyna pracę jako projektant, i powiedz mu, że to jest wiedza, którą ma wchłonąć. Musiałby się zamknąć i przez pierwsze pół roku nie zdobywać doświadczenia, żeby w ogóle chociaż odrobinę zrozumieć o czym te książki są.
TS: Ja uważam, że tak to powinno wyglądać. Uważam, że ludzie, zanim się zabiorą za projektowanie, najpierw powinni zacząć myśleć.
A bez tych bezpiecznych, minimalnych podstaw nie powinni się za to zabierać. Tak jak się zgadzamy, że (Axure, UXPin, Balsamiq to są tylko narzędzia, ale podstawą jest dobry kościec. Mieć w odpowiedni sposób ugruntowane podstawy, a dopiero potem próbować coś projektować, coś robi.
Najpierw zrozumienie co z czego wynika. Oczywiście praktyka też jest bardzo ważna, i na kolejnych etapach jest wszystkim, ale zdobycie wiedzy na temat tych podstaw jest bardzo istotne.
MA: Tu się zgadzam. Natomiast, bardziej mi chodzi o to, że jak pamiętam siebie z drugiego roku projektowania, np. z trzeciego, to tych książek było tak dużo, że ciężko było wyczuć, która książka powinna być w jakiej kolejności.
Często było tak, że te książki sprzedawały jakiś konkretny koncept, albo jakąś potężną dawkę wiedzy, z której nie byłeś w stanie skorzystać w stu procentach w swojej pracy. To gdzieś tam punktowo wyskakiwało w formie wiedzy, którą miałeś za darmo wcześniej. Tych książek jest tak dużo, że ciężko zrobić sobie samodzielnie przed rozpoczęciem w ogóle jakiejkolwiek styczności praktycznej z projektowaniem.
Ciężko obecnie ustalić teraz ścieżkę, że np. przeczytam te 10 książek w takiej kolejności i będę gotowy do tego, aby odpalić Axure-a. Wydaje mi się, że jest o trochę trudniej teraz, jeżeli chodzi o projektowanie UX.
Mimo że są szkoły, że są kierunki dedykowane do tego, to tak naprawdę, chyba o tym wspominałeś, tutaj może być bardziej takie uniwersyteckie podejście. Że uczysz się teorii, żeby potem zacząć wchodzić w świat praktyki. Nie wiem czy to jest okej. Nie wiem czy to jest dobre i bezbolesne wejście w projektowanie.
TS: Wiesz co, to może wynikać z tego, że ja pochodzę z rodziny akademickiej, od dwóch pokoleń. Pewne rzeczy mi się wydają naturalne. Ale wydaje mi się, że to działa.
Projektant, który zaczyna od razu projektować nie ma absolutnie żadnej pokory. Wydaje mu się, że to co robi jest dobre. Bardzo często tak jest, że nie potrafi wyjaśnić dlaczego pewne robi.
Oczywiście czasem się zdarza, że ma genialną intuicję, albo ma dar, który pozwala mu odpowiednie rzeczy projektować, które są w dobry sposób robione. Ale czym innym jest dar, a czym innym wiedza poparta doświadczeniem.
MA: Kierunek w stronę książek o UX jest jak najbardziej czymś oczekiwanym od osoby, która chce projektować. Książki, blogi, cokolwiek.
Natomiast wydaje mi się, że takim lepszym sposobem na wejście do takiego praktycznego projektowania jest znalezienie firmy, która szuka praktykantów, mając przy tym mocno wyżłobione koleiny, po których, jak się wejdzie do takiej firmy, to po prostu idziesz po nich w odpowiednim kierunku zdobywania wiedzy.
TS: Idąc za ciosem – czy Pearson szuka stażystów?
MA: Pearson szuka stażystów. Ale mam na myśli w ogóle firmy duże, w których są zespoły UX-owe i które istnieją od wielu lat, gdzie są wypracowane jakieś metody, zasady, jakiś sposób funkcjonowania.
Wydaje mi się, że wsparcie nauki teoretycznej takim stażem może być czymś co maksymalnie przyspieszy ten pierwszy krok wejścia.
TS: W swojej książce po części napisałeś jak wyobrażasz sobie jak wygląda idealny flow projektowy. Natomiast ciekawi mnie, jak ten flow obecnie wygląda w projektach, które realizujecie w Perason-ie?
Pytam o to, ponieważ rozmawiam z różnymi ludźmi jak to wygląda w start-upach, jak to wygląda w administracji publicznej, korporacjach, zwłaszcza tych zmieniających swoje podejście do UX, aby dowiedzieć o firmie i podpatrzeć różne tricki czy sztuczki, które możemy realizować, a tak można dowiedzieć się najwięcej.
MA: Jeśli chodzi o Pearson to po pierwsze trzeba wziąć pod uwagę, że nasz zespół jest dosyć młody. To jest rok, może mniej, kiedy funkcjonujemy razem i jest to więcej niż jedna osoba.
Przez pierwsze miesiące, które tam spędziłem, byłem jedyną osobą zajmującą się UX. Po paru miesiącach pojawiły się kolejne i nagle zaczęliśmy tworzyć zespół. I to był moment w którym musieliśmy dojść do wniosku jak funkcjonować wewnątrz firmy.
To też dotyczyło tego w jaki sposób mieliśmy podchodzić. Jedną z takich istotniejszych rzeczy, które dotyczą procesu projektowego to jest to, że staramy się robić wszystko w parach. Ja jestem przeciwnikiem tego, aby projektant zgadywał co może być dobrym rozwiązaniem, żeby sam generował jakieś pomysły i sam je rewidował, bo nie jest w stanie tego zrobić w sposób obiektywny, w miarę wartościowy dla projektu.
Staramy się pracować razem. Po zebraniu takich wymagań biznesowych, które spadają do nas od Product Ownera, zderzamy się jeszcze ze światem technologicznym. Nie myślimy o tym, w którym kierunku pójdziemy projektowo, ale rozpoczynamy od jakiejś idei, którą później, np. na warsztatach z deweloperami, staramy się zderzyć z ograniczeniami technologicznymi.
Myślę, że jest wiele przypadków, kiedy jesteś w stanie wybrać nieco inne rozwiązanie UX-owe. Stawiasz na dziesięć rozwiązań UX-owych, osiem się sprawdzi. Jedno jest super, inne jest fatalne. To wszystko później można przetestować. Natomiast często z punktu widzenia technologii produktów, które istnieją dłużej, to Twoja decyzja UX-owa może mieć dosyć potężny wpływ na to jak będzie się realizować zadanie, które Ty zaprojektowałeś.
Wydaje mi się, że ten kierunek zderzenia idei z ograniczonymi możliwościami technologicznymi jest czymś co jest bardzo wartościowe, a z drugiej strony pozwala trochę wciągnąć deweloperów w tę grę pod nazwą „proces projektowy”. Oni nie dostają później czegoś co mogą potraktować jako ciało obce, którego nie rozumieją dlaczego tak zostało stworzone. Na takich spotkaniach dosyć fajne jest to, kiedy pokazujemy jakiś koncept i mówimy dlaczego chcielibyśmy tak zrobić, a później pytamy, jak to wygląda od strony backend-owej, co jest nie tak, jakie requesty są wysyłane, albo kiedy jakiś request może spowodować, że coś będzie trwało dłużej niż powinno.
Z naszego punktu widzenia, jeżeli mamy produkty, które już istnieją od iluś lat, to też nie chcemy żeby ładnie wyglądający interfejs ładował się długo. Po tym wszystkim mamy wkład w tworzenie takiego prototypu klikanego. Tutaj głównie używamy albo Axure albo UXPin, a później staramy się wprowadzać testy, które są problematyczne, jeżeli chodzi e-learning. Dlatego że w e-commerce, który wcześniej mocno poznałem, praktycznie otwierałeś drzwi firmy, wyciągałeś pierwszą lepszą osobę, była użytkownikiem Twojego serwisu, albo Twojej aplikacji.
Natomiast tutaj role są nieco bardziej skomplikowane. Podstawową relacją jaka jest istotna, kiedy mówimy o użytkownikach, to jest nauczyciel i uczeń. To są osoby, które są jakby odcięte od tego świata, który jest dla Ciebie na co dzień, szczególnie jeśli robisz projekt globalny, gdzie okazuje się, że ten nauczyciel nie znajduje się w jakiejś szkole polskiej, ale np. w szkole w Peru albo w szkole w Argentynie, i że tym bardziej ciężej do nich dotrzeć i wykorzystać ich w projekcie, który akurat w tym momencie realizujesz.
Bronimy się trochę testami zdalnymi. Są one jednak trochę trudne do zorganizowania. Myślimy też o tym, aby jakoś mocniej uderzyć do szkół polskich i zobaczyć jak wygląda ten proces nauki, ta relacja między nauczycielem i uczniem. Natomiast to też jest problematyczne, bo nie można sobie sobie tak po prostu wejść do szkoły, usiąść na lekcji i zacząć notować.
TS: Wyciągnąć dyktafon…
MA: Dokładnie. Tutaj jest problem organizacyjny, chociażby już na poziomie dyrekcji, z którą trzeba się porozumieć i uzasadnić to co tak naprawdę chcemy robić. Jest problem z nauczycielem, żeby znaleźć takiego, który zaakceptuje że ktoś obcy przyjdzie i będzie nie wiadomo co notował.
Trzeba też wziąć pod uwagę, że w momencie kiedy usiądzie się w takiej sali w której są dzieci, studenci, to też zmienia się troszeczkę tę atmosferę wewnątrz. Generalnie temat testowania jest ciężki. Jak mamy możliwość to testujemy, jak nie to staramy się wszelkimi możliwymi sposobami zrobić cokolwiek zdalnego, aby dostać jakiś feedback.
Często ten feedback jest bardzo wartościowy, szczególnie dlatego że nauczyciele to jest specyficzna grupa, która przez większość dnia nie ma dostępu do komputera. Szkoły są w różny sposób…
TS: Mają osobne sale informatyczne, a komputer nie jest integralną częścią procesu nauczania, ale jest bardziej jak W-F, szukając jakiejś analogii.
MA: Myślałem, że bardziej naturalnym narzędziem jest tablica multimedialna, która się pojawia w szkołach.
TS: Naprawdę? Od kiedy skończyłem liceum… 14 lat temu moja noga chyba w żadnej szkole nie stanęła.
MA: Parę lat temu tablice multimedialne były czymś nowym, ale teraz są szeroko wykorzystywane. Wiem, że w kilku szkołach poznańskich jest to podstawowe narzędzie.
Natomiast jeśli chodzi o komputery to rzeczywiście tutaj jest problem, bo zazwyczaj sale informatyczne dają tą możliwość, kiedy i nauczyciel i uczniowie mają dostęp do komputera podczas zajęć. Jak możemy się domyślić, tego typu warunki mogą wystąpić w sytuacji, kiedy np. kończy się semestr i mamy klika godzin wolnych, więc pójdziemy do sali komputerowi i pobawimy się w jakieś platformy e-learningowe czy cokolwiek innego.
Jeżeli chodzi o ten proces projektowy to na pewno warto uwzględnić istnienie KPI, które się opracowuje z Product Ownerem. Z mojego punktu widzenia, KPIs są nie tylko wartościowe dla biznesu, ale z punktu widzenia UX-a to jest coś co pozwala Ci zwiększyć wartość Twojej pracy.
TS: I czy w ogóle ta wartość występuje czy nie. Jakie to są KPI, możesz powiedzieć?
MA: Mogę dać jakiś przykład. Jeżeli masz platformę e-learningową w której nauczyciel pełni rolę kogoś, kto wchodzi i przydziela zadania, a uczeń jest tym, kto loguje się i te zadania wykonuje, a te zadania są automatycznie, albo z pomocą nauczyciela sprawdzane, no to w tym wypadku np. w projekcie, który dotyczy przypisywaniu tego typu zadań, na pewno KPI będzie to ile zadań zostało przypisanych. Albo jak często ten nauczyciel skorzystał z konkretnej funkcji, która dotyczy przypisywania. Żebyśmy np. mogli stwierdzić, że rzeczywiście ten projekt, który powstał z jakiejś potrzeby, czy biznesowej czy zdiagnozowanej, wpływa na zmianę tego środowiska w postaci platformy. Że nauczycielom będzie np. łatwiej korzystać z tej opcji i wykonywać rzeczy tak, jak wcześniej chcieli robić. Jeżeli to się uda, no to fajnie. Jeżeli nie to wiadomo, że gdzieś trzeba coś poprawić.
Dla mnie jako projektanta i osoby, która też interesuje się tym w jaki sposób jej praca wpływa na produkt, to wydaje mi się, że to jest najlepszy sposób, który daje możliwość zmierzenia typowego UX.
TS: Ja uważam, że KPI są jak najbardziej potrzebne. Tylko że proces mierzenia czy użyteczności, czy doświadczeń użytkownika jest bardzo ciężki. Z rozmów jakie prywatnie prowadzę wynika, że raczej nie jest popularny, ponieważ nie ma zapotrzebowania pochodzącego „z góry” bądź z zewnętrznych instancji, które by pozwalały. Myślę też, że projektanci się częściowo boją tego.
MA: To jest rewizja Twojej pracy, jakości Twojej pracy. Natomiast ja w swoim doświadczeniu zawodowym spotykałem się z KPI-ami, które były dosyć naturalnym elementem. Raczej każdy rozumiał co one oznaczają.
Możesz realizować projekty w obrębie jakiejś firmy, ale wiadomo że te projekty muszą przynosić realną korzyść. Jeżeli Ty jako projektant dostajesz konkretne zadanie to musisz zdefiniować problem.
Jeżeli zdefiniujesz ten problem to wiesz co powinno być zmierzone na początku, a co na końcu, żeby wiedzieć czy w ogóle udało się ten problem rozwiązać.
TS: Ale to, widzisz, powoduje że UX przestaje być mambo jumbo, które jest w stanie wykonywać każdy, ale staje się realną korzyścią dla organizacji, która się przekłada na konkretne pieniądze i staje się odpowiedzią, czy konkretny projekt przyniósł korzyść finansową różnego rodzaju, bądź zwiększył satysfakcję użytkowników, a przestaje działać na poziomie deklaratywnym.
MA: Tak mi się wydaje. Nasza rola to nie jest tylko projektowanie. Projektowanie to jest tylko kilka procent naszej aktywności, którą powinniśmy robić.
Z jednej strony mamy jakieś aktywności ewangelizacyjne, które pokazują jak można zmienić firmę wewnątrz firmy, ale z drugiej strony mamy szereg różnych procesów wobec których odpowiedzialny UX nie może być obojętny.
Proces wytwarzania produktu często opiera się na różnych problemach, najczęściej związanych z tym, że ludzie ze sobą nie rozmawiają, albo nie przekazują sobie odpowiedniej ilości informacji. W momencie, kiedy UX wchodzi w taki proces, w momencie kiedy go pozna i zobaczy co nie działa, to wydaje mi się, że jakąś częścią jego obowiązków jest to, żeby ten proces usprawnić. Dlatego, że on, chcąc wytworzyć jakąś jakość UX-ową, to ta jakość musi być zrobiona w tym procesie, przez tych ludzi, którzy uczestniczą w tym procesie.
TS: A co w sytuacji, kiedy KPI związane z satysfakcją użytkowników bądź czasem, który mają poświęcać na przydzielanie tych zadań, używając tego jednego z przykładów podanego przez Ciebie, nie zostaje spełniony? Co wówczas? Twoja rola zmniejsza się? Czy jest to argument i dowód, że UX niekoniecznie ma zawsze znaczenie?
MA: Projekty w różny sposób się kończą źle. Natomiast z tego co widzę, najczęstszą reakcją firm na tego typu sytuację jest spotkanie i porozmawianie o tym czego się nauczyliśmy z porażki.
Czasami różne są wnioski, które płyną z tego typu spotkań. Nie zawsze to są wnioski, które wpływają na to, jak będziemy pracować później. Jest to po prostu taki rytuał kończenia pracy nad jakimś projektem. Niezależnie od tego czy projekt upadł, bo został zamknięty zanim został zakończony, czy skończył się fajnie. Wydaje mi się, że to jest coś co najczęściej można spotkać w firmach.
TS: Chciałęm jeszcze podpytać o szczegóły tego procesu, który realizujecie. Czy cała firma u Was – czy cały Pearson – działa w agile-owym modelu, czy są projekty w typowo waterfallowym sposób realizowane?
MA: Wiesz co, cały Pearson to jest potężna organizacja, która jest podzielona…
TS: Cały poznański Pearson.
MA: Poznański? Poznański Pearson podzielony jest na zespoły SCRUM-owe, które odpowiadają za konkretne obszary. Niektóre z zespołów odpowiadają za ten sam obszar i starają się współpracować ze sobą.
Z większością z tych zespołów współpracujemy. Z niektórymi nie musimy bo zajmują się np. utrzymaniem platform. Poza szybkością działania platformy nie ma tutaj żadnego wpływu, z naszego punktu widzenia, na użytkownika. Natomiast tak, ta część, która odpowiada za technologię i wytwarzanie technologii jest podzielona na scrumowe zespoły..
Myślę, że każda osoba, która miała styczność z jakąkolwiek firmą IT, w momencie kiedy pojawia się w Pearson najłatwiej zrozumienie w jaki sposób to działa, jak funkcjonuje i kto za co odpowiada. W naszym budynku są też osoby, które pracują nad typową treścią edukacyjną. One są zupełnie obok tej technologii, mają swój świat. Swój sposób wytwarzania tej treści.
TS: Cały poznański oddział technologiczny pracuje agilowo, ale prawdopodobnie gdzieś w organizacji pracują projekty w sposób bardziej waterfallowy. W jaki sposób łączynie te dwa światy? Na ile uważasz, że projektant jest się w tym modelu waterfallowym w stanie odnaleźć?
W swojej książce piszesz głównie o tym jak działać w agialowym świecie, a niektóre projekty cały czas działają waterfallowo. W Allegro, z tego co wspominałeś, realizowaliście jakiś projekt w waterfallowy sposób.
MA: Na samym początku, kiedy zaczynałem być tam projektantem, to rzeczywiście był waterfall. Z tego co pamiętam z tamtego okresu, miałem bardzo dużo czasu na projektowanie. Dostawałem dokumentację przygotowaną przez analityka, która była bardzo duża i często miała też wyrysowane elementy interfejsu. Był problem z tym, żeby utrzymać kontakt z projektem do samego końca. Później to po prostu wpadało do ludzi, którzy realizowali to technicznie i nie zawsze dostawaliśmy tę informację, że coś uległo zmianie z jakiegoś tam powodu.
W tym moim doświadczeniu dużych firm w których pracowałem, waterfall średnio się sprawdzał. Był takim głuchym telefonem, który uniemożliwiał skuteczną komunikację.
Dlatego, jeżeli chodzi o duże firmy, wydaje mi się, że SCRUM może być bardziej efektywny. Do takiej współpracy, kiedy łączysz ludzi o różnych umiejętnościach i jednak ten przepływ informacji jest znacznie lepszy. W obrębie zespołów SCRUM-owych ten przepływ informacji jest całkiem dobry. Problem pojawia się w momencie kiedy np. Product Owner przychodzi i nie przekazuje odpowiedniej ilości informacji, albo kiedy projektant UX rzuca jakiś projekt i nie wie dlaczego to jest zaprojektowane tak, a nie inaczej. Nikt nie rozumie dlaczego ma robić to w taki sposób. Wtedy pojawiają się jakieś problemy.
SCRUM jest zdecydowanie po to, żeby usprawnić komunikację wewnątrz dużych struktur. Natomiast waterfall… Podejrzewam, że gdybym miał większe doświadczenie w małych firmach, albo w start-upach, to waterfall bardziej by mi się przydał do takiej codziennej pracy. Byłby sensowniejszy.
Ja przede wszystkimi jestem nauczony podejścia agaile-owego i wydaje mi się, że jest ono bardziej skuteczne. Chociaż wiadomo, że narzuca na projektanta więcej obowiązków, które dzieją się teraz, kiedy musisz reagować w danym momencie, kiedy musisz szybko coś zaplanować. Nie ma po prostu czasu na to, żeby przewidzieć w sobie wszystkie możliwe zdarzenia i punkt po punkcie realizować, tylko trzeba być czujnym. A to oznacza też większy kontakt z zespołem, czyli usprawnia komunikację.
TS: A jak wychodzi to łączenie tych dwóch światów? Masz jakieś doświadczenie jak to można łączyć?
Często jest też tak – według moich obserwacji – że zespoły deweloperskie pracują agilowo przy rozwijaniu produktów, a nie przy realizowaniu projektów, natomiast cała reszta organizacji pracuje waterfall-owo. I wówczas łączenie tych dwóch światów może być pewnym wyzwaniem.
Na przykład, organizujesz jakieś testy, jakichś interfejsów, nie na poziomie UX-owym a technologicznym i czasem ciężko jest to reszcie organizacji zrozumieć.
MA: Ja jeszcze nie miałem takiego doświadczenia z takimi częściami Pearson, żeby stwierdzić że rzeczywiście mają tam waterfall. Być może gdzieś te obszary biznesowe, albo te które do nas nie docierają bezpośrednio, być może one są w taki sposób skonstruowane, jeżeli chodzi o logikę działania.
Natomiast te miejsca, z którymi my mieliśmy styczność jako zespół, to zawsze było spotykanie się z zespołami SCRUM-owymi, jeżeli chodzi o osoby pracujące nad konkretnymi projektami.
Czy to była Argentyna czy to był Urugwaj czy Peru, zawsze po drugiej stronie byli deweloperzy, którzy byli zgrani ze sobą w formie takiego SCRUMu, który – co też bardzo mnie cieszyło – rozumiał czym jest makieta i czym jest kilkalny prototyp, albo jaka jest rola UX. Przynajmniej z tego co widzę, sporo osób w organizacji mniej więcej już więcej została wyedukowana w ten sposób. Nie wszystkie, oczywiście, obszary, ale jest miłe jeżeli po raz pierwszy łączysz się z zespołem i oni wiedzą, czego się mogą od Ciebie spodziewać.
TS: Wraz z tym jak realizujecie kolejne sprinty, kolejne projekty, i wykazujecie, że Wasz dział jest faktycznie potrzebny, prawdopodobnie rośnie zapotrzebowanie na Wasze usługi i Wasze potrzeby. W jaki sposób przydzielane są do Was kolejne projekty? Czy to spada z góry?
MA: Ja od początku starałem się postawić na dobrą relację z product ownerami. Z osobami, które reprezentują biznes czy to w Poznaniu, czy bezpośrednio w UK, dlatego że to są osoby, które są pierwszym punktem kontaktu i które potrafią przekazać Ci informację, że będziemy się czymś zajmować.
Dla mnie to było o tyle istotne, że na długo przed rozpoczęciem jakichkolwiek oficjalnych prac nad projektem, dostawałem informację czym będziemy się zajmować.
Przez to, że wiedza w dużych organizacjach jest mocno rozproszona, i tutaj, jeżeli mamy tak trudnych użytkowników, to czasami poza zwykłymi testami zdalnymi, być może warto byłoby np. przejechać się do ludzi, którzy chodzą do szkół i sprzedają te podręczniki. Tak też zrobiliśmy, zrobiliśmy z nimi warsztaty i dowiedzieliśmy się wszystkiego, co padało podczas…
TS: O to jeszcze chcę zapytać, więc spokojnie. Natomiast zastanawiam się po prostu czy już w tym momencie macie w organizacji proces, który zakłada na którymś etapie angażowanie projektantów, bądź działu UX? Czy dopiero coś takiego się wykuwa? Czy jest to obligatoryjne? Czy jest to opcjonalne?
MA: To już jest. I to jest fajne, dlatego że nawet jeżeli pojawia się gdzieś na horyzoncie projekt i informacja o budżecie to jest informacja o tym, że będzie potrzebny ktoś do projektowania interfejsu, będzie potrzebny ktoś do projektowania graficznego. To też nie jest tak, że musimy się wbijać i pokazywać, że my tutaj chcemy coś zrobić dobrego, tylko rzeczywiście…
Być może nie we wszystkich zespołach to rozumienie kim jest projektant UX jest rozumiane w taki sposób, jak powinno, natomiast to też nie jest tak, że my musimy walczyć o te projekty. Ludzie wiedzą, że będziemy w nich uczestniczyć.
TS: A jak to wygląda od budżetowej strony? Nie chodzi mi o koszty (kwoty) explicite, tylko w jaki sposób to jest rozliczane? Zarówno działy deweloperskie, jaki i projektanci i działy marketingu są zwykle centrami kosztowymi, a nie miejscami, które przynoszą realne dochody. W jaki sposób wewnątrz Waszej organizacji to działa?
MA: Ogólnie mówiąc, każdy projekt ma swój budżet. I ten budżet zatrudnia ludzi, którzy mają realizować dany projekt. To dotyczy też ludzi UX-owych. Natomiast, ponad tymi projektami jesteśmy takim zespołem, którzy może mieć różne źródła budżetowania, ale organizacyjnie jest skupiony w jednym miejscu.
TS: Czyli innymi słowy, Wasze poznańskie centrum kosztowe rozlicza się na poziomie, który być może dzieje się poza Wami, odnośnie wynajmowania tych ludzi do tych poszczególnych sprintów, bądź poszczególnych projektów.
MA: Jeżeli mówimy o samym zatrudnieniu to tak, natomiast wszelkie kwestie związane z organizacją takiego zespołu czy jego funkcjonowaniem to jest też osobna kwestia.
TS: A w jaki sposób budujesz tę wiedzę, że posiadacie dział UX? W jaki sposób budujecie informację jak możecie pomóc? Widziałem na Facebooku, dostałem też od Ciebie materiały promocyjne, bardzo mi się one podobały. Było widać, że staracie się wybudować kulturę i wiedzę wewnątrz organizacji poprzez promocję materiałów marketingowych. Czy możesz coś więcej o tym opowiedzieć?
MA: Tutaj myślę, że kluczowe jest stwierdzenie „strategia UX”.
Jeżeli mamy zespół, który ma realizować projekty UX-owo, to to nie jest tylko zaangażowanie się w same projekty, ale to jest też samoorganizacja, zrozumienie własnej roli i określenie co my tak naprawdę chcemy robić.
My zrozumieliśmy na samym początku to, że jest strasznie dużo pracy do wykonania, żeby ludzie zrozumieli, że my w ogóle jesteśmy, jak można z nami współpracować i czego się można po nas spodziewać.
To jest jeden z takich podstawowych poziomów dojrzałości UX-owej w firmie, kiedy trzeba się mocniej postarać o ewangelizację, żeby wyjaśnić ludziom jakieś pojęcia, które dla Ciebie mogą być oczywiste, ale przez brak tej wiedzy ogólnie możesz mieć problem, żeby skutecznie współpracować.
TS: Czym jest persona, czym się różnią badania ilościowe od jakościowych, itd?
MA: Ludzie mogą mieć pojęcie, jeżeli mieli wcześniej styczność z UX, czym jest dobry i zły UX, bo korzystają z różnych produktów, wiedzą co im się podoba, a co nie. Widzą jakie produkty powstają wewnątrz firmy.
W takim pierwszym etapie doszliśmy do wniosku, że jeżeli mamy pokazać organizacji, że jesteśmy zespołem to musimy tym zespołem się stać. Czyli nie, że jesteśmy ludźmi, którzy spotykają się np. raz w tygodniu, żeby opowiedzieć sobie o projektach, o tym co sprawiło im trudność, albo co było ciekawe, ale że musimy mieć swoją jakąś tożsamość, osobowość zespołową.
Było wiele czynności, które mogą się wydawać trywialne, ale one nam bardzo pomogły.
Na przykład zaprojektowanie własnego logotypu. Albo zaprojektowanie plakatów na których widać było gdzie jesteśmy, gdzie siedzimy, jak się z nami skontaktować, z takim prostym stwierdzeniem, że jeżeli robisz coś dla użytkownika, coś co użytkownik zobaczy to wcześniej daj nam cynka, my Ci pomożemy. Mieliśmy takie sytuacje, kiedy np. rozmawiałem z programistą i mówił, że miał zadanie nad którym siedział, miał je poprawić backend-owo, ale wiedział że interfejsowo też wymagało dopracowania. Z tym, że nie do końca wiedział jak się może z nami skontaktować, mimo że siedział na tym samym piętrze.
Wtedy pomyślałem sobie, że być może warto byłoby w tych miejscach, gdzie ludzie zmieniają produkt siedzą wywiesić tego typu plakaty, żeby dać im taką prostą ścieżkę. Żeby odezwali się na Skypie, na Slacku, na czymkolwiek. Mailowo chociażby. Albo najlepiej, żeby przyszli i powiedzieli, że będą coś robić.
Były efekty bardzo wymierne takiego podejścia, bo mieliśmy sytuacje, kiedy dostawaliśmy cynk od dewelopera, że ma poprawić funkcjonowanie jakiejś rzeczy na stronie, natomiast wiedział, że logika działania tej strony pozostawia dużo do życzenia, że można by to zrobić prościej.
I my we współpracy z nim przygotowaliśmy wersję, która była UX-owo czysta, a z drugiej strony była UX-owo logiczna i zgodna z tym co udało nam się już dowiedzieć o tym, jak działają użytkownicy tych platform. A z drugiej strony był ten obecny stan z jakąś tam formą zmiany. Poprosiłem tego dewelopera, żeby oszacował czas realizacji jednego projektu i drugiego. Okazuje się, że czysta wersja, która zakłada przebudowanie większej wersji, była łatwiej osiągalna technologicznie i szybciej mogła być zakończona, niż poprawienie czegoś co nie było zbyt logicznie zbudowane.
Dla mnie to jest język z którym można iść do Product Ownera i powiedzieć mu słuchaj, chcesz coś co wygląda ładnie i będzie zrobione szybciej, czy coś co wygląda brzydko a deweloper będzie spędzał nad tym więcej czasu. I to jest wtedy sytuacja, kiedy nie możesz przegrać.
Ten kontakt z deweloperami i przekazanie im tej wiedzy jak się z nami kontaktować, jak współpracować głównie osiągnęliśmy za pomocą tych plakatów. Staraliśmy się też wciągać deweloperów do różnych warsztatów. Niektóre były nawet takie pokazowe, czyli po prostu pokazywały ludziom w jaki sposób można wspólnie rozwiązywać problem, i że to nie jest tylko domena osób o UX-owych umiejętnościach.
TS: I że projektanci UX niekoniecznie są wszechwiedzący.
MA: Dokładnie.
I tutaj docieramy do takiego bardzo ważnego słowa „transparentność”. Czyli pokazanie ludziom w jaki sposób my pracujemy i na czym polega nasza praca. W momencie, kiedy wrzucasz do zespołu czystą makietę, nawet jeżeli będzie klikalna i fajna, to ktoś może nie zrozumieć jaki proces poprzedził zrobienie tej makiety.
Jeżeli masz podejście takie jak mówiłem wcześniej, czyli zamiast rysować fajnie byłoby dotrzeć do jakichś informacji, zrozumieć problem i wiedzieć co tak naprawdę masz do zrobienia, to makieta która jest wypluta na sam koniec tego procesu, ona jest tylko takim wierzchołkiem góry.
Jeżeli wrzucasz to do zespołu bez żadnego wyjaśnienia i bez żadnej świadomości po stronie tego zespołu dlaczego to wygląda tak, a nie inaczej, to dla nich to po prostu będzie ciało obce w organizmie.
Ta transparentność jest o tyle fajna, że działa edukacyjnie. Ludzie są w stanie zrozumieć to kim jesteś i jaką rolę pełnisz w organizacji.
Dodatkowo z zespołem wypracowaliśmy kilka fajnych nawyków, jak np. szukanie czasu w trakcie tygodnia, żeby spotkać i pomyśleć o projektowaniu czegoś nowego. I to doprowadziło nas do własnych sketchbooków.
Spotkaliśmy się, bodajże, w lutym i pomyśleliśmy, że fajnie byłoby zrobić coś własnego. Coś co będzie niezależne od tych produktów nad którymi pracujemy, gdzie są procesy powolne w stosunku do tego jak szybko jesteśmy w stanie stworzyć jakiś interfejs w formie idei. Pomyśleliśmy więc, że zrobimy własny produkt i padło na sketchbooki.
W dużym skrócie. Ja np. miałem dużo sketchbooków w ręku i nigdy żaden mi się nie podobał. Wszystkie były po prostu słabe. Albo to były zwykłe notesy, albo były przekombinowane.
Chcieliśmy zrobić coś więcej, to nie miał być taki zwykły notes do szkicowania. Pomyśleliśmy o tym, że określimy taki idealny proces pracy projektanta, który chcielibyśmy żeby był realizowany przez nas, w tej firmie.
TS: A powiedz mi proszę, jaki był koszt wyprodukowania tych sketchbooków, tych książeczek, tych plakatów? Wiem że tutaj schodzę do bardzo trywialnych rzeczy, ale staram się zorientować na ile jest to realizowalne w innych firmach, i na ile jest to budżet w który warto wrzucić.
MA: Na początku wycena drukarni była trochę przerażająca, bo było dużo czynników wpływających na tę cenę. Największy problem był z materiałem na okładkę, albo w jakiś sposób to połączyć tak, żeby dało się to odczepić, albo włożyć kolejnych.
TS: Zdjęcia tych sketchbooków i tych książeczek umieścimy w notatkach do tego podcastu.
MA: Na początku to był koszt około 80 złotych za sztukę.
Natomiast ostatecznie byliśmy mocno zaskoczeni, bo to spadło do około 35-40 złotych, czyli do połowy tej ceny.
Tak naprawdę zamiast tej partii, którą mieliśmy dostać za tę cenę, dostaliśmy dwa razy. Mamy dość duży zapas sketchbooków. W tej chwili zostało nam jakieś 160. Początkowo było 200 sztuk.
TS: A książeczki?
MA: Nie jestem pewien czy dobrze pamiętam, ale to było około 15-20 złotych.
TS: Za książeczkę? I pewnie też wyprodukowaliście ich 200-300 sztuk?
MA: Ich akurat było mniej, bo na początku zrobiliśmy same książeczki, a dopiero później skupiliśmy się na sketchbookach, więc ich jest mniej.
Natomiast widzę, że one też bardzo fajnie się spodobały osobom do których dotarły.
Czy wewnątrz firmy, czy poza nią, żeby też pokazać zespół w Polsce, bo mimo wszystko, jeżeli istnieje się niecały rok czasu, to na pewno większość osób w Polsce nie ma świadomości, że w danej firmie jest w ogóle jakiś zespół UX.
Staraliśmy się więc tę ewangelizację z takiej wewnętrznej trasy przenieść też trochę na zewnątrz, żeby pokazać co udało nam się osiągnąć. To był też miły odzew z wielu stron. W różnych, które do nas napływały, np. od osób, które mają zespoły w firmach i twierdziły, że czegoś takiego potrzebują jako wzorca, żeby wiedzieć w którym kierunku iść.
Zazwyczaj to jest myślenie jak odnaleźć się w organizacji, ale to jest robienie rzeczy po omacku. Więc my staraliśmy się tutaj też opisać to w taki sposób, żeby to była taka gotowa recepta z której możesz ciągnąć i zobaczyć co Ci się uda zaadaptować w firmie.
TS: Mi ta koncepcja tych książeczek i plakatów bardzo się podobała. Zresztą poruszaliśmy ten temat w rozmowie z Marcinem Malickim, odnośnie do tego jak to może wyglądać i podawałem to jako taki wzorcowy przykład.
Przechodząc do trochę innego tematu. Wspominałeś też o tych technicznych ograniczeniach w procesie, że one się pojawiają. To jest naturalne, wiadomo. Na jakim etapie u Was staracie się wyłapywać te problemy? Poza tym, że jak najszybciej?
Interesuje mnie, kiedy dzieje się ta sytuacja, że następuje ta rozmowa pomiędzy deweloperem a projektantem. Świetną rzecz zaprojektowaliście, ale nie ma do tego żadnych sensownych framework-ów i to będzie rzeźba w glinie zanim uda się to zrobić.
MA: Może zacznę od tego, że kiedyś doświadczyłem takiej sytuacji, kiedy zaprojektowałem coś co okazało się ciężko wykonalne i wtedy też zauważyłem, że czasem proste zmiany interfejsu mogą niesamowicie ułatwić pracę deweloperom, więc zacząłem mocno wierzyć w to, że warto ich wciągać możliwie jak najszybciej.
W praktyce, jeżeli wpada do nas jakiś projekt, którym mamy się zająć, staramy się po prostu wytworzyć jakieś pomysły, jakieś idee w oparciu o dane, które są dostępne.
Czyli po prostu kompletujemy informacje. To jest trochę jak zbieranie przez dziennikarza informacje o jakimś wydarzeniu, żeby później być przygotowanym i żeby zrobić coś dobrze i właściwie. Żeby zadać odpowiednie pytania.
TS: Ale to w trakcie sprintu zero robicie?
MA: Dostajemy cynk dużo wcześniej, zanim zespoły się zajmą tą robotą.
Ta informacja to jest nie tylko to co będzie robione, ale też przez kogo. I w momencie, kiedy skompletujemy sobie takie informacje, i czasami też w wykorzystaniu metod agile-owych staramy się je albo pogrupować, albo inaczej przetworzyć, aby przyspieszyć sobie ten cały proces, to tworzymy idee, które są szybko dostarczanymi makietami, żeby też nie tracić czasu na tworzenie sztuki dla sztuki. I wtedy po prostu organizujemy spotkania z deweloperami, bądź – jeżeli nie wymaga to aż tak szerokiego zaangażowania – przegadujemy to z konkretnymi deweloperami, którzy wiemy, że będą się tym zajmować. Oni nam wtedy tłumaczą tę logikę, którą łatwo sobie zaprojektować np. w Axure, od strony backend-owej i mówią co się dzieje w momencie, kiedy platforma dostaje tego typu zapytania. Ale czasami to są jakieś proste, drobne zmiany, które powodują, że nic gdzieś tam się nie będzie krzyżować, ze sobą kłócić. To się okazuje łatwiejsze do osiągnięcia podczas takiej realnej już pracy z zespołem SCRUM-owym. Także staramy się możliwie jak najszybciej rozmawiać.
Zresztą, wydaje mi się, że na chwile obecną, przynajmniej w tym projekcie, który toczy się z moim udziałem i z udziałem drugiego projektanta, to tam mam wręcz wzorcowy kontakt z deweloperami.
TS: A ile realizujecie równocześnie projektów?
MA: W tej chwili doszły nam nowe produkty, ale mniej więcej udawało się zrobić tak, że dwóch projektantów pracowało nad jakimś obszarem w którym mogły być maksymalnie jakieś dwa projekty.
TS: Dwóch projektantów realizujących dwa projekty. A macie łącznie…?
MA: W tej chwili jesteśmy w piątkę, ale niedługo zespół się powiększy, dlatego że doszły do nas nowe produkty, które też wymagały tego, żeby projektować.
To też jest po części odpowiedź na to pytanie, które wcześniej zadałeś. To są produkty, które już zakładają obecność projektantów UX.
To też jest fajne, że nie musimy się o to starać i nikogo przekonywać, że jest to potrzebne.
TS: Tylko taka świadomość już w organizacji po prostu istnieje i jest zaimplementowana w procesie. Zastanawia mnie jedna rzecz, którą napisałeś w swojej książce. Napisałeś tam coś takiego, że jedną z umiejętności projektanto-badacza, UXa ogólnie rzecz biorąc, powinna być możliwość badania wielu rzeczy. Wielu projektów jednocześnie, w ciągu jednego dnia, czy w ciągu krótkiego czasu.
Jak patrzę z naszej perspektywy wydaje mi się to lekkim szaleństwem, ponieważ wywiady pogłębione czy badania użyteczności z użytkownikami potrafią bardzo często trwać godzinę, półtorej i takich ludzi starasz się przerobić pięcioro w ciągu dnia. I jak sobie myślę o tym, że jeszcze miałbym się switchować pomiędzy wieloma projektami jednocześnie, brzmi to jak kompletne szaleństwo.
MA: To bardziej zależało od tego o jakiej wielkości projektach mówimy.
Mi w tym momencie książki chodziło przede wszystkim o to, że w momencie kiedy masz do przetestowania jakąś prostą funkcjonalność, którą zaprojektowałeś, to być może to jest też dobra okazja do tego, żeby podciągnąć sobie do tego scenariusza jeden, dwa zadania więcej i zdobyć informacje na temat czegoś co niekoniecznie musi być robione przez zespół SCRUM-owy, ale może dać Ci jakąś wiedzę na temat czegoś, nad czym się zastanawiałeś w kontekście np. elementu, który wiesz, że przyjdzie nam nad tym pracować, ale np. brakuje nam informacji na ten temat.
Jeżeli zapraszamy już userów na takie badania i spędzamy z nimi czas, to być może warto byłoby dorzucić do tego dwa-trzy zadania więcej, które dorzucą nam wartościowe informacje.
Natomiast jeżeli chodzi o obecną pracę to tutaj mamy trochę bardziej skomplikowaną sytuację, dlatego że nasz użytkownik, po pierwsze, jest specyficzny.
Tak jak wspominałem wcześniej, to może być nauczyciel, to może być uczeń. Jest skomplikowany terytorialnie, bo może się znajdować w Peru, może się znajdować w Chinach. I w tym momencie nie możemy sobie pozwolić na to, żeby zaplanować, że w przyszłym tygodniu przeprowadzimy testy z użytkownikami, którzy docelowo będą korzystać z tego produktu, albo z danej funkcjonalności.
Zresztą, funkcjonalność to podobno nie jest właściwie słowo, tylko mocno zapożyczone. Z danej opcji, z danej funkcji.
I ten problem staramy się rozwiązywać za pomocą testów zdalnych, na przykład. Które też czasami są problematyczne, bo jeżeli testujemy coś np. z ludźmi po drugiej stronie globu to oznacza to, że później zaczynamy pracę.
Ale czasami są to testy, które mieliśmy z np. nauczycielami belgijskimi, więc tutaj dużej różnicy nie było. Wspomagają nas tutaj projektanci z Harlow (siedziba Pearson Education w Wielkiej Brytanii) i tutaj też chodzi o kwestię taką typowo prozaiczną, żeby nie było bariery językowej, żeby prowadzić to w sposób płynny. My obserwując tego typu testy jesteśmy w stanie dobrze dowiedzieć się czy to jest zaprojektowane okej czy nie okej.
TS: Wspomniałeś też wcześniej o Chinach. Czy projektujecie interfejsy w jakikolwiek sposób specyficzny dla azjatyckiego odbiorcy?
MA: Tak. Mamy w zespole dwójke projektantów, którzy pracują nad produktem, który będzie przeznaczony dla Chin.
TS: Ale to jest w języku angielskim?
MA: Tak. To jest produkt, który jest przeznaczony do nauki języka angielskiego. On złożony z resztą z produktu, który będzie dla użytkowników, oraz z produktu, który będzie dla obsługi, dla osób, które będą obsługiwać ten kurs. Tam też były różne problemy związane np. z testowaniem.
Tutaj testy zdalne niekoniecznie mogą dojść do skutku, bo są ograniczenia związane z tym jaka to jest specyfika kraju. Z tego co pamiętam, wykorzystywano do testów osoby, które były mocno powiązane z projektem, natomiast wychowywały się w innym kraju.
TS: A przeprowadzacie jakieś badania natury ilościowej?
MA: Są pewne dane do których udało mi się dotrzeć, bo tak jak mówię, wiele informacji jest rozproszonych, ale mamy dział analityków, który mocno stara się zrozumieć w jaki sposób te produkty są używane, w jakiej częstotliwości, gdzie ewentualnie pojawiają się jakieś problemy.
To czasami są bardzo fajne informacje, które zdradzają nam mentalność zachowań tych użytkowników, czyli to np. jak może wyglądać rok pracy nauczyciela z uczniem, kiedy ta aktywność na platformie może być większa, kiedy mniejsza, z czego to może wynikać.
TS: No właśnie. Jakie macie insighty z tym związane o których możesz powiedzieć?
MA: O których mogę powiedzieć… W ciągu tego roku to, co najbardziej uderzyło w mnie, jeżeli chodzi o użytkowników ze szkół, czyli nauczycieli, uczniów, jest to, że oni mając do dyspozycji produkty cyfrowe często przenoszą tę off-linową relację do produktów on-linowych.
I to się opiera na tym, że najistotniejszym słowem, które się z tym wiąże, jest progres. Uczeń, który się uczy, powinien czuć, że robi postęp. Nie zawsze to uczucie jest.
Na pewno uczyłeś się języka angielskiego i wiesz jak trudno jest dojść do momentu, kiedy wiesz, że okej, dobra, zrobiłem postęp podczas nauki. Ten postęp jest trudny do wychwycenia.
Z drugiej strony, jak ktoś uczy kogoś języka to chciałby mieć kontrolę nad tym, jak ta nauka przebiega nie tylko w klasie. Nawet jeżeli chodzi o taką czystą logikę użycia tych produktów, bardzo mocno widzę, że pojawia się ta relacja typowo z klasy, kiedy uczeń po prostu ma dostać zadanie domowe, albo ma dostać jakieś rzeczy, którymi się zajmie poza klasę, a nauczyciel jest tym, który to zleci a później sprawdzi, oceni.
I to jest obudowane bardzo dużą ilością różnych takich drobnych elementów, jak np. umiejętność odczytania co się tak naprawdę wydarzyło w tej relacji. Czy jeżeli ten uczeń spędził czas na zadaniach to rzeczywiście dało się z tego wyczytać jakie ma problemy, albo czy zrobił jakiś postęp.
To jest więc chyba taki największy insight, że nie możemy myśleć o tym, że w tym produkcie cyfrowym nauczyciel staje się inną osobą, która reaguje w inny sposób i używa innej logiki. To jest raczej po prostu przerzucenie, przeciągnięcie tego co się dzieje w klasie na taką relację nie bezpośrednią, natomiast opartą na tej samej logice.
TS: Wspominałeś o tym, że macie też dział customer supportu, tudzież sprzedawców, który realnie u Was działa i który jest dla Was jakimś sensownym źródłem wiedzy.
Pytam o to dlatego, że staram się znaleźć podobieństwa. My mamy przedstawicieli handlowych, którzy np. jeżdżą po różnych warsztatach i którzy są realną kopalnią wiedzy odnośnie do tego jacy klienci są, w jaki sposób funkcjonują i jakie mają realne bolączki, które w inny sposób by nie przekazali.
MA: Customer service, jest u nas taki zespół. Jest to coś innego niż to o czym mówisz, ale oni też są dla nas źródłem wiedzy. To są ludzie, którzy mają kontakt z użytkownikami, którzy zgłaszają się z jakimś problemem. Co ciekawe, tego typu wiedzę też można wykorzystać do tworzenia KPIs, kiedy rozwiązujemy jakiś problem, np. najczęściej zgłaszany. Ale to już inna historia.
Natomiast jest jeszcze zespół, który jest w Warszawie i który zajmuje się właśnie kontaktem z nauczycielami, ze szkołami i sprzedażą tych produktów. Co też się nie odbywa cały czas, bo tak jak wiemy, podręczniki nie są czymś co kupujesz raz na miesiąc, tylko po prostu zamawiasz podręczniki na cały rok szkolny. Więc to też są takie strzały, które też są jakimś deadline-m. Żeby ten produkt był gotowy do przedstawienia w takiej formie, żeby dały się go sprzedać przed rozpoczęciem roku szkolnego. I te osoby, kiedy się spotykają z nauczycielami, często z tymi, którzy już mieli wcześniej styczność z programem Pearson, to one bardzo często bez większych oporów opowiadają o tym z czym mają problem. Albo pytają się o to co, kiedy może być dostępne.
My spotkaliśmy się z takimi osobami dwa miesiące temu i przeprowadziliśmy z nimi takie mocno agilowe spotkanie, gdzie nie skupiliśmy się na konkretnych kategoriach tych problemów, tylko daliśmy się im po prostu wystrzelać ze wszystkich rzeczy, które mieli w swojej pamięci, że są jakąś bolączką , ale też z drugiej strony, które są np. dobre. Nie mieli tego w żaden sposób kategoryzować. Dzięki temu mieliśmy bardzo dużą wiedzę, którą później sobie wspólnie uporządkowaliśmy pod kątem jakichś takich kategorii tematycznych. Co dało nam też fajny obraz, bo z jednej strony dostaliśmy jakieś konkretne insighty, które zostały zapamiętane podczas konkretnej rozmowy.
To może się przydać np. podczas sesji projektowych. To są takie rzeczy mocno pobudzające. A z drugiej strony mieliśmy też całą listę rzeczy, która w powtarzalny sposób wiadomo było, że jest listą problemów, które trzeba rozwiązać. Dla mnie to było o tyle wartościowe, że w tym momencie, kiedy będziemy siadać do kolejnych projektów to my posiadamy wiedzę o problemach, które są do rozwiązania.
Jeżeli ten projekt będzie zakładał dotknięcie obszaru, którego dany problem dotyczy no to my możemy trochę więcej i sprytniej do tego podejść, czyli rzeczywiście zrobić coś, co użytkownika będzie realną wartością.
TS: Okej. Zamknijmy etap procesu. Jak u Was wygląda proces rekrutacji? Tak jak wspominałeś, Twój zespół jest teraz pięcioosobowy?
MA: Jest pięcioosobowy, ale jeszcze parę osób dojdzie w najbliższych miesiącach.
TS: Jesteście sporą korporacją. Jak u Was działa rekrutacja, zatrudnianie nowej osobowy?
MA: Wiesz co, ja do tej pory, jeżeli chodzi o mój zespół to uczestniczyłem w jednej takiej większej rekrutacji z której zatrudniliśmy dwie osoby.
Generalnie wiadomo, że jest problem, żeby znaleźć osoby, które będą doświadczone w tej pracy. A my z kolei mieliśmy wtedy dużą potrzebę wrzucenia w środek projektu kogoś kto ten czas adaptacji będzie miał możliwie jak najkrótszy. Wiadomo, że wymaga to paru miesięcy poznawania produktu i poznawania zespołu. Ale chodziło o to, żeby to nie była osoba, która będzie się doszkalać, tylko osoba, która już będzie potrafiła wykorzystać swoje umiejętności i doświadczenie.
Było oficjalne ogłoszenie. Też trafiło do Ciebie. Natomiast poza osobami, które się zgłosiły do nas bezpośrednio, ja starałem się osobiście zapraszać ludzi na rozmowy.
TS: Czyli prywatnymi, towarzyskimi kanałami?
MA: Najlepszy do tego, jeżeli chodzi o polskie UX-y, jest Facebook. Tam ta liczba koneksji, sposób w jaki się komunikujemy, czy to poprzez tę grupę Usability PL, czy poprzez takie zwyczajne tagowanie się na zdjęciach z różnych eventów, to to powoduje, że jednak mimo wszystko zdobywamy jakąś wiedzę co ktoś robi, czym się zajmuje.
I wtedy można byłoby, jeżeli ta osoba jest chętna, zaprosić taką osobę na rozmowę i zobaczyć czy przypadkiem nie jest to ktoś, kto by się nam przydał.
TS: Okej. Zdradziłeś mi bardzo niewielki kawałek. Ofertę układałeś Ty, układał dział HR?
MA: Ona się zaczyna od nas, konkretnie. My sprawdzamy jaki jest projekt, jakie jest zapotrzebowanie. Określamy kogo dokładnie potrzebujemy. Mamy, to też jest taka fajna rzecz, którą sobie wypracowaliśmy w zespole, opisane różne poziomy doświadczenia, łącznie ze skillami i z wiedzą.
TS: Ile macie takich poziomów? U nas są trzy w tym momencie.
MA: U nas też są trzy. Na razie wszyscy mają tę samą nazwę stanowiska, ale pewnie będziemy też nad tym pracować.
TS: Czyli junior, normal, senior, jak zgaduję?
MA: Tak. Natomiast jest problem taki, że tego typu gradacja, ona nie istnieje na przykład w Wielkiej Brytanii. Tam jest jedna nazwa stanowiska.
TS: Interaction designer?
MA: Tak. Ona z resztą też… Uważam, że ta nazwa też jest do zmiany, bo nie do końca odpowiada temu czym my się tak de facto zajmujemy, kiedy my też bardziej uderzamy w jakieś procesy, albo zajmujemy się tematem o wiele szerzej niż tylko kwestia tworzenia interakcji.
Na pewno będziemy pracować na to, żeby to szło stronę UX desingera. Albo coś tego typu.
Ale mamy określone te trzy poziomy, które ułatwiają nam tworzenie ofert. Staramy się do działu HR dostarczyć coś co będzie już gotową ofertą, którą wystarczy zrobić kopiuj, wklej, żeby nie było przypadkiem jakichś baboli z zapytaniem o język programowania, czy coś tego typu.
TS:. A co się dzieje potem? Jak wygląda rozmowa?
MA: Na tej rozmowie jestem oczywiście m.in. ja. Sam przebieg rozmowy… Dla mnie najistotniejsze jest, żeby zobaczyć w jaki sposób ktoś myśli i czy za jego pracą, jako projektanta stoi jakichś ciąg przemyślanych decyzji, kroków.
Tutaj ten proces projektowy jest jedną z takich podstawowych rzeczy, którą chcemy zobaczyć. Żeby zobaczyć czy jak wpada jakieś nowe coś do zrobienia, to czy to jest po prostu wzięcie tego i jakoś to uda się zrobić, czy rzeczywiście jest krokowo określony jakiś proces, że okej, najpierw robię to, później to i to. I staram się w każdym projekcie zrobić mniej więcej tyle ile się da z tych wszystkich punktów. To jest fajne.
Z drugiej strony, umiejętność rysowania i umiejętność podejścia do interfejsu, który np. miałby być zmieniony.
Jest problem z portfolio UX-owym. I to jest temat na który też wczoraj na UX Clubie rozmawialiśmy.
Generalnie ciężko projektantowi UX przygotować swoje portfolio, dlatego że często uczestniczy w projektach, które są efektem jakichś kompromisów, czy biznesowych czy technologicznych, więc nie jest to tak, że on pokazuje w danym projekcie całe spektrum swoich możliwości.
Z drugiej strony, nawet ze screenshota, który pokazuje projekt, nie widać np. w jaki sposób ta osoba współpracowała z deweloperami albo z innymi osobami w tym procesie. Tak naprawdę takie typowe portfolio UX to może się kojarzyć bardziej z grafikami czy web deweloperami. Tutaj nie ma racji bytu.
TS: Właśnie nie jestem co do tego przekonany. Zwróć uwagę, że nawet screenshot na którym położysz jakiś półprzezroczysty prostokącik i opiszesz, że tutaj byłeś odpowiedzialny za stworzenie wymagań do dodania tego elementu do koszyka, bądź opracowałeś flow logowania, itd itd. Moim zdaniem to są elementy, które można, dla konkretnego, pojedynczego serwisu nawet, jak najbardziej opisać.
I wydaje mi się, że to, jako jeden z elementów… Wiadomo, że czasem nawet pracując w obrębie jednego serwisu dotyka się kilkunastu elementów jego interfejsu, zwłaszcza jeżeli to są wielkie, bardzo popularne i znane serwisy, albo np. odpowiadałeś za listing wyników wyszukiwania, bądź faceting. To jest projekt, którym się możesz zajmować przez pół roku optymalizując go.
MA: W dobrym świecie, gdzie słońce zawsze świeci, to jest coś co na pewno by zadziałało. Natomiast przed tą rekrutacją, którą rozpoczęliśmy, posłuchałem sobie Jareda Spoola.
TS: Link do tej prezentacji ($$$) znajdzie się również w notatkach.
MA: Tam była jedna rzecz, która dała mi do myślenia, jeżeli chodzi o pytanie o portfolio. Jared Spool, który ma potężne doświadczenie, jeżeli chodzi o rekrutowanie UX wszelkiej maści, stwierdził że czasami, podczas jednej rekrutacji trafiają mu się trzy osoby, które twierdziły, że były jednym, głównym projektantem w danym projekcie i to był ten sam projekt. Więc wiesz…
Bardziej bym zmierzał w trochę innym kierunku. Takimi kierunkiem, w którym poszliśmy podczas rekrutacji i który dał mi dużo do myślenia, mi jako osobie która spotyka się z tymi ludźmi, jest pytanie o projekty, które poszły super świetnie i pytanie dlaczego tak się stało, ale też o projekty które poszły totalnie źle i dlaczego tak się stało.
TS: Też o to pytam. Pytanie o to czy możesz nam opowiedzieć o projekcie, który był Twoim największym sukcesem i co Ci się w nim nie podobało. To jest bardzo bezpieczne pytanie, bo dzięki temu ta osoba ma możliwość wybrania rzeczy, która faktycznie jej się udała i z której jest dumna. I bardzo dobrze też filtruje ludzi, którzy nie mają na ten temat przemyśleń. Moim zdaniem oni powinni odpaść.
MA: Kwestia tego kto jakie ma przemyślenia, albo kto jakie ma wypracowane nawyki to jest chyba coś co najbardziej warto sprawdzać, podczas takiej rekrutacji. Czasami nawet warto zapytać o to, kto się czym ze świata UX inspiruje.
TS: Kto Ciebie inspiruje ze świata UX?
MA: Wcześniej mocno Luke Wróblewski. A w ostatnim czasie Andrea Resmini. Miałem okazję porozmawiać sobie z nim na ostatniej konferencji w Lozannie i bardzo mi się podobały jego warsztaty na których może nie było niesamowicie olśniewającej dla mnie wiedzy, ale cały czas staram się dążyć do zrozumienia czym rzeczywiście jest ten UX.
Jest strasznie dużo różnych definicji. Czym rzeczywiście jest ten UX po stronie użytkownika.
Andrea miał takie mocno uniwersyteckie chyba podejście do swojej pracy. Miał dużo dosyć ciekawych stwierdzeń, które współgrały z moją nieufnością do zgadywania rozwiązań interfejsowych.
Podobało mi się np. to jak podczas warsztatów stwierdził, że jest wielu projektantów, którzy budzą się rano i nagle doznają iluminacji, że już wiedzą jak rozwiązać zadanie w pracy. Idą do pracy, realizują to i super, są zadowoleni. Natomiast on stwierdził, że to nie jest w żaden sposób coś co jest poparte wiedzą. Albo nie jest to coś co jest wsparte jakimś podejściem strategicznym, jakimś podejściem całościowym. To jest jakaś prosta inkubacja twórcza, która po odpoczynku, wykluwa Ci rozwiązanie, które wydaje Ci się słuszne, ale tak naprawdę to cały czas jest zgadywanie. W tym ostatnim czasie ten człowiek mocno mnie wspierał w tym moim myśleniu.
TS: A no właśnie. Na jakie cechy charakteru zwracasz jeszcze uwagę w procesie rekrutacji?
MA: Może odpowiem na to tak:
jeżeli chodzi o pracę w dużych firmach IT, największe problemy, które przytrafiają się nie tylko projektantom to są problemy związane z przekazywaniem informacji, z rozmawianiem.
Na pewno fajnie, żeby była to osoba kontaktowa, która nie ma problemu z tym, żeby nawiązać jakąś relację wymiany informacji z kimś kogo widzi po raz pierwszy. Myślę, że słabo sprawdzają się projektanci, którzy po prostu siadają przed komputerem i robią coś samodzielne, a później najlepiej wrzucają to jako załącznik w (systemie ticketowym) Jira.
To muszą być osoby, które są w stanie pójść i spotkać się z ludźmi z zespołu z którym zaczęli współpracować. I wypracować sobie to, o czym mówiłem wcześniej, czyli powiązanie idei UX-owej z jakimiś ograniczeniami technologicznymi.
Dla mnie przede wszystkim to jest ta komunikatywność i umiejętność rozmawiania.
TS: Ja szukam jeszcze pokory. Pokory jako tego, że osoba z którą rozmawiam wcale nie jest przekonana, że jej rozwiązanie jest najlepsze, tylko że to co proponuje jest jednym ze sposobów podejścia do problemu. Często jest też tak, że projektanci są bardzo egotyczni i są przekonani o tym, że to co zaprojektowali jest najlepsze, ale nie potrafią tego poprzeć wiedzą.
MA: Myślę, że to przede wszystkim zdarza się na samym początku, kiedy projektanci, bo też przeżyłem taki etap, kiedy projektanci traktują swoją makietę albo swój prototyp jako takie dziecko, które musza chronić przed całym światem.
TS: Ale to z deweloperami jest dokładnie tak samo.
MA: Wydaje mi się, że to przechodzi w raz z upływem czasu i makieta przestaje być tym centrum uwagi, a bardziej chodzi o to, żeby projekt skończył się dobrze i żeby przedstawiał jakąś realną wartość.
Jak np. jak pracujemy w parach nie mam żadnego problemu z tym, żeby jedna osoba zaczęła coś robić, a druga, jeżeli będzie miała lepszy pomysł, to żeby pociągnęła to dalej i coś zmieniła. Nikt u nas się nie obraża na takie rzeczy i od początku staramy się mieć jasne zasady, że dążymy do jakości, a nie do tego, żeby wrzucić to sobie w portfolio.
TS: A w jaki sposób rozwijacie wiedzę w zespole?
MA: Jeżeli chodzi o konferencję to każdy ma możliwość w miarę przysługującego mu budżetu tego gdzie chce pojechać.
Natomiast staramy się wspólnie, co bardzo mi się podoba, jako zespół zaplanować jakieś krótkie wyprawy razem. W zeszłym roku Product Camp. W tym roku prawdopodobnie wszyscy pojedziemy na WUD Silesia.
Dlatego że to są takie mocno nieformalne wyjazdy, gdzie nie musimy myśleć o projektach, które realizujemy. Gdzie możemy rzeczywiście znaleźć się w miejscu, które będzie mocniej rozluźniające, np. Product Camp nad morzem. Super! Fantastycznie sobie usiąść nad morzem i pomyśleć, że jutro nie muszę zająć się kolejnym zadaniem tylko po prostu pójdziemy i sobie pogadamy z Maćkiem Saganowskim. To jest na pewno komfortowa sytuacja.
TS: Maćku, pozdrawiamy!
MA: Pozdrawiamy! Tyle jeżeli chodzi o konferencje.
Jeżeli chodzi o szkolenia to tak, mamy możliwość robienia szkoleń wewnętrznych. Na razie skorzystaliśmy ze szkoleń, które wyniknęły z tego o czym rozmawiam z zespołem po Product Campie.
Oni byli mocno zainteresowani tym, żeby prędzej czy później też poprowadzić jakieś warsztaty albo zrobić jakąś prelekcję, co jest bardzo fajne. I fajnie, że pojawili się na Product Campie i zobaczyli jak to działa od wewnątrz, na tym naszym rynku lokalnym, bo efektem tego było to, że zauważyli że oni też posiadają takie kompetencje, żeby wyjść i poprowadzić tego typu spotkania. To było fajne.
Ale oczywiście, jeżeli mają wyjść i zrobić to dobrze, to przydałoby im się jakieś szkolenie z autoprezentacji, z prowadzenia tego typu wystąpień. I coś takiego zorganizowaliśmy jakiś czas temu. Całkiem fajnie było ocenione. Jeżeli chodzi o taką wewnętrzną organizację w zespole to staramy się też wytworzyć pewne nawyki zespołowe. Mamy spotkania, gdzie możemy wymyślić sobie projekt, który realizujemy przez jakiś czas, jak np. ten sketchbook. Później robimy przerwę i wracamy do tego po jakimś czasie. Ostatnio zaczęliśmy robić UX Book Cluby.
TS: Wewnętrzne?
MA: Wewnętrzne. Do których zapraszamy osoby z zewnątrz zespołu, ale wewnątrz firmy. W tej chwili mamy zaangażowane ok. 5-6 osób, które się pojawiają, które chcą czytać i interesują się UX-em, mimo że siedzą w innych zespołach. To też jest fajne.
To oczywiście „wymusiło” też to, żebyśmy stworzyli sobie własną fajną biblioteczkę. Ta biblioteczka jest w creative roomie, który jest po prostu miejscem, które jest naznaczone nami. Ta nasza obecność w firmie też jest więc większa.
Oprócz tego mamy takie różne inicjatywy, które bardziej wychodzą w praniu. Jeżeli dochodzimy do wniosku, że rzeczywiście musimy się zorganizować w jakimś temacie bardziej to sobie organizujemy takie spotkania na których omawiamy taką strategię zespołową.
Unikam raczej tego, żeby coś narzucać w zespole. W sensie, że wymyślę sobie kierunek rozwoju i powiem okej, już teraz wszyscy idziemy w tym kierunku. Raczej wypracowujemy to w inny sposób. To jest też trochę takie podejście jak w przypadku tych warsztatów z deweloperami. Wciągając ludzi w swoim zespole w tego typu decyzje powodujesz, że oni są bardziej zaangażowani, bardziej to rozumieją. Mamy takie design catchupy, gdzie przez godzinę, półtorej każdy po kolei pokazuje co udało się zrobić w ostatnim czasie z takim podejściem jaki problem napotkałem, albo czy jest tu coś co było na tyle ciekawe, że warto o tym opowiedzieć.
Jest to mocno budujące, szczególnie że cały czas gdzieś tam z tyłu głowy mamy pomysł stworzenia takich modułów logicznych, interfejsowych, które być może będą do używania w różnych produktach. Które będą bardziej budowały doświadczenie użytkownika marki, a nie tylko użytkownika danej platformy.
Więc w tym momencie, jeżeli się stykamy z różnymi produktami to to jest ten punkt styku, gdzie powinniśmy się czegoś takiego uczyć i uważnie patrzeć czy to nie jest ten moment, kiedy da się coś zastosować. Robimy to co tydzień. I to jest spotkanie obowiązkowe, którego nie odpuszczamy.
TS: W jaki sposób inspirujesz ludzi poza czytaniem książek, poza rozmawianiem co w danym tygodniu zrobiliście? W jaki sposób inspirujesz ludzi do dalszego rozwoju, do dalszej edukacji?
MA: Tutaj są dwie rzeczy o których mogę powiedzieć. Po pierwsze, co jakiś czas każdy z naszego zespołu może, nawet w formie pisemnej, sobie po prostu opisać to co mu nie pasuje i to w jakim kierunku chciałby pójść dalej. I to później przerabiamy na zadania. Zazwyczaj te rzeczy są bardzo racjonalne, bardzo realne i zrozumiałe z punktu widzenia kogoś, kto jest projektantem.
To są rzeczy osiągalne, tylko jest po prostu kwestia czasu i kwestia starań. A z drugiej strony pozwala to bardzo wykorzystać potencjał danej osoby. Taką listę zazwyczaj przerabiamy na listę zadań, które będą realizowane krok po kroku.
To mogą być kwestie związane z tym, że np. nazwa mojego stanowiska mi nie odpowiada, albo powinniśmy mieć np. trzy stopnie, albo powinniśmy częściej się spotykać w zespole i pracować nad jakimś tam tematem. To są rzeczy, które wynikają z prostych potrzeb codziennych, które mogą powodować pewien brak, pewien niedobór. Generalnie, widzę w zespole dużą chęć do tego, aby realizować tego typu rzeczy, bo każdy widzi tego profit. Widać to, że chcemy się ze sobą spotykać.
TS: A dlaczego pisemnie a nie np. w trakcie rozmowy, twarzą w twarz?
MA: Wiesz co, to nie jest tak, że tylko. Jak się spotykamy to bardzo często, jak zaczynamy o czymś rozmawiać, to wiadomo że tematy rozmów płyną w różnych kierunkach.
TS: Jak widać!
MA: Dokładnie. To co chociażby zaplanowałeś, jeżeli chodzi o kolejność tematów tego podcasta też bardzo się różni od tego w jakim kierunku to poszło.
TS: Nie… Powiem Ci, że zaskakująco mocno się trzymamy.
MA: Forma pisemna jest dla mnie o tyle fajną rzeczą, że daje komuś czas aby sobie coś przemyślał i przygotował lepiej, a przede wszystkim nie pominął czegoś.
Ja np. też mam tak, że wolę sobie często opracować coś pisemnie przed realizacją tego dlatego, że kiedy idę na żywioł mogę później zapomnieć o drobnych szczegółach, które się okazują istotne. I później to trzeba jakoś tam korygować.
Jestem mocnym zwolennikiem tego, aby sobie coś zaplanować w takiej formie, a później to realizować. Poza tym, w momencie kiedy masz jakąś formę pisemną jesteś w stanie to szybko przerobić na jakieś pisemne zadania, które wrzucasz do dokumentu i jako współdzielone odhaczasz po prostu to co jest zrobione a co nie. Jest jeszcze kwestia komunikacji zewnętrznej w zespole.
Jest tak, że nie wszyscy siedzimy razem, bo pracujemy przy innych produktach, ale korzystamy z narzędzia do komunikacji, Slacka, który jest podzielony na różne kategorie, które nie były narzucone z góry, tylko agile-uxowo, czyli najpierw patrzymy co wychodzi, a później tworzymy z tego kategorię. I mam tam też takie miejsca, że jeżeli ktoś znajdzie ciekawy link do artykułu to wrzuca i ktoś inny to może po jakimś czasie przeczytać.
Mamy też np. kanał, który powstał niedawno po to, aby wrzucać rzeczy do szybkiej feedbacku. Mamy jakiś kanał ogólny, który daje możliwość przeprowadzania zwykłych, zwyczajnych rozmów z których też czasami coś wynika fajnego i kreatywnego.
Wydaje mi się, że to co jest najważniejsze to, po pierwsze, żeby była komunikacja, a po drugie, żeby było to przekonanie, że o wszystkim możemy rozmawiać, bo sami jesteśmy taką jedną, wielką instancją, która będzie się nawzajem bronić.
TS: A powiedz mi, jako szef zespołu projektantów, na jakie problemy się natknąłeś które sprawiały Ci, bądź sprawiają Ci nadal problem, które nie do końca udało się rozwiązać?
MA: Myślę, że jest jedna rzecz najbardziej problemowa, która jest w dalszym ciągu nie rozwiązana. W momencie kiedy przyszedłem do tej firmy, zastałem dwóch visual designerów. Jeden bardziej labowy, drugi bardziej DTP.
Nie było działu marketingu, jako takiego, który mógłby wchłonąć osoby tworzące rzeczy tego typu. W taki dość naturalny sposób mamy jednego DTP-owca w zespole.
W momencie kiedy jesteśmy podzieleni na pary projektantów, którzy pracują nad produktem cyfrowym, myślą o jakichś metodach agile-owych, kiedy biegają na spotkania z deweloperami, to jest duży problem jak zadbać o rozwój tego typu osoby. Szczególnie, że jestem też czynnym projektantem, więc tutaj jest ta rozbieżność w kwestii rozumienia lub w kwestii odrębności tych projektów, którymi się zajmujemy. Myślę, że to jest taki największy problem z którym się teraz stykam, czyli po prostu brak takiego dedykowanego zespołu w którym taka osoba powinna być. I przez to może być czasami duża dysproporcja między tym, jaki rodzaj aktywności mamy.
TS: OK. Bardzo Ci dziękuję za poświęcony czas.
W premierowym odcinku rozmawiam z Marcinem Malickim, mistrzem projektowania w obszarze administracji publicznej. Dyskutujemy o procesach w administracji publicznej, projektowaniu dowodów osobistych, foncie Lato, Smutnym Autobusie i o tym dlaczego […]
Post comments (0)