Stawiasz pierwsze kroki w branży UXUI i zastanawiasz się, w którą stronę chcesz iść? Co decyduje o tym, czy znajdziesz pracodawcę, czy własnych klientów? Jak zaplanujesz swoją ścieżkę kariery jako Junior UXUI? Jak pokażesz swój mindset i warsztat, aby zbliżyć się do sukcesu?

Raczej nie za pomocą pięknych interfejsów użytkownika… Choć nie zaszkodzą 🙂

Szkoleniowcy, wykładowcy, masterzy UXUI — absolutnie wszystkie tęgie głowy prowadzące kursy, webinary i konferencje powtarzają zgodnym chórem: TWÓRZ PORTFOLIO. 

Jednak Ty słysząc „portfolio”, przed oczami widzisz tylko mnogość obrazków i mozaikę ładnych interfejsów użytkownika, które pozwalają jedynie zobaczyć, czy umiesz… rysować ładne ekrany. I choć te ładne ekrany pomagają sprzedawać, to musisz wiedzieć, że interfejs użytkownika znajduje się na samym końcu procesu projektowego. Są wynikiem, kropką nad „i”, wisienką na torcie Twojej pracy. Nie widać w nich całego magla towarzyszącemu tworzeniu: sita decyzyjnego, badań, narzędzi warsztatowych pozwalających określić strategię, funkcjonalności, czyli to, czym de facto dany produkt ma być, jakie ma spełniać cele, jak się monetyzować. Co w końcu, w ujęciu zwinnym, znajduje się w MVP… Ładny ekran to nie wszystko

Dlatego też prezentowanie portfolio tylko jako zbioru interfejsów użytkownika mija się z celem. Jeżeli uczestniczyłeś w dobrym kursie, czytałeś odpowiednie książki, słuchałeś odpowiednich ludzi to na pewno wiesz, że prawdziwym wyzwaniem dla młodego projektanta jest przygotowanie swojego własnego Case Study. I o tym Szanowny Czytelniku będzie ten artykuł. Dowiesz się, jak się przygotować do Case Study, jakie istotne informacje przekazywać, jak opowiedzieć i przygotować tę historię- Historię Twojego Produktu, Historię Twojego Warsztatu.

Wiem, że nie będzie łatwo, ani szybko. Wiem, bo kiedyś byłem w tym samym miejscu i po latach ciągle uważam, że dla siebie pracuje się najgorzej. Dlatego też ten artykuł to początek, jedynie nadgryzie tematu, który ma Wam pomóc przygotować Waszą własną opowieść. Kolejnym dobrym krokiem, do którego Was zapraszam jest webinar, w którym w sposób merytoryczny i praktyczny pogłębimy i przepracujemy założenia, które przeczytasz w tym artykule. 

Zatem, jakie powinno wyglądać dobre case study?

Przede wszystkim powinno być: prawdziwe, Twoje i zrozumiałe. 

Opowieść, którą będziesz chciał_ zaprezentować innym musi być prawdziwa, co znaczy, że możesz ją poprzeć dowodami. Musi być także Twoja, czyli unikalna i autorska. Musi być także zrozumiała dla tych, którzy nie mieli do tej pory styku z Twoim produktem, nie znają Cię, ani nie znają kontekstu Twojej pracy (narzędzi, jakie wykorzystał_ś, problemów, z jakimi się zmierzył_ś, rozwiązań, które odrzucił_ś itp.). 

Tutaj (cały na biało) wchodzi storytelling, czyli umiejętność interesującego opowiedzenia o swojej pracy i tu zanotuj sobie: bardzo ważna jest struktura tej opowieści, czyli: kontekst, wyzwanie, któremu musiał_ś sprostać, rozwiązania, które zastosował_ś i w końcu wynik Twojej pracy. Pamiętaj, że Twoja opowieść musi być o tyle porywająco, co uporządkowana i zrozumiała — w końcu odbiorcą jest rekruter, który musi się nią zainteresować, doświadczyć tego, czego doświadcza użytkownik i w końcu polubić. 

Kluczem do Twojego zatrudnienia jest umiejętne przekazanie Twojemu odbiorcy (pracodawcy, rekruterowi, klientowi etc.) Twojego mindsetu, Twojego procesu tworzenia, podejmowania decyzji, sposobu komunikacji, definiowania wyzwania i rozwiązywania problemów. Tego, jaki prezentujesz warsztat.

