Znasz to uczucie, kiedy w każdym ogłoszeniu o pracę na juniora widnieje wymóg „minimum rok doświadczenia komercyjnego”? Błędne koło, w które wpada prawie każdy aspirujący designer: żeby dostać pracę, potrzebujesz portfolio z realnymi projektami, a żeby mieć realne projekty, potrzebujesz pracy.
To koło da się przerwać i w tym artykule zdradzimy ci, jak to zrobić.
Jako Mood Up, software house z Poznania prowadzimy rekrutacje do naszych zespołów designe’owych na różnych poziomach – od stażów przez stanowiska juniorskie, aż do seniorów. W tym artykule zdradzimy ci, jak to przygotować swoje portfolio, kiedy nie masz jeszcze komercyjnego doświadczenia.
Czym jest dobre portfolio i dlaczego „ładne obrazki” to za mało?
Zacznijmy od obalenia pewnego mitu. Rekruterzy nie szukają w portfolio “estetycznych obrazków”. Szukają dowodu, że umiesz myśleć produktowo, czyli że potrafisz zidentyfikować problem, zrozumieć użytkownika i ograniczenia biznesowe, a potem świadomie zaprojektować rozwiązanie, które je adresuje.
Ładny ekran można wygenerować, skopiować z inspiracji albo zlecić komuś innemu. Tego, czego nie da się podrobić, to proces myślowy stojący za decyzjami projektowymi.
Pytania, na które musi odpowiadać każdy projekt:
- Dlaczego podjąłeś takie decyzje projektowe?
- Dlaczego dana funkcjonalność jest w tym miejscu, a nie gdzie indziej?
- Jakie pomysły odrzuciłeś po drodze i dlaczego?
- Jak zweryfikowałeś, że rozwiązanie w ogóle działa?
To właśnie odpowiedzi na te pytania budują zaufanie do ciebie jako designera. Jeśli w swoim projekcie oprócz mock upów i widoków aplikacji umieścisz opis tego, w jaki sposób pracowałeś pokażesz rekruterowi, że umiesz działać strategicznie, a to w branży IT jest najważniejsze.
Skąd brać projekty do portfolio, skoro nikt ci ich nie zleca?
Redesign istniejącej aplikacji to dobry punkt startowy, ale tylko wtedy, gdy wybierzesz go mądrze. Problem w tym, że setny redesign Spotify, Netflixa czy Instagrama w portfolio nie robi już żadnego wrażenia, rekruter widział go dziesiątki razy i najczęściej od razu przewija dalej. Te aplikacje mają zespoły projektantów, testy A/B i dane, do których nie masz dostępu, więc trudno w ogóle mówić tam o realnym rozwiązywaniu problemu.
Znacznie lepiej działa coś mniej oczywistego:
- lokalne aplikacje, które nie miały funduszy na inwestowanie w dobry UX,
- stare strony internetowe, które potrzebują redesignu,
- panele użytkowników, np. do rezerwacji wizyt, które są bardzo nieintuicyjne.
Dlaczego to działa lepiej? Bo te produkty mają realne problemy, które możesz zdiagnozować samodzielnie, obserwując, testując, pytając znajomych. A rekruter od razu widzi, że umiesz dostrzec problem tam, gdzie inni przechodzą obok niego obojętnie.
Projekty koncepcyjne z własnymi ograniczeniami
Drugą drogą są projekty od zera, czyli tzw. self-initiated projects. Tu największym błędem jest projektowanie bez jasno określonej graniczy lub też celu. Kiedy masz nieograniczony budżet, nieograniczony czas i żadnych wymagań technicznych, projekt zaczyna wyglądać jak fantazja, a nie realna praca produktowa. W skutku projekt wydaje się przekombinowany, a tym samym nieużyteczny.
Rozwiązanie jest proste: narzuć sobie sztuczne ograniczenia, zanim zaczniesz.
Kilka przykładów:
- „Ten startup ma budżet na jednego dewelopera i musi wystartować w 3 miesiące, więc MVP musi być jak najprostrze.”
- „Aplikacja musi działać offline, bo target to obszary o słabym zasięgu internetu.”
- „Klient nalega na konkretną, niestandardową paletę kolorów”.
Takie samodzielnie wymyślone ograniczenia sprawiają, że projekt zaczyna przypominać prawdziwe zlecenie, a nie czysto artystyczne ćwiczenie. I dokładnie to chcą zobaczyć osoby rekrutujące na stanowiska product designerskie – umiejętność projektowania w realiach, a nie w próżni.
NGO, wolontariat, hackathony i projekty dla znajomych
To najbardziej niedoceniana droga do zdobycia realnego doświadczenia, bo tu naprawdę istnieje klient, realny problem i prawdziwe ograniczenia (czasowe, budżetowe, techniczne).
Organizacje pozarządowe – prawie zawsze potrzebują pomocy przy stronach, formularzach zbiórek czy aplikacjach wolontariackich, a rzadko stać je na profesjonalnego designera.
Hackathony – dają Ci 24–48 godzin ostrego projektowania pod presją czasu, a przy okazji są świetną okazją do networkingu i poznania ludzi z branży.
Znajomi prowadzący małe biznesy – fryzjerka, korepetytor, lokalna kawiarnia, które mają realne problemy (np. brak systemu rezerwacji).
Takie projekty są najlepiej oceniane przez rekruterów z jednego względu: są to już początki prac komercyjnych. Pojawia się klient, który ma swoje wymagania i oczekiwania, ty jako strona wykonawcza musisz się do nich dostosować lub znaleźć złoty środek. To uczy nie tylko samego projektowania, ale też komunikacji, która jest niezbędna w pracy komercyjnej.
Co najważniejsze, po wykonanej pracy możesz poprosić klienta o feedback, który później umieścisz w portfolio. To bardzo dobry nawyk, który również przyda ci się w późniejszej pracy.
Anatomia idealnego case study
Samo zrobienie dobrego projektu to połowa sukcesu. Druga połowa to umiejętność opowiedzenia o nim w sposób, który prowadzi rekrutera przez twoje myślenie krok po kroku.
Struktura wygląda mniej więcej tak:
1. Problem
Jedno, dwa zdania. Co było nie tak? Jaki ból odczuwał użytkownik lub biznes?
2. Kontekst i ograniczenia
Kim był (fikcyjny lub realny) klient, jaki miał budżet, deadline, ograniczenia techniczne. To tutaj pokazujesz, że rozumiesz biznesowy wymiar projektowania, a nie tylko estetykę.
3. Proces
Tu dzieje się najwięcej. Opisujesz swoje badania (nawet szczątkowe, wywiady z trzema osobami też się liczą), persony, user flow, wireframe’y, iteracje.
Pokaż porażki i zmiany kierunku, to nie wstyd, a dowód na krytyczne myślenie.
4. Rozwiązanie
Finalny efekt, ale osadzony w kontekście: dlaczego wygląda właśnie tak, a nie inaczej.
5. Wnioski i to, czego się nauczyłeś/aś
Sekcja, którą pomija 90% portfolio, a która najbardziej zapada w pamięć. Co zrobiłbyś inaczej? Jaki błąd popełniłeś? Ta sekcja pokazuje dojrzałość i samoświadomość pracy, a bardzo niewielu kandydatów się na nią decyduje.
Złota zasada: 2–3 świetne projekty > 10 średnich
Rekruter nie ma czasu przewijać dziesięciu pobieżnie opisanych projektów. Woli zobaczyć dwa albo trzy dogłębne case study, które dowodzą, że potrafisz przejść przez cały proces projektowy od A do Z.
Jakość rozwiązywania problemu zawsze wygra z ilością ekranów.
Czas otworzyć Figmę
Nie potrzebujesz zgody rekrutera, żeby zacząć rozwijać swoje kompetencje projektowe. Potrzebujesz jednego dobrze wybranego problemu, odrobiny odwagi i konsekwencji w dokumentowaniu procesu.
Autorka:
Viktoriia Trykisha – Product Designer w Mood Up