Case study w portfolio: jak pokazać proces projektowy, by klient zaufał od razu

Dlaczego case study w portfolio buduje zaufanie szybciej niż same „ładne obrazki”

Czego tak naprawdę szuka klient w portfolio projektanta

Klient wchodzący na portfolio rzadko szuka „sztuki”. Szuka dowodu, że poradzisz sobie z jego konkretnym problemem. Interesuje go, czy:

• rozumiesz realia biznesu (terminy, budżet, ograniczenia techniczne),
• umiesz słuchać i przekładać cele firmy na decyzje projektowe,
• potrafisz samodzielnie prowadzić proces projektowy krok po kroku,
• nie spanikujesz, gdy coś pójdzie nie tak i trzeba będzie iterować.

Same makiety, ekrany UX/UI czy identyfikacje wizualne pokazują poziom estetyki, ale nie pokazują sposobu myślenia. Case study w portfolio wypełnia tę lukę – pozwala klientowi dosłownie „zajrzeć ci do głowy” i ocenić, czy chce z tobą pracować.

Jak case study redukuje ryzyko po stronie klienta

Dla klienta każde zlecenie projektowe to ryzyko: pieniędzy, czasu i nerwów. Im większy budżet, tym większa obawa, że:

• projekt się przeciągnie bez jasnej przyczyny,
• wyjdziesz poza ustalony zakres,
• skończy się na czymś innym niż potrzebuje biznes,
• napotkasz problem i „znikniesz”, zamiast go rozwiązać.

Dobrze opisane case study pokazuje, że potrafisz kontrolować proces: definiować problem, planować działania, dokumentować decyzje i dowozić efekt. Klient widzi, że masz powtarzalny sposób pracy, a nie działasz chaotycznie i „na wyczucie”. To automatycznie obniża jego stres.

Galeria prac kontra portfolio decyzyjne dla klienta biznesowego

Większość młodych projektantów tworzy galerię prac – ciąg ekranów w figmie, mockupy stron, logotypy na białym tle. Klient ogląda to jak katalog inspiracji i… dalej nie wie, czy z tobą współpracować.

Portfolio decyzyjne wygląda inaczej. Zamiast „o, ładne!”, klient ma odpowiedź na pytanie: „Czy ta osoba ogarnie mój projekt?” Bo przy każdym case study widzi:

• z jaką sytuacją startową miałeś do czynienia,
• jak zdefiniowałeś problem razem z klientem,
• jak wyglądały najważniejsze kroki procesu projektowego,
• jakie efekty realnie przyniósł projekt.

Taki układ wspiera decyzje biznesowe: dyrektor marketingu, product owner czy właściciel firmy widzą analogie do swoich wyzwań i dużo szybciej mogą powiedzieć „tak, to jest nasz człowiek”.

Case study a wyższe stawki i dłuższe współprace

Wyższe stawki nie biorą się z „ładniejszej kreski”, tylko z postrzegania twojej wartości. Jeśli portfolio sprowadza się do obrazków, klient widzi w tobie wykonawcę typu „zrób mi ładny banner”. W takiej relacji trudno rozmawiać o budżecie większym niż jednorazowe zlecenie.

Case study z jasno opisanym procesem projektowym pokazuje cię jako partnera w rozwiązywaniu problemów. Partner:

• może zadawać niewygodne pytania o strategię,
• ma wpływ na produkt, nie tylko na kolory,
• może proponować dłuższą współpracę (retainer, opieka produktowa),
• łatwiej negocjuje wyższe stawki, bo uzasadnia je wpływem na biznes.

Dobrze skonstruowane case study jest więc nie tylko materiałem do chwalenia się, ale narzędziem sprzedażowym.

Co sprawdzić w swoim obecnym portfolio

Krótka kontrola jakości:

• Czy przy każdym projekcie klient rozumie, z jaką sytuacją startową pracowałeś?
• Czy opisujesz problem i cel, czy tylko pokazujesz finalny efekt?
• Czy widać najważniejsze kroki procesu, czy tylko „przed” i „po”?
• Czy pokazujesz choć jeden efekt – liczbowy lub jakościowy?
• Czy klient biznesowy mógłby na podstawie portfolio stwierdzić: „Ta osoba ogarnia proces, nie tylko grafiki”?

Szkielet skutecznego case study: prosta struktura, która działa

Uniwersalny szablon: od kontekstu do wniosków

Najprostszy i jednocześnie bardzo skuteczny schemat case study to:

1. Kontekst – kto, co, w jakiej sytuacji.
2. Problem – co nie działało, co było celem.
3. Proces – jak pracowałeś krok po kroku.
4. Rozwiązanie – co konkretnie zaprojektowałeś/zaproponowałeś.
5. Efekty – co to zmieniło.
6. Wnioski – czego się nauczyłeś, co robisz dziś inaczej.

Niezależnie, czy pokazujesz projekt UX, identyfikację wizualną czy kampanię social media – ta struktura porządkuje opowieść. Klient może płynnie śledzić historię projektu, a ty nie gubisz najważniejszych elementów.

Krok 1: Kontekst – krótki opis klienta i sytuacji wyjściowej

Opis kontekstu powinien odpowiedzieć na trzy pytania:

• Kim był klient? (branża, wielkość, typ produktu, rynek).
• W jakim momencie był projekt? (start od zera, redesign, usprawnienie części systemu).
• Jakie były ograniczenia? (czas, budżet, zastana technologia, zespół).

Przykład:

„Klient: średniej wielkości sklep internetowy z branży kosmetycznej, obecny na rynku od kilku lat. Projekt: redesign kluczowych ekranów procesu zakupowego na desktop i mobile w oparciu o istniejący system CMS i szatę graficzną.”