Proces projektowy to Twoja historia

Twoje case study powinno być oparte o Twój proces projektowy lub o proces projektowy zespołu, w którym pracował_ś, funkcjonował_ś podczas wytwarzania produktu cyfrowego. Każda dobra historia ma wstęp, rozwinięcie i… zakończenie! Opowiadając o procesie zacznij więc od początku: nakreśl tło i kontekst narracji, mów o wyzwaniach projektowych, o postawionych hipotezach, wykorzystanych narzędziach i idei biznesowej.

Zanim jednak opowiesz o badaniach (jakościowe czy ilościowe) warto wspomnieć o desk researchu. Jeżeli przeprowadził_ś badania jakościowe, napisz o tym, jaka była grupa fokusowa, jak ją wyłonił_ś, co z to wynikło i jakie wyciągn_ł_ś wnioski po tych badaniach? Podsumuj proces badawczy, nadaj mu kontekst. 

W tym miejscu możesz także powiedzieć o smaczkach tworzenia, ciekawostkach, na jakie natrafił_ś, rzeczach, które cię zaskoczyły, zainspirowały lub zmieniły postrzeganie przez ciebie idei biznesowej — produktu.

Dodaj cytaty, wzmianki, wycinki — coś, co pokaże, że zagłębił_ś się w ten proces, że chciał_ś zrozumieć, co projektujesz i dla kogo. To jest znakomity haczyk na złapanie interakcji i rozpoczęcie ciekawej rozmowy na własnych warunkach.

Nie bój się błędów 

Proces projektowy to rollercoaster wzlotów i upadków. Jak na prawdziwej kolejce górskiej mogą być momenty zachwytu i ekscytacji, ale także mdłości i przerażenia. Na początku każdemu twórcy towarzyszy duża doza niepewności, kluczenia, szukania, odrzucania rozwiązań (które wydają nam się idealne, a po badaniach okazuje się, że były to jedynie nasze „widzi-misie”). To normalne etapy procesu twórczego, nie bój się ich. Nie bez powodu proces projektowy jest iteracyjny, podzielony na kroki milowe. Dzięki temu możemy powrócić do konkretnego etapu i nanieść poprawki. 

Istotne jest, jak opowiesz o swoich „widzi-misiach”, jak je obalił_ś, albo jak nadał_ś kształt tym, które się potwierdziły.

Tu leży istota pracy projektanta — tak poprowadzić prace, by zniwelować ryzyko wytwarzania wadliwego rozwiązania. Ta opowieść jest fantastyczna, jeżeli przyznasz się do tych potknięć, pokażesz je w swoim procesie projektowym. Najważniejsze jest, aby Twoja puenta zawierała kroki, działania i narzędzia, które zastosował_ś, by produkt był lepszy.

Prawdziwą siłą projektanta jest to, jak definiujesz wyzwania, rozwiązujesz problemy i to, że dostarczasz jakość pożądaną przez biznes i z myślą o użytkowniku.

Odkryj narzędzia 

Większość produktów cyfrowych jest obecnie wytwarzana w metodologiach zwinnych. Największym wyzwaniem w procesie projektowym jest droga, którą twórcy muszą przejść zaczynając od określenia idei biznesowej, przez koncepcję na produkt aż do samego projektu produktu o minimalnej pożądanej funkcjonalności (MVP). Celem procesu projektowego jest odpowiedź na pytania: które funkcjonalności będą wartościowe dla użytkowników i będzie je łatwo wytworzyć?

Zdecydowanie warto opowiedzieć o tej podróży projektowej, o narzędziach, jakich podczas niej używał_ś. Niezależnie od tego, czy to była propozycja wartości, Customer Journey Map, red router, kolejne iteracje badań czy pierwsze Wireflow wizualizujące proces. A może wykorzystał_ś metody Design Thinking do generowania pomysłów? Bezwzględnie w Twoim Case Study warto przedstawić tool box i pokazać drogę, którą pokonał_ś. Zwróć szczególną uwagę na argumentację, dlaczego funkcjonalność X znalazła się w MVP kosztem funkcjonalności Y, zaplanowanej jako rozwój produktu.

