Jak rekruter i klient czytają portfolio – prawdziwy kontekst
Różne perspektywy, jeden klucz: sposób myślenia
Rekruter i klient oglądają portfolio z innych powodów, ale łączy ich jedno: chcą zrozumieć, jak myślisz. Nie tylko to, czy umiesz zrobić ładny interfejs, ale czy potrafisz połączyć kropki: potrzeby użytkownika, cele biznesowe, ograniczenia i zespół.
Rekruter patrzy pod kątem: czy poradzisz sobie w procesie produktowym, czy rozumiesz współpracę z developerami, PM-em, biznesem, czy umiesz priorytetyzować. Klient bardziej szuka odpowiedzi: czy ta osoba zrozumie mój biznes, dowiezie projekt i nie utopi mnie w niekończących się wariantach.
Obie strony szukają sygnałów strategicznego myślenia. Nie interesuje ich jedynie warstwa wizualna – chcą zobaczyć decyzje, uzasadnienia, wpływ. Portfolio jest dla nich narzędziem oceny sposobu pracy, a nie tylko jakości estetycznej.
„Ładne obrazki” działają przez 3 sekundy
Przy pierwszym kontakcie ważne jest, aby projekty były estetyczne na tyle, by nie zniechęcały. Jednak ten efekt trwa krótko. Po kilku sekundach zaczyna się zadawanie pytań: o co w ogóle chodziło w tym projekcie, po co zmieniano ten ekran, czy te pomysły działają w rzeczywistości.
Sam zespół rekrutacyjny zwykle zakłada, że jeśli ktoś dotarł do rozmowy, ma już pewne minimum warsztatu wizualnego. W tej fazie przewagę buduje historia projektu, a nie sam dribbblowy wygląd ekranu. Portfolio, które zatrzymuje się na poziomie galerii, przegrywa z portfolio, które do prostych wizualizacji dokłada głębszą narrację.
Stąd tak ważne jest, by pod każdym projektem pojawiła się choćby krótka, ale przemyślana sekcja tekstowa: kontekst, problem, rola, decyzje, efekty. To właśnie tam widać Twoje myślenie strategiczne.
Jak naprawdę przegląda się portfolio: skan, nie lektura
Większość rekruterów i klientów ma na pierwsze przejrzenie portfolio kilka–kilkanaście minut. Skanują nagłówki, pierwsze zdania, śródtytuły w opisach projektów. Zatrzymują się tylko tam, gdzie widzą konkrety i strukturę.
Typowy sposób przeglądania:
zobaczenie listy projektów i rzut oka na miniatury,
kliknięcie w jeden lub dwa najciekawsze projekty,
przewijanie i łapanie wzrokiem nagłówków w case study,
szukanie fragmentów typu: „Moja rola”, „Cele i wyniki”, „Decyzje projektowe”,
ocena: czy to jest konkretnie, czy ogólnikowo i marketingowo.
To oznacza, że najważniejsze informacje muszą być widoczne „z lotu ptaka”. Krótkie, jasne nagłówki, pogrubienia kluczowych zdań, przejrzysta struktura. Długi blok tekstu bez podziału po prostu zostanie pominięty.
Co musi być widoczne na pierwszy rzut oka
Przy każdym projekcie dobrze, aby na górze lub z boku ktoś mógł jednym spojrzeniem złapać:
jaki to typ projektu (np. aplikacja mobilna dla e-commerce, panel B2B, landing kampanii),
dla kogo (branża lub rodzaj klienta, nawet jeśli zanonimizowany),
Twoja rola (UX, UI, product design, research, prowadzenie warsztatów itd.),
główny cel biznesowy/projektowy (np. poprawa konwersji, skrócenie procesu, wzrost aktywności),
jeden–dwa najważniejsze efekty lub wnioski.
Ten skrócony opis (może być w formie krótkiej tabelki, listy punktowanej, „metryczki projektu”) decyduje, czy ktoś zechce wejść w szczegóły. Bez tego Twój strategiczny proces może nawet nie zostać przeczytany.
Co znaczy pokazywać myślenie strategiczne w portfolio
Operacyjne vs strategiczne: dwa poziomy opisu
Opis operacyjny skupia się na tym, co zrobiłeś. Kolejne wydarzenia: „zrobiłem research, przygotowałem persony, zaprojektowałem makiety, wdrożyliśmy produkt”. Taki opis jest poprawny, ale płaski – przypomina checklistę działań.
Opis strategiczny pokazuje, dlaczego wykonywałeś te kroki i jakie decyzje podjąłeś. To różnica między: „przeprowadziliśmy 10 wywiadów” a „przeprowadziliśmy 10 wywiadów, żeby zrozumieć, dlaczego użytkownicy porzucają koszyk po kroku numer trzy – okazało się, że…”.
Myślenie strategiczne wychodzi poza narzędzia i metody. Łączy badania, priorytety biznesowe, ograniczenia i efekt końcowy. W portfolio warto więc konsekwentnie przechodzić z poziomu „co zrobiłem” na „co z tego wynikło i dlaczego wybrałem właśnie to podejście”.
Cztery filary myślenia strategicznego w opisie projektu
Praktycznie każde case study, które ma pokazać myślenie strategiczne, powinno dotykać czterech elementów:
Kontekst – w jakiej sytuacji był produkt/klient, jaki to rynek, jaka grupa użytkowników.
Cele – czego mieliście wspólnie dokonać, z punktu widzenia biznesu i użytkownika.
Decyzje i kompromisy – co wybraliście, co odrzuciliście i dlaczego.
Wpływ – co się zmieniło dzięki projektowi: liczby, zachowania, procesy, świadomość zespołu.
Jeśli w każdym projekcie pokażesz choćby po jednym konkretnym przykładzie z tych obszarów, Twoje portfolio automatycznie wskoczy na wyższy poziom. Rekruter nie szuka idealnych historii, tylko oznak świadomego, przemyślanego działania.
Jak przełożyć „strategiczne” na prosty, ludzki język
Strategia wielu osobom kojarzy się z cebulką terminów: „alignment interesariuszy”, „roadmapa rozwojowa”, „kaskadowanie KPI”. W opisie projektu nie chodzi o modne sformułowania, tylko o czytelne pokazanie problemów, wyborów i konsekwencji.
Zamiast:
„Zachodziliśmy w głowę, jak zwiększyć engagement w aplikacji”
lepiej:
„Klienci logowali się raz, a potem przez miesiąc nie wracali. Aplikacja nie dawała im powodu, by ją otworzyć ponownie.”
Zamiast:
„Wdrożyliśmy nowy flow on-boardingu”
lepiej:
„Poprzedni onboarding miał sześć kroków i co trzeci użytkownik odpadał w połowie. Skróciliśmy go do trzech decyzji, dzięki czemu więcej osób dochodziło do ekranu głównego.”
Strategia w portfolio to umiejętność opowiadania o projektach przez pryzmat problemów, wyborów i skutków, a nie listy zastosowanych narzędzi.
Ten sam projekt opisany „estetycznie” i „strategicznie”
Przykład prostej różnicy na fragmencie opisu:
Opis estetyczny:
„Zaprojketowałem nową stronę główną sklepu z odzieżą. Użyłem jaśniejszej palety kolorów, dużych zdjęć i prostych kart produktowych. Dodałem też sekcję z rekomendacjami i opinie klientów.”
Opis strategiczny:
„Sklep miał duży ruch z kampanii, ale mały procent osób przechodził z homepage do listy produktów. W analizie kliknięć widać było, że użytkownicy gubią się w trzech równorzędnych sekcjach na starcie. Zamiast przeprojektowywać wszystko, skupiliśmy się na jednym celu: doprowadzić jak najwięcej osób do listy produktów. Przebudowaliśmy układ strony, podnosząc sekcję z najpopularniejszymi kategoriami i dodając wyraźny przycisk ‘Zobacz produkty’. Opinie klientów pokazaliśmy dopiero niżej, jako wsparcie decyzji, a nie punkt wyjścia.”
Ten drugi opis od razu pokazuje: problem, priorytet, wybór, konsekwencje. Nawet jeśli nie ma ani jednego procenta czy liczby, widać tok rozumowania.
Mały projekt też może pokazać szerokie myślenie
Nie trzeba pracować przy wielkiej platformie SaaS, żeby pokazać strategiczne podejście. Landing kampanii, mała apka, prosty kreator formularzy – każdy z tych tematów może ujawnić rozumienie biznesu i procesu.
Przykład: landing dla webinaru. Zamiast pisać „zaprojektowałem landing z sekcją prelegentów, agendą i formularzem”, pokaż:
jaki był problem (np. mało zapisów z poprzednich kampanii),
jaką decyzję biznesową podjęliście (np. skrócenie strony, mocniejsze wyeksponowanie korzyści zamiast tytułów prezentacji),
co zmieniono dla użytkownika (np. prostszy formularz, sekcja „dla kogo jest ten webinar”),
jak zmieniły się wyniki lub zachowania (choćby jakościowo: więcej zapisów z telefonu, mniej przerwanych formularzy).
Nawet jeśli nie masz twardych danych, możesz opisać sygnały jakościowe: opinie zespołu sprzedaży, feedback uczestników, obserwacje po starcie. To dalej jest pokazanie wpływu, a więc myślenia strategicznego.
Źródło: Pexels | Autor: Gustavo Fring
Wybór projektów: które prace w ogóle warto pokazać
Mniej projektów, ale opowiedzianych „do końca”
Portfolio z dwudziestoma screenami bez kontekstu przegrywa z portfoliem, które ma trzy–pięć dobrze opowiedzianych case studies. Rekruter i klient wolą zobaczyć kilka projektów, w których naprawdę „siedzisz”, niż dziesięć slajdów z ładnymi UI-ami, o których niewiele możesz powiedzieć.
Dobrym punktem wyjścia jest zestaw:
2–3 pełne case studies (proces, decyzje, efekty),
kilka mniejszych projektów pokazanych jako „mini-case” (metryczka + 2–3 zdania kontekstu + 1–2 kluczowe ekrany),
opcjonalnie: osobna sekcja na eksperymenty, koncepty, projekty hobbystyczne.
Myślenie strategiczne wybrzmiewa dopiero, gdy możesz poświęcić projektowi trochę miejsca. Dlatego selekcja jest tak ważna: lepiej schować część projektów do szuflady, niż rozmyć obraz siebie jako świadomego projektanta.
Kryteria selekcji: jakie projekty pracują na Twoją historię
Przy wyborze projektów warto przejść przez krótką checklistę:
czy problem w tym projekcie był choć trochę złożony (więcej niż „zmień kolor przycisku”),
czy miał realny wpływ na biznes, proces lub użytkownika,
czy Twoja rola była wyraźna, a nie totalnie rozmyta w dużym zespole,
czy możesz pokazać proces (choćby skrótowo), a nie tylko efekt końcowy,
czy ten projekt pasuje do kierunku, w jakim chcesz iść zawodowo.
Jeśli projekt spełnia większość z tych kryteriów, ma potencjał na case study projektowe. Jeśli nie – być może lepiej pokazać go jako mały przykład wizualny, bez rozbudowanej historii.
Komercyjne, własne, szkolne – jak są czytane
Rekruter zwykle ocenia projekty przez pryzmat ich „realności”. Projekty komercyjne są naturalnie traktowane jako najbardziej wiarygodne: miały ograniczenia, prawdziwych interesariuszy, budżety i terminy.
Projekty własne i hobbystyczne też mogą świetnie pokazać myślenie strategiczne, pod warunkiem, że:
opisujesz je jak realne – z jasno wymyślonym kontekstem, celem, odbiorcą,
nie wyglądają jak przypadkowe dribbble-shoty oderwane od problemu,
pokazujesz, jakie decyzje podejmowałeś, a nie tylko „bawiłem się stylem”.
Projekty szkolne z kursów i bootcampów mogą być wartościowe, jeśli zadbasz o własny komentarz: co byś zrobił inaczej, jakie kompromisy były wymuszone przez format, czego nauczyłeś się o procesie. Najgorzej wypadają projekty, w których tylko powtarzasz brief kursu bez własnego wkładu.
Kiedy projekt nadaje się na pełne case study
Dobry kandydat na case study to projekt, gdzie możesz jasno opowiedzieć:
co było punktem wyjścia (konkretna sytuacja produktu/klienta),
z czym realnie się mierzyliście (problem),
co Ty konkretnie zrobiłeś,
jakie dwie–trzy ważne decyzje podjąłeś,
co się zmieniło po wdrożeniu lub testach.
Jeśli któregoś z tych punktów w ogóle nie da się rzetelnie opisać (np. nie miałeś wpływu na decyzje, tylko „rysowałeś według specyfikacji”), lepiej przenieść projekt do sekcji „inne realizacje” i pokazać go w mocno skróconej formie.
Jak ułożyć kolejność projektów, żeby zbudować historię
Chronologia to najprostszy klucz, ale nie zawsze najlepszy. Lepiej ułożyć projekty tak, by razem opowiadały o Twoim rozwoju i obszarach, w których chcesz się poruszać.
Dobrym podejściem może być np.:
na początku projekt, który najlepiej pokazuje Twoje aktualne kompetencje i rolę (flagowe case study),
Jak łączyć projekty w spójną narrację o sobie
Portfolio nie jest zbiorem osobnych kartek. To jedna opowieść o tym, jak myślisz i działasz. Kolejność projektów może tę opowieść albo wzmocnić, albo kompletnie rozmyć.
Zamiast układać projekty „jak leci”, zrób krótkie ćwiczenie:
Wypisz na kartce 2–3 hasła, z którymi chcesz się kojarzyć (np. „produkty subskrypcyjne”, „praca z danymi”, „usprawnianie procesów w organizacji”).
Przypisz do każdego hasła projekty, które je najlepiej pokazują.
Ułóż z tego sekwencję: mocne otwarcie → pogłębienie → szerszy kontekst.
Przykładowe ustawienie dla projektanta produktowego:
1. Case: redesign kluczowego flow (pokazuje wpływ na metryki, decyzje produktowe),
2. Case: projekt od zera (pokazuje myślenie o strategii produktu i wejściu na rynek),
3. Case: usprawnienie procesu w zespole (pokazuje pracę z interesariuszami i komunikację),
na końcu: mini-projekty wizualne, eksperymenty.
Rekruter po takim zestawie nie widzi już tylko „UX/UI”. Ma raczej obraz: „osoba, która potrafi brać odpowiedzialność za wynik, rozumie produkt i ogarnia współpracę w firmie”. Taki efekt daje właśnie przemyślane, strategiczne ułożenie projektów.
Struktura dobrego opisu projektu – szkielet case study
Prosty szablon, który da się użyć w każdym projekcie
Pełne case study nie musi być długą historią od „dzieciństwa produktu”. Wystarczy powtarzalny szkielet, który da się dopasować do małego i dużego tematu. Taki szablon może wyglądać tak:
Kontekst: gdzie jesteśmy, co to za produkt/usługa, kim jest odbiorca.
Problem: co konkretnie nie działało, skąd to wiedzieliśmy.
Cel: co miało się zmienić z perspektywy biznesu i użytkownika.
Rola: za co byłem odpowiedzialny, z kim współpracowałem.
Proces: skrót kroków, które naprawdę miały znaczenie.
Decyzje i kompromisy: 2–3 kluczowe wybory i „co poświęciliśmy”.
Efekt: co wyszło, co się zmieniło, czego się nauczyłem.
Nie musisz trzymać się kolejności jak prawa fizyki. Czasem lepiej zacząć mocnym efektem („Udało się skrócić czas onboardingu o połowę”), a potem pokazać drogę. Ważne, by każdy z tych elementów realnie się pojawił, choćby w jednym–dwóch akapitach.
Jak szczegółowo opisywać proces, żeby nie zanudzić
Najczęstszy błąd: ściana tekstu „robiliśmy warsztaty, potem persony, potem user flow, potem makiety…”. Taki opis nic nie mówi o Twoim myśleniu. Proces warto pokazywać tylko tam, gdzie widać decyzje.
Pomocne pytania przy edycji:
Który krok procesu realnie wpłynął na kierunek projektu?
W którym momencie zmieniliście założenia?
Gdzie pojawił się konflikt oczekiwań (np. biznes vs. użytkownik) i jak go rozwiązaliście?
Przykład zamiast listy narzędzi:
Zamiast: „Przeprowadziliśmy 10 wywiadów z użytkownikami, stworzyliśmy mapę empatii oraz persony.”
Lepiej: „W wywiadach wyszło, że użytkownicy nie ufają podawaniu danych karty na starcie. To uderzało w model biznesowy, który zakładał darmowy okres próbny z kartą. Musieliśmy przekonać zespół sprzedaży do zmiany kolejności kroków w procesie.”
Proces zostaje, ale jest tłem dla wyborów, a nie celem samym w sobie. To właśnie robi różnicę między „ładną checklistą metod” a obrazem projektanta, który potrafi z nich korzystać świadomie.
Jak radzić sobie z ograniczeniami poufności
W wielu projektach nie możesz pokazać wszystkiego: wyników, ekranów, szczegółów branży. To nie przekreśla case study, jeśli dobrze opiszesz kontekst i decyzje.
Kilka prostych trików:
zamień wrażliwe liczby na przedziały lub relacje („dwukrotny wzrost liczby rejestracji”, „spadek czasu obsługi o kilkanaście procent”),
zamiast pełnych ekranów pokaż fragmenty z omówieniem, co i dlaczego się zmieniło,
jeśli musisz całkiem zrezygnować z wizualizacji, oprzyj się na schematach flow i opisie decyzji.
Strategiczne myślenie da się pokazać nawet na mocno zanonimizowanym projekcie. Ważne, by czytelnik zrozumiał: z jakim problemem się mierzyłeś, jakie opcje rozważałeś, co ostatecznie wybraliście.
Źródło: Pexels | Autor: RDNE Stock project
Jak opisać kontekst, problem i cele bez korporacyjnego żargonu
„Scena otwarcia” projektu: 3–4 zdania, które ustawiają wszystko
Kontekst to krótkie wprowadzenie, w którym odbiorca ma zrozumieć: gdzie jesteśmy i o co w ogóle chodzi. Nie chodzi o historię firmy od 1998 roku, tylko o ramy dla Twoich decyzji.
Pomocna mini-struktura:
Co to za produkt/usługa – 1 zdanie.
Dla kogo – 1 zdanie.
Jaka była sytuacja wyjściowa – 1–2 zdania.
Przykład:
„Projekt dotyczył aplikacji do zarządzania wydatkami dla małych firm. Użytkownikami byli właściciele jednoosobowych działalności, często bez zaplecza księgowego. Produkt miał stabilną bazę klientów, ale bardzo niski odsetek osób korzystających z modułu planowania budżetu.”
Zero „transformacji cyfrowej”, „inicjatyw strategicznych” i „dynamicznych środowisk”. Samo mięso, które pozwala wejść w projekt bez zgadywania.
Jak nazywać problemy, żeby były zrozumiałe dla każdego
Problem powinien być zapisany tak, żeby osoba spoza firmy mogła go poczuć. Pomijaj wewnętrzne nazwy projektów, skróty, wewnętrzny slang.
Porównanie:
Zamiast: „W ramach inicjatywy X2Y mieliśmy zwiększyć adopcję modułu B2 wśród klientów premium.”
Lepiej: „Tylko niewielka część klientów premium korzystała z modułu do planowania budżetu, mimo że płacili za niego w abonamencie. Zadaniem projektu było sprawdzić, dlaczego tak się dzieje i zaproponować zmiany.”
Dobry opis problemu często zawiera:
zachowanie („użytkownicy nie kończą rejestracji”, „klienci nie wracają po pierwszym zakupie”),
skutek („tracimy potencjał przychodów”, „wsparcie spędza czas na powtarzalnych pytaniach”).
Jeśli masz dane, pokaż je wprost. Jeśli nie, opisz obserwacje i źródła: rozmowy z zespołem sprzedaży, feedback z supportu, nagrania z sesji badawczych.
Formułowanie celów: z „zadowolenia” na konkret
„Poprawa satysfakcji użytkowników” to nie jest cel, który pokazuje myślenie strategiczne. To życzenie. Cel musi być powiązany z czyimś wynikiem: biznesu, zespołu, użytkownika.
Użyj prostego filtra przy każdym celu:
Dla kogo to jest ważne (biznes, użytkownik, konkretny dział)?
Po czym poznamy, że jest lepiej (zachowanie, liczba, sygnał jakościowy)?
W jakim horyzoncie (po wdrożeniu, po kwartale, po kampanii)?
Przykładowa para:
Cel ogólny: „Zwiększyć użyteczność panelu raportów.”
Cel przełożony na konkret: „Doprowadzić do tego, aby menedżerowie sprzedaży byli w stanie samodzielnie wygenerować raport tygodniowy bez pomocy analityka, w czasie poniżej pięciu minut.”
Tak sformułowany cel automatycznie sugeruje, na co będziesz patrzeć: czas wykonania zadania, liczbę zgłoszeń do analityków, poczucie kontroli użytkownika nad raportami. To już jest strategia, a nie „ładniej i wygodniej”.
Jak mówić o celach, gdy nie masz żadnych liczb
W wielu mniejszych firmach lub projektach pobocznych nikt nie ustawia KPI. Da się jednak pokazać cele przez pryzmat wpływu na codzienną pracę lub doświadczenie użytkownika.
Przykładowe sposoby:
„Ułatwić rejestrację dla osób mniej technicznych, żeby zespół wsparcia nie musiał prowadzić ich krok po kroku przez telefon.”
„Skrócić czas szukania dokumentów przez księgowych, żeby ograniczyć pracę po godzinach pod koniec miesiąca.”
„Zmniejszyć liczbę porzuconych formularzy wniosku kredytowego na telefonach.”
To nadal są cele – tylko opisane językiem ludzi, którzy z systemu korzystają. Rekruter od razu widzi, że myślisz o skutkach w realnym świecie, a nie tylko o „ładnym interfejsie”.
Pokazywanie swojej roli, decyzji i kompromisów
Jak klarownie opisać swoją rolę, nie umniejszając zespołu
„Pracowaliśmy w zespole multidyscyplinarnym” brzmi dobrze, ale nie mówi nic o Tobie. Z drugiej strony, „zaprojektowałem cały produkt” w dużej organizacji jest mało wiarygodne. Trzeba znaleźć środek.
Pomaga prosty format:
Skład zespołu: „W projekcie brał udział product manager, dwóch developerów, analityk i ja jako UX/UI designer.”
Twoje główne odpowiedzialności: „Byłem odpowiedzialny za badania z użytkownikami, prototypowanie kluczowych flow i współpracę z developerami przy wdrożeniu.”
Gdzie wywarłeś największy wpływ: „Moja kluczowa decyzja dotyczyła zmiany kolejności kroków w procesie rejestracji.”
Taki opis nie odbiera zasług innym, a jednocześnie jasno pokazuje, za co można Cię „rozliczać”. Rekruter może dopytać o konkretne obszary, a Ty masz grunt pod dalszą rozmowę.
Decyzje: pokaż alternatywy, nie tylko finał
Strategiczne myślenie najlepiej widać tam, gdzie są opcje. Jeśli w opisie pokazujesz tylko końcowe rozwiązanie, wygląda to jak jedyna słuszna droga. Tymczasem w każdym projekcie pojawiają się rozgałęzienia.
Spróbuj takiego schematu opisu jednej decyzji:
Jaki był dylemat: „Mogliśmy zbierać dane karty od razu albo dopiero po okresie próbnym.”
Jakie były opcje: „Biznes chciał pierwszego wariantu ze względu na przychody, badania pokazały ryzyko dużego odpływu użytkowników.”
Na czym opierałeś wybór: „Przetestowaliśmy dwa warianty na małej grupie nowych użytkowników.”
Co ostatecznie wybraliście i dlaczego: „Zostaliśmy przy zbieraniu karty od razu, ale dodaliśmy jasne wyjaśnienia i możliwość rezygnacji jednym kliknięciem.”
Nie chodzi o to, by zawsze wygrywał użytkownik czy biznes. Liczy się pokazanie, że świadomie ważysz konsekwencje, zamiast mechanicznie wdrażać cudze pomysły.
Komunikowanie kompromisów: „co odpuściliśmy i na kiedy”
W prawdziwych projektach mało co jest „idealne”. Feature’y wypadają z zakresu, część pomysłów ląduje „na później”, niektóre rozwiązania są wersją minimum. Udawanie, że wszystko poszło zgodnie z planem, odbiera Twojej historii wiarygodność.
Dobry opis kompromisu zawiera trzy elementy:
Co odpuściliście: „Zrezygnowaliśmy z personalizowanych rekomendacji w pierwszym wydaniu.”
Dlaczego: „Wdrożenie algorytmu zjadało zbyt dużo czasu zespołu przy niepewnym wpływie na wynik.”
Jak to zabezpieczyliście na przyszłość: „Zostawiliśmy techniczne haki pod prostsze reguły rekomendacji i wpisaliśmy pełny moduł na roadmapę po walidacji podstawowego flow.”
Taki opis pokazuje, że nie działasz w próżni. Rozumiesz terminy, ograniczenia techniczne i to, że czasem „lepiej wypuścić wersję prostszą, ale na czas”. Jednocześnie dajesz sygnał, że masz plan na dalszy rozwój rozwiązania.
Jak szczerze mówić o porażkach bez strzelania sobie w stopę
Nie każdy projekt kończy się sukcesem. Czasem metryki nie rosną, hipoteza się nie potwierdza albo wdrożenie zostaje zatrzymane. Taki case może paradoksalnie najlepiej pokazać Twoje myślenie strategiczne, jeśli mądrze go opiszesz.
Kiedy opłaca się pokazać trudny projekt
Nie każdy trudny projekt jest dobrym case study. Jeśli chcesz opisać porażkę lub dyskusyjne decyzje, upewnij się, że możesz pokazać tam coś więcej niż „nie wyszło”.
Pomaga prosty filtr:
Masz na coś wpływ: pokazałeś inicjatywę, proponowałeś inne rozwiązania, wyciągnąłeś wnioski.
Widać proces: są badania, hipotezy, testy, nie tylko „zrobiliśmy redesign, ale się nie przyjął”.
Jest lekcja na przyszłość: wiesz, co byś zrobił inaczej w kolejnym projekcie.
Jeśli projekt był po prostu chaosem bez Twojej podmiotowej roli, lepiej poświęcić miejsce na inne przykłady. Porażka ma sens w portfolio tylko wtedy, gdy pokazuje Twój rozwój i sposób myślenia, a nie wyłącznie cudze błędy.
Jak ramować porażkę, żeby pokazać dojrzałość
Bezpieczna struktura wygląda tak:
Cel: „Chcieliśmy zwiększyć udział zakupów mobilnych.”
Zakładana ścieżka: „Postawiliśmy na skrócenie checkoutu i usunięcie rejestracji.”
Rzeczywisty efekt: „Wzrosła liczba rozpoczętych koszyków, ale spadła liczba transakcji.”
Dlaczego tak się stało (Twoja analiza, nie zrzucanie winy): „Zbyt mocno uprościliśmy formularz danych, co budziło nieufność przy droższych zakupach.”
Co zrobiłeś dalej: „Przywróciliśmy część pól, dodaliśmy komunikaty o bezpieczeństwie i przetestowaliśmy dwa warianty.”
Czego się nauczyłeś: „Przy produktach wysokokwotowych kluczowe jest poczucie bezpieczeństwa, nie minimalna liczba kroków.”
Taka narracja pokazuje, że nie uciekasz od odpowiedzialności, patrzysz na dane i potrafisz korygować kurs. To jest esencja myślenia strategicznego – nie sam fakt, że coś „zadziałało”.
Jak mówić o decyzjach, z którymi się nie zgadzałeś
W wielu projektach część decyzji zapada ponad Twoją głową. To normalne. Klucz w tym, jak o tym opowiadasz.
Konstrukcja, która chroni relacje, a jednocześnie nie robi z Ciebie biernego wykonawcy:
Twoje stanowisko: „Z mojej perspektywy kluczowe było utrzymanie prostoty rejestracji.”
Co zrobiłeś: „Przygotowałem dwie wersje flow i krótkie testy użyteczności.”
Decyzja biznesu: „Zarząd wybrał wariant z dodatkowymi krokami ze względu na wymagania prawne.”
Twoja reakcja: „Skupiłem się na tym, żeby dodatkowe ekrany były jak najbardziej zrozumiałe i lekkie.”
Nie ma potrzeby dramatyzować ani ubarwiać konfliktów. Rekruter chce zobaczyć, że potrafisz mieć zdanie, argumentować je i jednocześnie działać profesjonalnie, gdy decyzja idzie w inną stronę.
Jak pokazywać wpływ, gdy efektów jeszcze nie widać
Część projektów w portfolio jest świeża: wdrożenie dopiero się toczy, danych mało. Możesz mimo to pokazać myślenie strategiczne, jeśli jasno opiszesz spodziewany wpływ i sposób jego mierzenia.
Przydatny szablon:
Co już wiadomo: „Projekt jest po pierwszym release, mamy feedback jakościowy od zespołu sprzedaży.”
Jakie sygnały obserwujesz: „Sprzedawcy zgłaszają mniej problemów z konfiguracją ofert na tabletach.”
Jakie metryki planujesz śledzić: „Czas przygotowania oferty, liczba błędnie skonfigurowanych umów, liczba zgłoszeń do działu wsparcia.”
Jaka jest hipoteza: „Jeśli konfiguracja będzie prostsza, sprzedawcy będą w stanie obsłużyć więcej spotkań dziennie.”
Dzięki temu rekruter widzi, że nie kończysz myślenia w momencie zrobienia makiet. Masz w głowie dalszy ciąg – jak rozwiązanie ma „pracować” w biznesie.
Jak podkreślić ciągłość myślenia między projektami
Portfolio zwykle pokazuje osobne case’y, ale strategiczne myślenie widać też po tym, jak łączysz kropki między nimi. Krótkie wzmianki o tym, jak doświadczenia z jednego projektu wpłynęły na kolejny, robią dużą różnicę.
Możesz to pokazać na dwa proste sposoby:
W sekcji „Czego się nauczyłem” przy każdym projekcie dodaj jedno zdanie o tym, jak wykorzystałeś tę lekcję później. Np.: „W kolejnym projekcie onboardingowym od razu zaplanowałem krótkie testy A/B formularza.”
Przy podobnych tematach (np. kilka projektów e‑commerce) wskaż zmianę podejścia: „W pierwszym sklepie kładłem nacisk na liczbę kroków w koszyku, w kolejnych – na poczucie bezpieczeństwa i jasną komunikację kosztów.”
To sygnał, że nie zaczynasz każdego projektu „od zera”, tylko budujesz swoją praktykę w czasie.
Jak przełożyć wewnętrzny chaos na czytelną historię
Wiele projektów przebiega chaotycznie: zmieniają się priorytety, pivot goni pivot, backlog puchnie. W portfolio nie chodzi jednak o wierne odtworzenie bałaganu, tylko o pokazanie, jak w nim nawigujesz.
Pomaga podział na etapy, nawet jeśli w rzeczywistości trochę się zazębiały:
Faza 1 – rozpoznanie: „Przez pierwsze dwa tygodnie rozmawiałem z zespołem sprzedaży i supportu, żeby zrozumieć, gdzie naprawdę boli.”
Faza 2 – skupienie: „Zamiast ruszać cały panel, skupiliśmy się na dwóch krytycznych ekranach, które blokowały pracę.”
Faza 3 – iteracje: „Wypuszczaliśmy małe poprawki co tydzień, zbierając szybki feedback.”
Nikt nie oczekuje, że wszystko będzie linearne. Liczy się Twoja zdolność do nadania temu sensu i kierunku.
Jak opisywać współpracę z innymi działami w kontekście strategii
Myślenie strategiczne to także umiejętność pracy na styku zespołów. Zamiast ogólnego „blisko współpracowałem z biznesem”, pokaż, co to znaczyło w praktyce.
Przykładowe wątki, które dobrze wybrzmiewają w portfolio:
Marketing: „Dzięki warsztatom z marketingiem doprecyzowaliśmy persony kampanii i to wpłynęło na priorytety w projekcie onboardingowym.”
Sprzedaż: „Spotkania z zespołem field sales pozwoliły zrozumieć, że kluczowy jest tryb offline aplikacji, nawet kosztem części zaawansowanych funkcji.”
Obsługa klienta: „Analiza ticketów supportu pomogła wybrać trzy scenariusze do poprawy zamiast rozdrabniania się na kilkanaście mniejszych usprawnień.”
Tu też chodzi o decyzje. Nie tylko że współpracowałeś, ale jak feedback innych działów przekładał się na to, co projektowałeś.
Jak pokazać świadomość ryzyk i ograniczeń
Projekty rzadko są robione w idealnych warunkach. Brakuje danych, czasu, zasobów. Jeśli udajesz, że tego nie było, Twoja historia brzmi jak bajka.
Przy każdym większym projekcie możesz dodać krótką sekcję o ryzykach:
Jakie ryzyka widziałeś: „Brak rzetelnych danych historycznych o zachowaniach w aplikacji.”
Jak je ograniczałeś: „Oparliśmy się na nagraniach z Hotjara i 10 wywiadach, a wnioski traktowaliśmy jako hipotezy do dalszej walidacji.”
Jak je komunikowałeś: „Od początku mówiłem zespołowi, że pierwsze wydanie traktujemy jako MVP z założonym ryzykiem zmian po 2–3 miesiącach.”
To pokazuje, że umiesz pracować z niepewnością i nie sprzedajesz iluzji stuprocentowej pewności tam, gdzie jej nie ma.
Pokazywanie decyzji „czego NIE zrobiliśmy”
Strategia to także wybór, gdzie nie wkładać energii. W portfolio możesz wygospodarować miejsce na krótki fragment o tym, co świadomie zostawiłeś poza zakresem.
Dobre przykłady:
„Nie poprawialiśmy wyglądu całej aplikacji, skupiliśmy się na flow otwierania konta, bo tam traciliśmy najwięcej klientów.”
„Zrezygnowaliśmy z rozbudowanego systemu badge’y i gamifikacji, bo badania pokazały, że użytkownikom zależy głównie na stabilności i szybkości działania.”
„Nie budowaliśmy własnego systemu powiadomień, tylko wykorzystaliśmy istniejące rozwiązanie, żeby szybciej dowieźć wartość.”
Takie decyzje są dla rekrutera równie ważne, jak to, co faktycznie wdrożyłeś. Pokazują, że umiesz priorytetyzować i mówić „nie”.
Jak łączyć warstwę wizualną z narracją strategiczną
Same makiety czy screeny rzadko pokazują myślenie strategiczne. Z drugiej strony, ściana tekstu bez wizualizacji też nie pomaga. Dobrze jest podejść do tego jak do storyboardu.
Przy każdym kluczowym screenie zadaj sobie kilka pytań i odpowiedz na nie w dwóch–trzech zdaniach obok grafiki:
Jaką decyzję reprezentuje ten ekran? (np. „Tu widać skrócenie procesu rejestracji z pięciu do trzech kroków.”)
Jaki problem rozwiązuje? („Użytkownicy gubili się przy wyborze planu, więc rozbiliśmy go na prostsze pytania.”)
Jakie były alternatywy? („Rozważaliśmy też wizard pełnoekranowy, ale testy pokazały większe porzucenia.”)
Dzięki temu nawet osoba, która tylko „przeleci” projekt wzrokiem, złapie kontekst Twoich decyzji, a nie tylko stylistykę interfejsu.
Jak pisać zwięźle, ale nie tracić głębi
Portfolio nie jest miejscem na pełny raport z projektu. Chodzi o wybranie ujęć, które najlepiej pokazują Twoje myślenie. Zamiast rozwlekać każdy wątek, wybierz 2–3 kluczowe decyzje i opisz je trochę głębiej.
Przykładowe cięcia, które pomagają utrzymać balans:
Wytnij szczegółowe opisy narzędzi („użyłem Figmy, Miro, Jiry”), zachowaj tylko to, co miało wpływ na sposób pracy.
Skróć listę badań do tych, które realnie zmieniły kierunek („Po trzeciej rundzie testów zmieniliśmy strategię na…”).
Rozwiń opis jednej–dwóch decyzji, zamiast lekko dotykać pięciu różnych.
W efekcie Twoje case’y są krótsze, ale gęstsze od treści – a to dużo lepiej świadczy o sposobie myślenia niż dziesięć ekranów procesu bez komentarza.
Najczęściej zadawane pytania (FAQ)
Jak pokazać myślenie strategiczne w portfolio projektanta?
Najprościej: przy każdym projekcie pokaż nie tylko co zrobiłeś, ale przede wszystkim dlaczego i co z tego wynikło. Opis powinien przechodzić z listy działań („zrobiłem research, zaprojektowałem makiety”) do decyzji („wybraliśmy ten wariant, bo…”) i efektów („dzięki temu użytkownik szybciej…”).
Pomaga prosty szkielet: kontekst (sytuacja produktu), cel (co mieliście osiągnąć), decyzje i kompromisy (co wybraliście/odrzuciliście), wpływ (jak to zmieniło produkt, ludzi lub wyniki). Nawet krótki, ale konkretny akapit w tej logice pokazuje sposób myślenia, a nie tylko warsztat graficzny.
Co koniecznie dodać do opisu projektu w portfolio UX/UI?
Minimum, które pozwala ocenić sposób pracy:
Typ projektu – np. „aplikacja mobilna dla e-commerce”, „panel B2B do zarządzania zamówieniami”.
Dla kogo – branża, segment klienta, krótka charakterystyka użytkowników.
Główny cel – np. poprawa konwersji, skrócenie procesu, zwiększenie aktywności.
1–2 konkretne efekty – liczby lub jakościowe zmiany w zachowaniu użytkowników czy sposobie pracy zespołu.
To może być krótka „metryczka” na początku case study. Dzięki niej rekruter od razu rozumie, w jakim kontekście działałeś i czyje problemy rozwiązywałeś.
Jak pisać o projektach, gdy nie mam twardych danych i wyników?
Jeśli nie masz liczb, pokaż wpływ w innych kategoriach. Możesz opisać zmianę zachowania użytkowników (np. „użytkownicy przestali zgłaszać problem X na support”), zmianę w decyzjach biznesowych („po testach zrezygnowaliśmy z funkcji, która tylko komplikowała interfejs”) albo w pracy zespołu („wspólny warsztat uporządkował priorytety feature’ów”).
Zamiast próbować „wymyślać” KPI, opisz konkretną przed i po: jak wyglądał proces, ekran czy komunikacja wcześniej, co dokładnie się zmieniło i dlaczego podjęliście taką decyzję. Nawet jakościowy opis jest lepszy niż puste hasło „poprawiliśmy UX”.
Jak odróżnić opis operacyjny od strategicznego w portfolio?
Opis operacyjny odpowiada na pytanie: „co zrobiłem po kolei?”. Dużo tam zdań typu: „zrobiłem audyt, przygotowałem makiety, wdrożyliśmy nowy wygląd”. Taki zapis przypomina checklistę z procesu i niewiele mówi o tym, jak myślisz.
Opis strategiczny dokłada trzy rzeczy: powód (po co robiliście dany krok), wybór (z jakich opcji korzystaliście i co odrzuciliście) oraz konsekwencje (co się zmieniło). Przykład: zamiast „przeprowadziliśmy 10 wywiadów”, lepiej „przeprowadziliśmy 10 wywiadów, żeby zrozumieć, dlaczego użytkownicy porzucają koszyk w kroku 3 – okazało się, że…”.
Jak opisywać małe projekty (np. landing, prostą apkę), żeby wyglądały strategicznie?
Kluczowe jest pytanie: jaki problem biznesowy i użytkowy ten mały projekt rozwiązywał. Dla landingu nie pisz tylko „zaprojektowałem stronę z agendą i formularzem”. Pokaż: co było nie tak wcześniej, co chcieliście zmienić, jaką decyzję podjęliście i co poprawiliście dla użytkownika.
Przykład: „Poprzedni landing webinaru miał długą agendę i chował korzyści. Skróciliśmy stronę, dodaliśmy sekcję ‘dla kogo to jest’ oraz uprościliśmy formularz z pięciu pól do dwóch. Dzięki temu zniknęła większość pytań typu ‘czy to dla mnie?’ w mailach do supportu”. To nadal mały projekt, ale pokazuje rozumienie kontekstu i decyzji.
Jak pisać opisy projektów, żeby rekruter szybko „złapał” sens?
Załóż, że ktoś skanuje, nie czyta linijka po linijce. Pomaga kilka prostych zasad: krótkie nagłówki, logiczne śródtytuły, pogrubione kluczowe zdania i brak ścian tekstu. Zadbaj o sekcje typu: „Kontekst”, „Moja rola”, „Cel”, „Kluczowe decyzje”, „Efekty”.
Dobrym testem jest przeczytanie tylko nagłówków i pierwszych zdań akapitów. Jeśli już z tego da się zrozumieć, o co chodziło w projekcie, jaki był problem i co zmieniliście, to rekruter prawdopodobnie się zatrzyma i doczyta szczegóły.
Czego unikać w opisie projektów, jeśli chcę pokazać myślenie strategiczne?
Najczęstsze pułapki to: opisywanie wyłącznie warstwy wizualnej („zmieniłem kolory, typografię, dodałem ilustracje”), ogólniki bez konkretu („zwiększyliśmy engagement”, „poprawiliśmy użyteczność”) oraz przeładowanie modnymi hasłami bez treści („alignment interesariuszy”, „kaskadowanie KPI”).
Zamiast tego używaj prostego, zrozumiałego języka, pokazuj konkretny problem, jasny wybór i namacalny skutek. Jedno realistyczne zdanie o tym, że „użytkownicy przestali dzwonić na infolinię z pytaniem X”, mówi więcej o Twoim myśleniu niż trzy akapity marketingowego żargonu.
Opracowano na podstawie
Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability. New Riders (2014) – Zasady projektowania zorientowanego na użytkownika i czytelności treści
The Elements of User Experience: User-Centered Design for the Web and Beyond. New Riders (2010) – Model warstw UX, kontekst produktu, cele biznesowe i użytkownika
Lean UX: Designing Great Products with Agile Teams. O'Reilly Media (2016) – Nacisk na efekty, hipotezy, decyzje i wpływ w procesie projektowym
Inspired: How to Create Tech Products Customers Love. SVPG Press (2018) – Rola product discovery, celów biznesowych i współpracy z zespołem
Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. Pichler Consulting (2016) – Definiowanie strategii produktu, celów i priorytetów
About Face: The Essentials of Interaction Design. Wiley (2014) – Projektowanie interakcji, scenariusze użycia i decyzje projektowe
Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster (2016) – Struktura procesu, decyzje i testowanie rozwiązań z perspektywy biznesu