Bezpieczeństwo danych jest kluczowe, więc unikaj wrażliwych szczegółów (konkretne przychody, dane klientów, tajne funkcje). W razie potrzeby możesz zmienić nazwę firmy lub napisać ogólnie: „Klient z branży X”.

Krok 2: Problem i cel – nazwij, co naprawdę trzeba było rozwiązać

Drugi element to precyzyjne zdefiniowanie problemu i celu. Tutaj łatwo wpaść w pułapkę żargonu projektowego („niespójny UI”, „zły flow”), który dla klienta niewiele znaczy. Lepiej łączyć język biznesu z projektowym:

• Problem biznesowy: co bolało firmę? (np. „duża liczba porzuconych koszyków”).
• Problem użytkownika: co frustrowało odbiorcę? (np. „trudno znaleźć informację o dostawie”).
• Cel projektu: co miało się zmienić? (np. „ułatwić dokończenie zakupu na mobile”).

Przykład:

„Sklep otrzymywał wiele wiadomości od klientów, że nie mogą znaleźć informacji o kosztach dostawy przed dodaniem produktów do koszyka. Z analityki wynikało też, że część użytkowników porzuca proces na etapie wyboru formy dostawy. Celem projektu było uproszczenie ścieżki zakupu i lepsze wyeksponowanie informacji o dostawie, bez przebudowy całej platformy.”

Krok 3: Proces – opis działań, badań i decyzji

To serce case study. Tu pokazujesz proces projektowy krok po kroku: od zrozumienia problemu, przez warianty, po testy i wdrożenie. Warto rozbić go na kilka logicznych etapów, np.:

• Analiza i badania wstępne.
• Synteza wniosków i kierunki rozwiązania.
• Makiety / prototypy / projekty wizualne.
• Testowanie i iteracje.
• Wdrożenie i współpraca z zespołem.

Przy każdym etapie opisz:

• Po co to robiłeś (jaki był cel danego kroku).
• Jak to robiłeś (narzędzia, metody, forma współpracy z klientem).
• Co z tego wynikło (konkretny wniosek lub decyzja).

Nie chodzi o to, by pokazać każdy pojedynczy ekran, tylko najważniejsze momenty decyzyjne. W kolejnej sekcji pojawią się szczegółowe przykłady.

Efekty i wnioski – domknięcie historii projektu

Na końcu case study klient chce zobaczyć: „Co to dało?”. Jeśli masz twarde dane – świetnie. Jeśli nie, pokaż:

• zmiany w zachowaniu użytkowników (np. „mniej pytań na support”),
• konkretne usprawnienia (np. „skrócona liczba kroków w formularzu”),
• opinię klienta lub użytkowników,
• twoje własne wnioski, które pokazują refleksję.

Na końcu dopisz 2–3 zdania w stylu: „Czego się nauczyłem?”. To sygnał, że rozwijasz się jako projektant, a nie tylko „odhaczasz” projekty.

Co sprawdzić w konstrukcji każdego case study

Przygotowując lub poprawiając case study, przejdź tę listę kontrolną:

• Czy jasno opisałeś kontekst i ograniczenia projektu?
• Czy problem jest nazwany w sposób zrozumiały biznesowo, nie tylko projektowo?
• Czy proces projektowy jest podzielony na etapy z wyraźnym „po co” i „co z tego wynikło”?
• Czy pokazałeś konkretne decyzje, a nie tylko „robiliśmy makiety i testy”?
• Czy case ma efekt końcowy i wnioski, a nie urywa się na ekranach?

Jak opisać kontekst i problem, żeby klient natychmiast się utożsamił

Krótki i jasny opis branży, produktu i skali

Kontekst nie musi być długi, ma być konkretny. Kilka zdań wystarczy, jeśli odpowiada na pytania: „kto?”, „co?”, „na jaką skalę?”. Dobrze, gdy klient może szybko ocenić, czy:

• pracujesz z podobnymi firmami (wielkość, B2B/B2C),
• rozumiesz jego typ produktu (SAAS, e‑commerce, aplikacja, usługa lokalna),
• ogarniesz złożoność jego projektu.

Przykłady sformułowań:

• „Aplikacja mobilna do rezerwacji wizyt w salonach beauty, skierowana do użytkowników w dużych miastach.”
• „Lokalna firma usługowa (warsztat samochodowy), która chciała przenieść część sprzedaży do internetu.”
• „Platforma B2B do składania zamówień hurtowych przez partnerów handlowych klienta.”

Formułowanie problemu językiem klienta, nie tylko projektanta

Typowy błąd: problem opisany brzmi jak fragment dokumentu projektowego, a nie jak realne wyzwanie biznesowe. Przykład słabego opisu:

„Strona miała złą architekturę informacji i nieintuicyjny UX.”

Z perspektywy klienta więcej mówi:

„Użytkownicy mieli problem z odnalezieniem kluczowych usług. Często dzwonili z pytaniami, które powinna rozwiązać strona. Dla firmy oznaczało to dodatkowe obciążenie działu obsługi i utratę części zapytań.”

Dopiero później możesz dodać komentarz projektowy: „Za tym stała niejasna architektura informacji i brak hierarchii treści”. Najpierw jednak pokaż problem tak, jak widzi go biznes.

Pokazywanie ograniczeń bez narzekania

Realne projekty prawie nigdy nie dzieją się w idealnych warunkach. Masz za mało czasu, budżetu, dostępności devów, realnych danych. Jeśli pokażesz to w case study z głową, zyskujesz wiarygodność. Klient widzi, że potrafisz projektować w ramach ograniczeń, a nie tylko w teorii.

Unikaj tonu: „klient nic nie rozumiał, a ja byłem geniuszem”. Zamiast tego:

• „Zakres projektu był ograniczony do przebudowy dwóch kluczowych modułów, więc skupiłem się na elementach o największym wpływie na realizację celu.”
• „Nie mieliśmy możliwości przeprowadzenia pełnych badań z użytkownikami, dlatego wykorzystałem dane z Google Analytics i rozmowy z działem obsługi klienta.”
• „System CMS miał swoje ograniczenia, dlatego część rozwiązań trzeba było dopasować do istniejącej siatki komponentów.”

Taki język pokazuje, że nie rozkładasz rąk, tylko szukasz rozwiązań w ramach realiów projektu.

Przykład: „Redesign sklepu online” vs „projekt e‑commerce”

Dwa opisy tego samego projektu:

Wersja ogólna:

„Projekt e‑commerce dla klienta z branży kosmetycznej. Odpowiadałem za redesign strony produktowej i koszyka.”

Trudno z tego wyciągnąć, co robiłeś, jaki był problem, jaka była skala.

Wersja konkretna:

Rozszerzona, konkretna wersja opisu

W wystarczająco konkretnym opisie pokazujesz, co naprawdę się działo i z czym się mierzyłeś. Przykład rozwinięcia:

„Średniej wielkości sklep internetowy z kosmetykami naturalnymi, sprzedający głównie na rynku polskim. Udział mobile wynosił ponad połowę ruchu, ale większość transakcji kończyła się na desktopie. Projekt dotyczył redesignu strony produktowej i koszyka w ramach istniejącej platformy, bez możliwości zmiany procesora płatności.”

Takie 3–4 zdania wystarczą, żeby potencjalny klient z e‑commerce od razu pomyślał: „To o mnie”. Widzi:

• branżę i skalę (kosmetyki, rynek lokalny),
• kluczowy kontekst (duży udział mobile, problem z konwersją),
• ograniczenia technologiczne (brak ingerencji w płatności).

Dopiero na tym tle opisujesz konkretny problem i cel. Całość układa się w historię, a nie w techniczny raport.

Krok po kroku: jak „ustawić scenę” w pierwszych akapitach case study

Dobry początek case study można zbudować według prostego schematu:

1. Jedno zdanie o kliencie – kto to jest i co robi.
2. Jedno–dwa zdania o sytuacji – co się działo przed projektem.
3. Jedno zdanie o ograniczeniach – w jakich ramach działasz.
4. Dwa–trzy zdania o problemie i celu – co trzeba było zmienić i po co.

Przykład takiego startu (bez wodotrysków):

„Klientem był sklep internetowy z kosmetykami naturalnymi, działający od kilku lat na rynku polskim. W ostatnim roku ruch mobilny urósł, ale wskaźnik dokończonych zakupów na telefonach stał w miejscu. Projekt obejmował tylko stronę produktową i koszyk, z zachowaniem obecnej platformy i systemu płatności. Celem było uproszczenie ścieżki zakupu na mobile i lepsze pokazanie informacji o dostawie, bez generalnego remontu całego sklepu.”

Taki szkielet możesz w zasadzie skopiować do każdego nowego case study – zmieniają się tylko szczegóły.

Co sprawdzić w opisie kontekstu i problemu

• Czy klient z twojej grupy docelowej po 2–3 zdaniach wie, „czy to o nim”?
• Czy używasz języka bólu biznesowego („telefony na infolinię”, „porzucone koszyki”), a nie samego żargonu projektowego?
• Czy pokazałeś przynajmniej jedno realne ograniczenie projektu, zamiast udawać idealne warunki?

Pokazanie procesu projektowego krok po kroku (bez nudzenia)

Krok 1: Wybierz 3–5 kluczowych etapów, resztę odpuść

Najczęstszy błąd w opisie procesu to „dziennik pokładowy”: każda warsztatowa sesja, każde spotkanie, każda wersja makiety. Dla klienta to nie jest interesujące. Klient potrzebuje zobaczyć:

• jak myślisz,
• jak podejmujesz decyzje,
• jak reagujesz na nowe informacje.

Dlatego proces rozbij na kilka kluczowych etapów, np. 3–5, i wokół nich zbuduj historię. Przykładowy podział:

1. Rozpoznanie i analiza.
2. Określenie kierunków rozwiązania.
3. Prototypowanie i testowanie.
4. Dopracowanie i współpraca z zespołem.
5. Wdrożenie i obserwacja po starcie.

Jeśli projekt był mniejszy, spokojnie możesz połączyć część etapów, by nie rozdmuchiwać opisu. Ważne, by każdy etap miał swoje „po co”, „jak” i „co z tego wynikło”.

Krok 2: Używaj powtarzalnego mini-schematu w każdym etapie

Żeby proces był czytelny, możesz trzymać się jednego prostego schematu opisu każdego etapu:

• Cel etapu – po co: jedno–dwa zdania.
• Działania – jak: 2–4 punkty lub krótkie akapity.
• Wnioski – co z tego wynikło: 1–3 konkretne efekty.
• Decyzje – co zmieniliśmy: 1–2 zdania o tym, jak wpłynęło to na projekt.

Przykład mini-etapu z projektu e‑commerce:

Cel: zrozumieć, na którym etapie ścieżki zakupowej klienci najczęściej rezygnują z zakupu.

Działania:

• Analiza danych z Google Analytics (porzucone koszyki, długość sesji, urządzenia).
• Przegląd nagrań z narzędzia typu session recording.
• Rozmowy z działem obsługi o najczęstszych pytaniach klientów.

Wnioski:

• Wiele osób przerywało proces przy wyborze formy dostawy.
• Na mobile część użytkowników nie widziała informacji o kosztach dostawy przed koszykiem.

Decyzje: w dalszej części projektu priorytetem stało się wcześniejsze pokazanie informacji o kosztach i czasie dostawy oraz uproszczenie ekranu wyboru metody dostawy.

Krok 3: Pokaż tylko najważniejsze artefakty