I teraz ważne i istotne: nie ma sensu wklejać gotowych canvasów ani screenów z Miro. Rektuterowi będzie trudno przechodzić przez pojedyncze canvasy, zapełnione dziesiątkami karteczek i skrótów myślowych. Pamiętaj, że masz u swojego odbiorcy ograniczony kredyt zaufania i czas, dlatego musisz skutecznie zarządzać uwagą swojego odbiorcy. Spisz wnioski, opisz krótko wybrane narzędzie, daj im kontekst i przekaż dostęp do dokumentacji do materiałów źródłowych. Przedstaw wnioski, argumentację, kluczowe elementy i “smaczki”. Powiedz co cię zaskoczyło, co okazało się problematyczne, jak wybrn_ł_ś? Plus link dokumentacji i tyle. Serio!

Pracowałeś zespołowo? Opowiedz, jak było… 

Praca zespole jest o tyle fajna co trudna i wymagająca. Każdy z nas ma trochę inny rytm pracy, inaczej przykłada się do swoich zadań, inaczej się komunikuje, ma inne doświadczenia. Oczywiście łatwo jest powiedzieć, że receptą na sukces jest 100% zaangażowania. Prawda jest taka, że nie da się mieć 100% uwagi cały czas i przez cały czas trwania projektu. Nie jesteśmy robotami, mamy gorsze dni, możemy być niewyspani, zmęczeni, zniechęceni, może nas boleć głowa, ręka, noga albo najzwyczajniej w świecie mieć dzień lenia. To też jest normalne.

Dlatego, jeżeli tworzyłeś swój produkt w zespole, spróbuj opowiedzieć w tym wątku o wyzwaniach, jakie napotkaliście na swojej drodze, w jaki sposób pracowaliście, zarządzaliście swoją pracą, jak rozdzielaliście zadania. Jeżeli na przykład dzieliliście się zadaniami, określiliście deadliny, pracowaliście wspólnie warsztatowo — napisz o tym! Jeżeli pojawiły się problemy, na przykład przy bieżącej komunikacji lub z dowożeniem zadań — też o tym wspomnij, bo jeśli pojawił się problem w funkcjonowaniu i jako zespół znaleźliście rozwiązanie, to znaczy, że ulepszyliście proces wspólnej pracy. Tak funkcjonuje branża, tak funkcjonują zespoły. Twoja osobowość i sposób funkcjonowania w zespole jest równie istotny, jak Twój warsztat projektowy.

Praca w zespole oznacza, że produkt nie został wytworzony w całości przez Ciebie. Musisz zatem precyzyjnie wskazać, jaka była Twoja rola w zespole, bez nadinterpretacji, bez nawijania makaronu na uszy. Jest to idealne miejsce, by w trakcie rozmowy porozmawiać o swoich brakach, które zauważył_ś i Twoich planach na ich zniwelowanie. W trakcie pracy dowiedział_ś się czego i jak chcesz się nauczyć albo co sprawia Ci przyjemność? Warto szczerze o tym powiedzieć — to procentuje.

Before — after 

Na etapie modelowania wybranych i zmapowanych procesów rysujesz konkretne widoki, tak by przygotować je do testów użyteczności. Warto pamiętać tutaj o dwóch rzeczach: jeżeli diagram procesu jest skomplikowany, zastosuj zasadę z poprzedniego akapitu — opisz ten proces prosto, czyli wskaż wyzwania projektowe i do pełnej dokumentacji odeślij linkiem. Drugą jest bariera wejścia rekrutera. Przeglądanie User Flow jest  uciążliwe, jeżeli nie zna się kontekstu lub nie będzie się pracować na jego podstawie. Rekruter będzie się skupiał na tym, czy notacja jest spójna i nie zawiera błędów logicznych. Nie będzie za to analizował ani odnosił się do zasadności samego procesu.

Pamiętaj też, że przy modelowaniu i utrzymywaniu dokumentacji ważne jest wersjonowanie. Badania użyteczności mogą wykoleić pewne rozwiązania, a istotnym elementem Case Study jest pokazanie zmiany, czyli tego, jak procesy/ ekrany wyglądały przed i po badaniu, jakie poprawki zostały naniesione, a nawet, w jaki sposób podejmował_ś decyzje projektowe prowadzące do tej zmiany.

Nie bój się wskazywać błędów. Wyciągnij z nich wnioski krytycznie i bezlitośnie. Nie zapominaj o metodyce badawczej: ile osób było zrekrutowanych, jaka była grupa docelowa, ile iteracji badań wykonano?

