Jak zbudować portfolio (dla projektantów i programistów)

Wybór, co się w nim znajdzie

1. 1Wypisz każdy projekt, który mógłbyś/mogłabyś pokazać — praca, freelance, projekty poboczne, prace na studiach, hackathony, open source.
2. 2Oceń każdy pod kątem: znaczenia dla prac, których chcesz, jaką część wyniku możesz sobie przypisać i czy potrafisz wyjaśnić swój konkretny wkład.
3. 3Zostaw 3–5 najlepszych. Odrzuć wszystko, co musiałbyś/musiałabyś mocno obwarowywać zastrzeżeniami lub o czym nie możesz mówić z powodu umowy o poufności.
4. 4Zadbaj, by zestaw pokazywał różnorodność — różne rodzaje problemów, a nie pięć wersji tego samego ekranu.

Struktura studium przypadku

Studium przypadku to krótka historia o stałej formie. Celuj w coś, co czytelnik przejrzy w dwie minuty, a przeczyta w całości w pięć.

1. Przegląd (2–3 zdania)
   Czym jest produkt, dla kogo, jaki był projekt.

2. Moja rola
   Twoje stanowisko, zespół, ramy czasowe, za co odpowiadałeś/odpowiadałaś, a do czego się dołożyłeś/dołożyłaś.

3. Problem
   Problem użytkownika lub biznesowy i skąd wiedziałeś/wiedziałaś, że jest realny (dane, badania, skargi).

4. Proces
   3–4 kluczowe ruchy, które wykonałeś/wykonałaś. Pokaż artefakty: szkice, przepływy, prototypy, eksperymenty, PR-y.
   Uwzględnij co najmniej jeden kompromis lub ślepą uliczkę i dlaczego zmieniłeś/zmieniłaś kierunek.

5. Rozwiązanie
   Efekt końcowy, z materiałami wizualnymi lub działającym linkiem. Opatrz komentarzem decyzje, które mają znaczenie.

6. Wpływ
   Liczby, jeśli je masz (konwersja, czas ładowania, skuteczność zadań, adopcja). Jeśli nie, wyniki jakościowe i co zmierzyłbyś/zmierzyłabyś dalej.

7. Czego się nauczyłem/nauczyłam
   Jedna lub dwie szczere refleksje.

Jeśli jesteś programistą

• Każdy projekt: link do działającego demo i link do repozytorium, oba działające. Zepsute demo jest gorsze niż brak dema.
• Napisz prawdziwy README: co robi, zrzut ekranu lub GIF, stos technologiczny, jak uruchomić lokalnie, co zrobiłbyś/zrobiłabyś dalej.
• Przypnij swoje 4–6 najlepszych repozytoriów na profilu GitHub i dodaj README profilu.
• Uwypuklij sygnały jakości kodu: testy, CI, jasne commity, sensowna struktura. Oceniający naprawdę otwierają kod.
• Wkład open source się liczy — podlinkuj scalone PR-y i krótko powiedz, co każdy zrobił.
• Przy rolach back-end lub danych, gdzie nie ma nic wizualnego, jasny diagram architektury i pisemny opis zastępują zrzuty ekranu.

# Nazwa projektu
Jedno zdanie o tym, co robi i dla kogo jest.

![demo](demo.gif)

## Dlaczego to zbudowałem/zbudowałam
2–3 zdania.

## Stos
Języki, frameworki, ważne biblioteki, hosting.

## Uruchomienie lokalne
Kroki.

## Ważne decyzje
- Decyzja i jej powód
- Kompromis, który podjąłeś/podjęłaś

## Co dalej
Krótka lista.

Jeśli jesteś projektantem

• Pokaż artefakty procesu, nie tylko finalne kompozycje: notatki z badań, przepływy użytkownika, wireframe'y, iteracje.
• Uwzględnij wersje, które nie trafiły do wdrożenia, i powiedz dlaczego — to pokazuje osąd.
• Utrzymuj wysoki poziom rzemiosła wizualnego na samej stronie portfolio; to próbka pracy, czy tego chcesz, czy nie.
• Wiąż każdą decyzję z potrzebą użytkownika lub celem biznesowym, a nie z osobistym gustem.
• Przy rolach UX zaczynaj od myślenia; przy rolach wizualnych lub brandingowych zaczynaj od rzemiosła — ale oba potrzebują obu.

Gdzie to hostować

• Osobista strona na własnej domenie to najmocniejsza opcja — pełna kontrola, wygląda na zaangażowanie.
• Szybko do opublikowania: szablon na kreatorze stron albo prosta strona statyczna na GitHub Pages, Vercel lub Netlify.
• Projektanci mogą uzupełnić zasięg o Behance lub Dribbble, ale prawdziwe studia przypadków trzymaj na własnej stronie.
• Programiści: GitHub jest nienegocjowalny; strona portfolio to plus.
• Zawsze miej wersję PDF lub w slajdach jednego–dwóch studiów przypadków na wypadek, gdy ktoś zapyta mailem.

Częste błędy

• Za dużo projektów, żaden wyjaśniony dogłębnie.
• Zrzuty ekranu bez opisu problemu, roli czy wyniku.
• Przypisywanie sobie wyników zespołu bez powiedzenia, co zrobiłeś/zrobiłaś osobiście.
• Brak danych kontaktowych lub oczywistego sposobu na kontakt.
• Linki chronione hasłem lub zepsute w wersji wysyłanej do rekruterów.
• Zakopanie najlepszego projektu na trzeciej stronie.

Najczęściej zadawane pytania