Makiety, diagramy, mapy podróży są ważne, ale ich nadmiar męczy. Zamiast kilkunastu ekranów, wybierz trzy–cztery, które najlepiej pokazują zmianę:

• „przed” i „po” w kluczowym miejscu,
• widok, na którym widać rozwiązanie ważnego problemu,
• jeden zrzut, który ilustruje skalę złożoności (np. mapa przepływu).

Przy każdym artefakcie dopisz krótki komentarz, nie tylko podpis typu: „Wireframe nowej strony produktowej”. Zamiast tego lepiej:

„Na tym etapie zdecydowałem się wyciągnąć sekcję z informacjami o dostawie ponad opis produktu. Testy pokazały, że użytkownicy częściej przewijają dalej, gdy od razu widzą koszty i formy wysyłki.”

Jeśli case study jest online, możesz wykorzystać prostą animację „przed/po” lub slider. Nie jest to obowiązkowe, ale pomaga szybko zobaczyć różnicę.

Krok 4: Nie udawaj, że wszystko poszło gładko

Coraz więcej klientów wie, że projektowanie to iteracje i poprawki. W case study możesz śmiało pokazać:

• co nie zadziałało w pierwszej wersji,
• jak użytkownicy obalili twoją hipotezę,
• jak przeprojektowałeś rozwiązanie.

Krótki, szczery fragment działa lepiej niż idealna, wygładzona historia. Przykład:

„Pierwsza wersja ekranu wyboru dostawy zakładała ukrycie mniej popularnych metod w rozwijanej sekcji, żeby uprościć widok. Podczas testów użytkownicy mieli wrażenie, że dostępne są tylko dwie opcje dostawy. W kolejnej iteracji wszystkie metody pokazaliśmy w jednym widoku, za to lepiej je pogrupowaliśmy i dodaliśmy krótkie opisy.”

Co sprawdzić w opisie procesu

• Czy każdy etap ma jasno nazwany cel, zamiast suchych opisów działań?
• Czy liczba artefaktów nie przytłacza (3–5 kluczowych zamiast galerii wszystkiego)?
• Czy pokazujesz choć jeden moment, w którym zmieniłeś pierwotne założenia na podstawie danych lub testów?

Jak mówić o decyzjach projektowych, żeby brzmieć jak partner

Łączenie perspektywy użytkownika i biznesu w jednej decyzji

Decyzje projektowe robią wrażenie na kliencie wtedy, gdy pokazujesz, że widzisz obie strony: użytkownika i biznes. Klient nie chce słyszeć tylko: „to jest zgodne z dobrymi praktykami UX”. Chce wiedzieć, co ta decyzja zmienia w jego liczbach, ryzykach i codziennej pracy.

Dlatego przy ważniejszych decyzjach opisz je dwutorowo:

• Użytkownik: jak to ułatwia życie konkretnej osobie.
• Biznes: jak to pomaga w realizacji celu biznesowego (więcej zapytań, mniej błędów, szybsza obsługa).

Przykład opisu decyzji:

„Zrezygnowałem z dodatkowego kroku „podsumowanie zamówienia” przed płatnością. Dla użytkowników oznacza to krótszą, czytelniejszą ścieżkę, szczególnie na mobile. Dla biznesu skrócenie procesu zmniejsza liczbę miejsc, w których można porzucić koszyk, a jednocześnie wszystkie kluczowe informacje (cena, dostawa, adres) są nadal widoczne tuż przed kliknięciem „Płacę”.”

Mniej „ja zrobiłem”, więcej „jak razem doszliśmy do decyzji”

Jeżeli projekt realizowałeś we współpracy z zespołem klienta, pokaż to. Dla przyszłego klienta to sygnał, że potrafisz działać partnersko, a nie „wrzucać” gotowe projekty z góry.

Zamiast:

„Zaprojektowałem nowy proces onboardingu.”

lepiej:

„Po warsztacie z działem sprzedaży i obsługi klienta wspólnie ułożyliśmy nowy proces onboardingu, a ja opracowałem jego prototyp i kolejno iteracje.”

Wciąż jasno widać twoją rolę, ale klient widzi też, że nie działasz w oderwaniu od zespołu.

Używaj prostych uzasadnień zamiast autorytetu

Częsty błąd: powoływanie się na „dobrą praktykę” albo „standard branżowy” bez wyjaśnienia. Dla wielu klientów brzmi to jak pusty argument. Lepsze podejście:

• pokazujesz krótko, jakie były opcje,
• opisujesz kryteria wyboru,
• wyjaśniasz, dlaczego finalna decyzja wygrała.

Przykład:

„Rozważaliśmy trzy sposoby pokazania informacji o kosztach dostawy: w osobnej podstronie, w rozwijanym akordeonie na karcie produktu oraz w skróconej formie tuż przy cenie. W testach użytkownicy najczęściej ignorowali link do osobnej podstrony, a akordeon był mylony z tabelą rozmiarów. Najlepiej działał krótki komunikat „Dostawa od X zł – szczegóły” obok ceny, dlatego ten wariant wdrożyliśmy.”

Takie uzasadnienie jest zrozumiałe niezależnie od poziomu wiedzy cyfrowej po stronie klienta.

Mów też o tym, czego świadomie NIE zrobiliście

Partner to osoba, która potrafi odradzić klientowi niektóre pomysły i wytłumaczyć, dlaczego zostały odłożone. W case study możesz zaznaczyć decyzje, które polegały na odcięciu się od zbędnego zakresu.

Przykład zapisu:

„Na początku projektu pojawił się pomysł wprowadzenia modułu rekomendacji opartego na AI. Po analizie danych i dostępnych zasobów wspólnie z klientem zdecydowaliśmy, że ważniejsze jest doprowadzenie podstawowej ścieżki zakupu do porządku. Moduł rekomendacji opisaliśmy jako osobny etap, do realizacji po przetestowaniu efektów redesignu.”