Iteracje i dane 

Produkt cyfrowy to dane, zbiór procesów, które prowadzą użytkownika do wykonania konkretnej pracy. Dlatego sukces powinien być mierzalny. Zwróć uwagę, żeby w case study o tym mówić, wskaż kroki milowe w procesach, dane, które są potrzebne do wykonania pracy, czy procesy się konsumują itp. To pokaże ewolucje w procesie projektowym i Twoje zrozumienie produktu, biznesu i użytkownika.

Świadomość przepływu, konsumowania produktu cyfrowego, konwersji, najbardziej dochodowego momentu jest kluczowy. Jako projektanci jesteśmy zatrudniani do tego, żeby — choć to dosyć brutalne — użytkownikowi łatwiej było wydawać pieniądze w ten lub inny sposób.

Case study jest odbiciem twojego warsztatu

Dla młodego projektanta Case Study jest bezpośrednim odbiciem mindsetu i wizytówką warsztatu. To zwierciadło Twoich zawodowych kompetencji i motywacji, narzuca ton rozmowy, powinien być także Twoją strefą komfortu. Case Study daje pogląd potencjalnemu pracodawcy na to, jakim projektantem jesteś i czy będziesz pasować do kultury organizacji.
Oczywiście na samym początku swojej kariery możesz chcieć zaczepić się gdziekolwiek, jednak z mojego doświadczenia lepiej nieco dłużej szukać odpowiedniego miejsca, niż wybrać cokolwiek i szybko je zmieniać na takie, które spełni Twoje wymagania.
Ten zbiór wskazówek, który przygotowałem to jedynie wskazówka, jak zacząć tworzyć swoje pierwsze Case Study.  Niestety nie ma przepisu na idealne case study. Dlaczego?
Bo każdy produkt jest inny, a decyzje projektowe i efekty pracy diametralnie różne. Bo historia, którą opowiadasz, to nie tylko historia samego produktu, ale opowieść o Twojej pracy nad nim. I dlatego też jest to takie trudne.
Na koniec dam Ci jeszcze jedną radę: jesteś projektantem? Pracuj więc jak projektant. Czyli określ cel, grupę docelową i zaprojektuj swoje Case Study. Szukaj informacji zwrotnej, pracuj iteracyjnie i przygotuj się na kilka, kilkanaście tygodni pracy. Czy warto więc poświęcić je na tworzenie dobrego Case Study? Czy pomoże Ci ono znaleźć pracę? 

Warto! I zdecydowanie pomoże!
Do dzieła!

Checklista

Na samym końcu przedstawiam swoistą checklistę, która powinna Ci pomóc w przygotowaniu opowieści o projektowanym przez Ciebie produkcie. Jeżeli chcesz dowiedzieć się więcej, m.in. o tym jak pracować z tym warsztatowo, jak przygotować się do budowania tej historii, jakie elementy są w Twojej opowieści kluczowe — zapisz się na webinar. Chętnie pomogę.

Checklista dobrego Case Study:

1. Napisz konspekt, plan dla Case Study — oprzyj się o proces projektowy.
2. Zbuduj kontekst dla produktu, zacznij od idei biznesowej.
3. Wprowadź do wiedzy domenowej — wnioski z desk researchu.
4. Opisz grupę docelową i dotarcie do grupy focusowej.
5. Opisz metodologię badań i ekstraktuj z nich wnioski.
6. Mów o zmianie. O wnioskach, argumentacjach. 
7. Nie bój się wskazywać na błędy popełnione w trakcie procesu projektowego. 
8. Pokaż drogę i decyzję, które doprowadziły cię do MVP.
9. Nadaj CS realności, wyciągaj smaczki, cytaty.
10. Narzędzia prezentuj opisowo, skup się na decyzjach i iteracjach.
11. Nie publikuj pełnej dokumentacji, ale daj do niej dostęp.
12. Przy badaniach użyteczności, omów zmianę, nie zapomnij opisać metodologii.
13. Pokazuj zmianę na zasadzie before — after.
14. Omów pracę zespołową, podział obowiązków, problemy.
15. Określ jasno swoją rolę w zespole.
16. Pamiętaj o konwersji i nakreśleniu kluczowych danych do konsumowania lejka konwersji.