Taki opis pokazuje, że umiesz priorytetyzować, a nie tylko realizować wszystkie życzenia z listy.

Co sprawdzić w sposobie opisywania decyzji

• Czy łączysz perspektywę użytkownika i biznesu w ważniejszych decyzjach?
• Czy pokazujesz choć jedną decyzję podjętą wspólnie z klientem lub zespołem?
• Czy w jednym miejscu opisujesz świadome „nie” – coś, co odradziłeś lub odłożyłeś na później?

Dane, efekty i rezultaty: co pokazać, gdy nie masz „twardych liczb”

Krok 1: Zbierz to, co już istnieje „w tle”

Nie zawsze masz dostęp do dokładnej analityki czy raportów sprzedaży. To nie znaczy, że w case study musisz pisać ogólniki. Zanim uznasz, że „nie ma danych”, zrób mały przegląd:

• maile i wiadomości od klientów (częstotliwość konkretnych problemów),
• notatki z rozmów z supportem lub sprzedażą,
• porównanie liczby pytań o daną funkcję „przed” i „po”,
• subiektywne, ale konkretne opinie zespołu: „formularz wreszcie da się obsłużyć na telefonie bez przewijania w bok”.

Nawet jeśli nie możesz użyć precyzyjnych liczb, możesz opisać zmiany jakościowe w logiczny sposób.

Krok 2: Opisuj zmiany w zachowaniach, nie w domysłach

Zamiast ogólnego „użytkownikom jest łatwiej”, szukaj sygnałów, które tę tezę podpierają. Kilka przykładów:

• „Po wprowadzeniu nowej strony FAQ dział obsługi klienta otrzymuje wyraźnie mniej pytań o warunki dostawy.”
• „Na testach użyteczności użytkownicy bez podpowiedzi byli w stanie przejść cały proces rezerwacji w czasie krótszym niż w starej wersji.”
• „Handlowcy zgłaszają, że klienci lepiej rozumieją różnice między planami cenowymi po zmianie układu cennika.”

Takie stwierdzenia są dalej miękkimi danymi, ale dużo lepszymi niż: „projekt poprawił doświadczenie użytkownika”.

Krok 3: Użyj zakresów, proporcji i porównań zamiast dokładnych cyfr

Gdy nie możesz podawać konkretnych liczb (np. ze względu na NDA), często możesz użyć opisów względnych:

• „liczba porzuconych koszyków spadła o kilkadziesiąt procent”,

Krok 4: Opracuj bezpieczny sposób mówienia o wynikach

Przy projektach objętych NDA często nie możesz ujawnić ani klienta, ani dokładnych liczb. Nadal jednak da się pokazać efekty tak, by były wiarygodne i nie łamały umów. Pomaga kilka prostych zabiegów:

• anonimizacja branżowa: „klient z branży fintech / edukacyjnej / e‑commerce” zamiast nazwy firmy,
• zaokrąglone okresy czasu: „po kilku miesiącach od wdrożenia” zamiast konkretnych dat,
• opis trendu zamiast liczby: „liczba zgłoszeń do supportu dotyczących resetu hasła spadła wyraźnie” + krótki komentarz, dlaczego.

Jeżeli obawiasz się, że idziesz za daleko, możesz dodać zdanie porządkujące:

„Ze względu na NDA nie mogę podać dokładnych liczb, ale trend jest stały i potwierdzony w kilku kolejnych raportach klienta.”

Krok 5: Zbuduj jeden „ekran wyników” w każdym case study

Zamiast rozsypywać efekty po całym opisie, zbierz je w jednym, czytelnym fragmencie – jak na prostym dashboardzie. Klient skanuje takie miejsce w kilkanaście sekund, więc im bardziej przejrzyście, tym lepiej.

Prosty układ może wyglądać tak:

• Cel na start: 1–2 zdania, co miało się zmienić,
• Co zrobiliśmy: krótka lista 3–5 najważniejszych działań,
• Efekty: liczby (jeśli możesz) + jakościowe zmiany,
• Cytat klienta / zespołu: jedno zdanie, które „zamyka” historię.

Dzięki temu nawet ktoś, kto nie ma czasu na całą opowieść, zobaczy, że twoje projekty realnie coś zmieniają, a nie kończą się na pięknych makietach.

Co sprawdzić w sekcji o efektach

• Czy jasno widać, jaki był cel projektu i czy się do niego odnosisz przy opisywaniu wyników?
• Czy używasz konkretnych przykładów zachowań zamiast ogólnych stwierdzeń typu „użytkownikom jest łatwiej”?
• Czy przynajmniej część efektów jest pokazana jak na „ekranie wyników” – w jednym, zebranym miejscu?
• Czy opisujesz rezultaty w sposób zgodny z NDA (bez nazw, wrażliwych danych, z anonimizacją tam, gdzie trzeba)?

Storytelling w case study: jak prowadzić czytelnika przez historię projektu

Krok 1: Ułóż projekt jak prosty scenariusz

Najprostszy i bardzo skuteczny schemat opowieści projektowej to:

• punkt wyjścia: jak wyglądała sytuacja „przed”,
• konflikt: co konkretnie nie działało, gdzie bolało,
• droga: jakie kroki podjęliście, żeby to zmienić,
• finał: co jest „po” – nowy stan i efekty.

W praktyce możesz to rozpisać krótkimi akapitami we wstępie case study:

„Klient zgłosił się, bo mimo dużego ruchu na stronie mało osób kończyło zakup. W rozmowach z supportem regularnie wracał problem skomplikowanego formularza. Naszym celem było uproszczenie ścieżki zakupu na mobile i zmniejszenie liczby porzuconych koszyków. W ciągu kilkunastu tygodni przeszliśmy od audytu UX, przez testy z użytkownikami, do wdrożenia nowej wersji checkoutu.”

Taki wstęp „ustawia scenę” i podpowiada czytelnikowi, czego ma szukać w dalszych częściach opisu.

Krok 2: Wprowadź bohaterów, zamiast pisać o „użytkowniku” w próżni

Zamiast powtarzać ogólną figurę „użytkownika”, pokaż 1–2 krótkie postacie, które reprezentują kluczowe grupy. Nie muszą to być pełne persony z imieniem, zdjęciem i tabelką potrzeb. Wystarczą dwa–trzy zdania kontekstu.

Przykład:

• „Marta, właścicielka małej kawiarni, zamawia kawę raz na kilka tygodni, zwykle w biegu, z telefonu.”
• „Paweł, kierownik magazynu, korzysta z systemu codziennie, ale mało komfortowo czuje się w nowych interfejsach.”

Potem, opisując decyzje projektowe, możesz do nich wracać:

„Widok zamówienia zaprojektowaliśmy tak, by Marta mogła złożyć je w przerwie między obsługą klientów, bez konieczności logowania.”

To drobiazg, ale sprawia, że czytelnik widzi konkretnych ludzi, a nie abstrakcyjne „grupy docelowe”.

Krok 3: Używaj „scen”, w których coś się dzieje

Zamiast suchego opisu „przeprowadziliśmy testy z 5 użytkownikami”, pokaż jedną małą scenę z tego etapu. Wystarczy jedno–dwa zdania:

• „Już na drugim wywiadzie okazało się, że nikt nie zauważa linku do regulaminu zwrotów – wszyscy przewijali go odruchowo.”
• „Podczas testu na telefonie użytkownik przez kilkanaście sekund szukał przycisku ‘Dalej’, który schował się poza widocznym obszarem ekranu.”

Takie sceny dają poczucie, że projekt naprawdę się wydarzył, a wnioski nie są wzięte z powietrza. Nie przesadzaj z ich liczbą – 2–3 na całe case study w zupełności wystarczą.

Krok 4: Doprowadź wątki do końca

Jeżeli we wstępie opisujesz konkretny problem, wróć do niego w sekcji o efektach. Klient podświadomie sprawdza, czy domykasz historię, czy tylko „rozpływasz się” w procesie.

Przykładowo:

„Na początku projektu celem było zmniejszenie liczby porzuconych koszyków. Po wdrożeniu nowego checkoutu klient zauważył, że porzucenia na ostatnim kroku są dużo rzadsze, a support praktycznie przestał dostawać pytania o problemy z płatnością.”

Jeśli cel nie został osiągnięty w pełni, również możesz to napisać – i dodać, co dalej:

„Choć nadal część użytkowników rezygnuje z zakupu na etapie wyboru dostawy, zespół ma teraz jasne dane, gdzie dokładnie pojawia się problem i które warianty dostawy wymagają dopracowania.”

Krok 5: Pilnuj tempa – skracaj tam, gdzie nic się nie „przewraca”

Nie każdy etap projektu jest tak samo ważny dla historii. Klient nie musi czytać szczegółowego opisu badań benchmarkowych, jeśli nic przełomowego z nich nie wynikło. Zastosuj prostą zasadę:

• więcej miejsca daj tam, gdzie coś się zmieniło (decyzja, pivot, odkrycie z badań),
• mniej miejsca poświęć rutynowym czynnościom (kolejne rundy dopracowań wizualnych, techniczne szczegóły wdrożenia, jeśli nie są kluczowe dla efektu).

Jeśli w trakcie pracy wydarzył się zwrot – klient zmienił priorytety, pojawił się nowy wymóg prawny, zmieniły się zasoby – warto pokazać, jak to wpłynęło na historię projektu i twoje decyzje.

Co sprawdzić w warstwie storytellingu

• Czy case study ma czytelny początek (kontekst), środek (proces) i finał (efekty)?
• Czy pokazujesz choć jedną konkretną „scenę” z badań, warsztatu lub testów, a nie tylko suche podsumowania?
• Czy wprowadziłeś choć jednego bohatera (krótki opis typu „Marta, właścicielka kawiarni”), do którego nawiązujesz przy decyzjach projektowych?
• Czy wątki z początku (problemy, cele) są domknięte w części o rezultatach, nawet jeśli efekty są częściowe?

Jak technicznie „opakować” case study, żeby chciało się je czytać

Krok 1: Zadbaj o szybki „podgląd” – streszczenie na górze

Wielu klientów tylko skanuje treść. Pomaga krótki blok na samej górze case study (tuż pod tytułem), w którym w kilku linijkach pokazujesz sedno:

• Branża / typ klienta (np. „platforma SaaS B2B dla małych firm”),
• Główny problem („użytkownicy gubili się w procesie konfiguracji”),
• Zakres twojej pracy („research, warsztaty, UX/UI, współpraca z devami”),
• Kluczowy efekt („krótszy onboarding, mniej zgłoszeń do supportu”).

Taki „nagłówek” pozwala szybko ocenić, czy case study jest w ogóle relewantne dla osoby po drugiej stronie – i zachęca do wczytania się głębiej.

Krok 2: Używaj powtarzalnej struktury między case studies

Jeśli każdy projekt opisujesz innym schematem, klient za każdym razem musi „uczyć się” twojego sposobu opowiadania. Prostsza droga: ustal 4–6 stałych sekcji, np.:

1. Kontekst i cel projektu,
2. Wyzwania użytkowników i biznesu,
3. Proces krok po kroku,
4. Kluczowe decyzje projektowe,
5. Efekty i wnioski,
6. Co dalej (następne etapy, jeśli były).

Nie musisz zawsze używać tych samych nagłówków słowo w słowo, ale układ powinien być rozpoznawalny. Dla klienta to sygnał, że masz uporządkowany sposób pracy.

Krok 3: Ogranicz długość – lepiej mniej case studies, ale dopracowanych

Rozbudowane, 30‑ekranowe opowieści rzadko ktoś czyta do końca. Jeśli masz taki projekt, spróbuj go skondensować do:

• 3–5 głównych etapów pracy,
• 3–7 kluczowych artefaktów (ekrany, mapy, diagramy),
• 2–3 najważniejszych decyzji z uzasadnieniem,
• 1–2 dobrze opisanych efektów.

Jeśli czujesz, że ucinasz coś boleśnie, możesz dodać link „dla geeków” – np. do PDF‑a z pełną dokumentacją albo osobnej podstrony z dodatkowymi materiałami. Główne case study powinno jednak pozostać lekkie i przyswajalne.

Krok 4: Pokaż swoją rolę w projekcie w jednym miejscu

W większych projektach łatwo zgubić, czym dokładnie się zajmowałeś. Dobrze działa krótki blok „Moja rola”, gdzie w 3–5 punktach opisujesz konkretnie:

• za co odpowiadałeś,
• z kim współpracowałeś (UX writer, PM, devy, marketing),
• jakie decyzje były po twojej stronie.

Przykład:

„Moja rola: prowadzenie warsztatów z zespołem sprzedaży, przygotowanie makiet low‑fi i high‑fi, zaplanowanie i przeprowadzenie testów z 6 użytkownikami, współpraca z front‑endem przy wdrożeniu.”

Klient dzięki temu widzi, czy twoje doświadczenie pokrywa się z tym, czego potrzebuje – i czy jesteś osobą strategiczną, czy raczej skupioną na wykonaniu.

Co sprawdzić w sposobie prezentacji case study

• Czy każdy projekt ma krótkie streszczenie na górze, z którego widać branżę, problem i efekt?
• Czy case studies mają powtarzalną strukturę, dzięki czemu łatwo je porównać?
• Czy w jednym miejscu opisujesz swoją rolę, zamiast rozrzucać to po całym tekście?
• Czy długość i liczba artefaktów nie przytłacza, a najważniejsze elementy są odpowiednio wyeksponowane?

Najczęściej zadawane pytania (FAQ)

Jak napisać dobre case study do portfolio UX/UI krok po kroku?

Krok 1: Zdefiniuj szkielet. Użyj prostego układu: kontekst, problem, proces, rozwiązanie, efekty, wnioski. Zanim cokolwiek napiszesz, wypisz w punktach odpowiedzi na te sześć elementów – dopiero potem rozbuduj je do krótkich akapitów.

Krok 2: Opisz proces jak historię, nie jak listę narzędzi. Zamiast „zrobiliśmy warsztat i makiety”, napisz: „krok 1 – zebraliśmy dane i ustaliliśmy priorytety, krok 2 – przygotowałem dwa warianty, krok 3 – przetestowaliśmy je i zostawiliśmy tylko to, co działało”. Dodawaj krótkie wnioski przy każdym etapie.

Co sprawdzić: czy osoba nietechniczna (np. znajomy spoza branży) rozumie, o co chodziło w projekcie, co zrobiłeś i jaki był finał; jeśli nie – uprość język i dołóż kontekst.

Co musi się znaleźć w case study, żeby klient biznesowy od razu mi zaufał?

Najbardziej zwiększają zaufanie trzy elementy: jasny problem biznesowy, konkretny opis procesu oraz chociaż jeden efekt. Klient chce widzieć, z jaką sytuacją startową pracowałeś, co dokładnie było do naprawienia i jak krok po kroku do tego podszedłeś, a nie tylko końcowe ekrany.

Dodaj też krótką sekcję „wnioski” – 2–3 zdania o tym, czego się nauczyłeś i co dziś zrobiłbyś inaczej. To sygnał, że potrafisz wyciągać lekcje, a nie tylko „klepać projekty”. Gdy możesz, dorzuć krótki komentarz klienta lub opis zmiany w zachowaniu użytkowników (np. mniej pytań na support).

Co sprawdzić: czy z case study da się jednym zdaniem odpowiedzieć na pytanie klienta „z czym mieli problem i jak to rozwiązałeś?”. Jeśli nie – doprecyzuj część o problemie i celu.

Jak pokazać proces projektowy w case study, jeśli projekt był mały i prosty?

Nawet małe zlecenie można rozpisać na logiczne kroki. Zamiast udawać duży projekt, pokaż rozsądną skalę działań: krótka analiza sytuacji, szybkie szkice, jedna–dwie iteracje, wdrożenie. Ważne, by przy każdym kroku było „po co to robiłem” i „co z tego wynikło”.

Przykład: krok 1 – przegląd obecnej strony i krótkie rozmowy z klientem, krok 2 – szkice i jeden wariant graficzny, krok 3 – poprawki po feedbacku, krok 4 – przekazanie plików deweloperowi z opisem kluczowych decyzji.

Co sprawdzić: czy proces nie wygląda jak „magia”: było źle → jest ładnie. Jeśli brakuje choć dwóch–trzech etapów pośrednich, dopisz, jak dochodziłeś do finału.

Jak pisać o efektach w case study, jeśli nie mam twardych danych (liczb)?

Jeśli nie masz analityki, skup się na efektach jakościowych i konkretnych zmianach. Możesz opisać: mniej pytań na support, krótszą ścieżkę w formularzu, bardziej czytelne informacje, lepszy odbiór projektu przez zespół sprzedaży, usprawnienie współpracy (np. mniej „gaszenia pożarów”).

Dobre podejście: krok 1 – wypisz, co dokładnie się zmieniło w interfejsie lub materiale; krok 2 – zapisz, jak to odczuli użytkownicy lub klient; krok 3 – dodaj jedno zdanie o tym, jak te wnioski wykorzystujesz w kolejnych projektach.

Co sprawdzić: czy efekty są konkretne („zmniejszyliśmy liczbę kroków z 5 do 3”), a nie ogólne („użytkownikom jest teraz wygodniej”). Jeśli brzmią jak ogólnik, uszczegółów je.

Ile case studies powinno być w portfolio projektanta i które projekty wybrać?

Lepsze jest 3–5 dopracowanych case studies niż 15 powierzchownych. Wybierz te projekty, w których miałeś realny wpływ na proces, możesz opisać decyzje, a nie tylko „pokolorowałeś” gotowe założenia. Dobrze, jeśli pokazują różne typy wyzwań: np. redesign, start od zera, usprawnienie fragmentu produktu.

Układ może być prosty: na górze 2–3 najmocniejsze case studies „procesowe”, niżej kilka skróconych realizacji „gallery style” tylko dla pokazania estetyki. Dzięki temu klient zobaczy zarówno sposób myślenia, jak i styl.

Co sprawdzić: czy każde case study dodaje coś nowego (inny typ klienta, inny problem, inna skala), czy powtarzasz trzy razy to samo w innej kolorystyce.

Jak opisać case study, kiedy klient nie pozwala podawać nazwy firmy i liczb?

Użyj opisu ogólnego, ale konkretnego: „klient z branży finansowej”, „lokalna sieć sklepów spożywczych”, „startup SaaS dla małych firm”. Zamiast dokładnych liczb możesz pisać o trendach: „wzrost konwersji”, „spadek porzuceń formularza”, „mniej zgłoszeń na infolinii”. Kluczowy jest jasno opisany problem i proces, nie marka.

Dobrze działa też lekkie „zamaskowanie” szczegółów: zmiana kolorystyki, brak wrażliwych ekranów, pokazanie fragmentów zamiast całego systemu. Dodaj jedno zdanie, że case study jest zanonimizowane ze względu na umowę z klientem – to pokazuje, że dbasz o poufność.

Co sprawdzić: czy bez nazwy firmy nadal rozumiesz, co to był za biznes, z jaką sytuacją startową pracowałeś i do jakiego celu dążyliście.

Jak uniknąć typowych błędów przy tworzeniu case study do portfolio?

Najczęstsze błędy to: brak kontekstu, opis tylko finalnych ekranów, żargon niezrozumiały dla klienta i brak efektów. Projekt wygląda wtedy jak „kolejny ładny obrazek”, a nie rozwiązanie konkretnego problemu. Druga pułapka to zbyt długie, techniczne opisy, których nikt nie czyta do końca.

Dobry filtr: krok 1 – skróć tekst tak, żeby każdą sekcję (kontekst, problem, proces, rozwiązanie, efekty, wnioski) dało się przeczytać w 1–2 minuty; krok 2 – zamień żargon („low fidelity wireframes”) na zwykły język („wstępne szkice ekranów”); krok 3 – dodaj choć jedną decyzję projektową z krótkim „dlaczego tak”.

Co sprawdzić: czy case study da się przeskanować wzrokiem w 30–60 sekund – nagłówki, śródtytuły, wyróżnione kroki. Jeśli wszystko wygląda jak jeden, długi blok tekstu, podziel treść i uprość.

Kluczowe Wnioski

• Krok 1: Przestaw myślenie z „ładnych obrazków” na rozwiązywanie problemów – klient szuka w portfolio dowodu, że rozumiesz biznes, umiesz prowadzić proces i poradzisz sobie z jego konkretną sytuacją, a nie tylko dobrze projektujesz ekrany.
• Krok 2: Dobrze opisane case study obniża ryzyko po stronie klienta – pokazujesz, że kontrolujesz terminy, zakres, iteracje i komunikację, więc maleje obawa przed „chaosem projektowym” i przepalonym budżetem.
• Krok 3: Zbuduj portfolio decyzyjne zamiast galerii – przy każdym projekcie pokaż kontekst, problem, proces, rozwiązanie i efekty, żeby klient biznesowy mógł łatwo odpowiedzieć sobie na pytanie: „Czy ta osoba ogarnie mój projekt od A do Z?”.
• Krok 4: Używaj case studies do pozycjonowania się jako partner, nie wykonawca – jasny opis procesu, zadawanie trudnych pytań i pokazanie wpływu na biznes pomagają negocjować wyższe stawki i dłuższe współprace (np. retainer zamiast pojedynczego bannera).
• Krok 5: Trzymaj się prostego szkieletu – Kontekst, Problem, Proces, Rozwiązanie, Efekty, Wnioski – ta struktura porządkuje historię projektu niezależnie od typu zlecenia (UX, identyfikacja, kampania), dzięki czemu klient się nie gubi.
• Typowy błąd: pokazywanie tylko „przed i po” – bez opisania sytuacji startowej, celu, kluczowych kroków i choć jednego mierzalnego lub jakościowego efektu klient nie ma podstaw, by uznać cię za osobę ogarniającą proces.

Bibliografia i źródła

• Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability. New Riders (2014) – Zasady projektowania zorientowanego na użytkownika i użyteczność
• The Design of Everyday Things. Basic Books (2013) – Myślenie projektowe, modele mentalne i proces rozwiązywania problemów
• Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster (2016) – Struktura procesu projektowego, iteracje i testowanie rozwiązań
• Lean UX: Designing Great Products with Agile Teams. O’Reilly Media (2016) – Proces UX, współpraca z biznesem, iteracyjna praca nad produktem
• About Face: The Essentials of Interaction Design. Wiley (2014) – Metody projektowania interfejsów i podejmowania decyzji projektowych