Dobre portfolio nie musi być największe ani najbardziej efektowne. Powinno pozwalać ustalić, co wykonawca zrobił, jaki problem rozwiązywał i jak działają pokazane strony.
Otwórz kilka działających realizacji zamiast oceniać wyłącznie makiety i zrzuty ekranu.
Porównaj typ strony, jej funkcje, odbiorców i cel z własnym projektem.
Zapytaj o dokładny zakres odpowiedzialności wykonawcy.
Przetestuj wersję mobilną, najważniejsze funkcje i wydajność realizacji.
Portfolio wykonawcy strony internetowej jest punktem wyjścia do oceny, a nie gotowym dowodem jakości współpracy. Najbardziej użyteczna analiza obejmuje cztery warstwy: dopasowanie projektu, działanie strony, autorstwo oraz możliwość potwierdzenia informacji. Nie pozwala natomiast samodzielnie ocenić terminowości, komunikacji, kosztów ani rezultatów biznesowych.
Portfolio to materiał do sprawdzenia, nie tylko do oglądania
Portfolio ma wartość wtedy, gdy prowadzi do działających stron i dostarcza informacji o udziale wykonawcy. Zrzut ekranu pokazuje tylko wybrany widok. Nie pozwala przetestować menu, formularza, wersji mobilnej ani całej ścieżki użytkownika. Dlatego analizę należy zacząć od otwarcia rzeczywistych realizacji.[1][3][4]
Sama dostępność strony nie potwierdza jednak, że wykonawca odpowiadał za cały projekt. Mógł przygotować wyłącznie warstwę wizualną, wdrożyć dostarczony projekt albo wykonać jeden z modułów. Portfolio powinno więc umożliwiać rozdzielenie tego, co widać, od tego, co rzeczywiście można przypisać wykonawcy.
Liczbę realizacji i różnorodność branż lepiej traktować jako kontekst niż jako wynik oceny. To praktyczna zasada porządkowania decyzji, a nie wniosek z niezależnego badania rynku. Więcej mówi możliwość sprawdzenia kilku odpowiednich projektów niż długa lista logotypów bez opisów i aktywnych odnośników.[3][4]
Przy pierwszej selekcji wybierz kilka realizacji i zapisz dla każdej z nich typ strony, najważniejsze funkcje, deklarowany zakres udziału wykonawcy oraz elementy możliwe do samodzielnego potwierdzenia. Taka analiza w czterech warstwach jest procedurą praktyczną, a nie zwalidowaną skalą punktową.
Ustal, co wykonawca zrobił przy pokazanej realizacji
Przy każdym ważnym projekcie trzeba ustalić, za co dokładnie odpowiadał wykonawca. Strategia, architektura informacji, UX, projekt wizualny, treści, kod, wdrożenie i późniejsze utrzymanie mogą należeć do różnych osób lub firm. Dopiero znajomość tego podziału pozwala uczciwie ocenić doświadczenie.[1][3][4]
Pytania, które odsłaniają zakres prac
Jaki był cel strony i problem, który należało rozwiązać?
Czy wykonawca odpowiadał za strategię, UX i projekt wizualny, czy otrzymał gotowe materiały?
Kto przygotował treści, kod i integracje?
Kto przeprowadził wdrożenie i testy?
Czy w projekcie uczestniczyli podwykonawcy lub zespół klienta?
Kto obecnie utrzymuje stronę i wprowadza na niej zmiany?
Czy zakres pracy można potwierdzić w opisie projektu, publicznych materiałach albo u klienta?
Odpowiedź wykonawcy pozostaje deklaracją. Gdy zakres realizacji ma istotne znaczenie dla decyzji, może wymagać potwierdzenia u klienta lub w dostępnych publicznie materiałach. Nie należy przy tym oczekiwać ujawnienia informacji objętych poufnością.
Sygnały, że potrzebna jest dodatkowa weryfikacja
Potrzebę dopytania zwiększają brak aktywnego adresu strony, niejasny opis roli wykonawcy, prezentowanie samych grafik oraz odpowiedzi, które nie rozdzielają projektu od wdrożenia. Są to sygnały ostrzegawcze, a nie automatyczny dowód nierzetelności. Strona mogła zostać wyłączona, przebudowana przez inną firmę albo objęta ograniczeniami umownymi.
Nie należy również uznawać samego logotypu klienta za dowód pełnego autorstwa. Prawidłowo ograniczony zakres prac nie jest wadą, jeśli został jasno opisany i odpowiada kompetencjom potrzebnym w nowym projekcie.
Porównaj podobieństwo problemu, a nie tylko branżę i styl
Najbardziej przydatne są realizacje podobne do planowanego projektu pod względem celu, funkcji, odbiorców i skali. Zbliżona kolorystyka albo obecność klienta z tej samej branży nie wystarczają. Dwie wizualnie podobne strony mogą wymagać innych integracji, treści i ścieżek użytkownika.[2][3][4]
Gdy punktem wyjścia jest lokalna usługa, na przykład tworzenie stron Pruszków, położenie wykonawcy może być jednym z warunków wyboru, ale nie zastępuje analizy jego zakresu pracy i podobnych realizacji.
Typ strony
Porównaj, czy realizacja jest stroną wizerunkową, serwisem usługowym, sklepem, portalem albo platformą o zbliżonym zakresie.
Cel projektu
Ustal, jaki rezultat miała wspierać strona i czy opis realizacji wyjaśnia decyzje podjęte w związku z tym celem.
Odbiorcy
Oceń, czy projekt uwzględniał potrzeby grupy podobnej do odbiorców planowanej strony.
Funkcje
Szukaj doświadczenia z potrzebnymi formularzami, katalogiem, rezerwacjami, kontem użytkownika lub integracjami, jeżeli należą do zakresu zlecenia.
Skala i złożoność
Porównaj zakres treści, liczbę funkcji oraz udział różnych osób w realizacji.
Opis projektu
Oceń, czy case study określa problem, zakres prac i ograniczenia, zamiast przedstawiać wyłącznie końcowy wygląd.
Dopasowanie portfolio do własnych potrzeb nie gwarantuje powodzenia nowego projektu. Wynik zależy także od procesu współpracy, a w przedsięwzięciach ze szczególnymi wymaganiami doświadczenie branżowe może mieć większe znaczenie. Kryteria służą więc selekcji i przygotowaniu pytań, nie wydaniu ostatecznego werdyktu.
Przetestuj działające strony z portfolio
Działającą realizację należy obejrzeć na telefonie, uruchomić jej najważniejsze funkcje i potraktować pomiar wydajności jako sygnał pomocniczy. Jeden test nie ocenia całej strony, a tym bardziej wszystkich kompetencji wykonawcy.
Otwórz stronę na telefonie i komputerze. Porównaj, czy treść pozostaje czytelna, a najważniejsze elementy są dostępne na obu urządzeniach.
Uruchom menu i podstawowe interakcje. Przejdź ścieżkę, która ma znaczenie dla użytkownika danej strony.
Sprawdź formularz bez wysyłania niepotrzebnych danych. Oceń układ pól, komunikaty i możliwość obsługi na małym ekranie.
Zwróć uwagę na stabilność działania. Zapisz zauważone problemy jako pytania do wykonawcy, zamiast od razu przypisywać mu ich przyczynę.
Uruchom PageSpeed Insights. Oddziel wyniki testu laboratoryjnego od danych rzeczywistych użytkowników, jeśli są dostępne.
Wykonaj wstępną ocenę dostępności. Potraktuj ją jako przygotowanie do rozmowy, a nie potwierdzenie zgodności ze standardem.
Test mobilny i funkcjonalny
Responsywność oznacza w tym kontekście coś więcej niż zmniejszenie układu. Należy sprawdzić, czy na telefonie można posłużyć się menu, przeczytać treść, wypełnić formularz i przejść najważniejszą ścieżkę użytkownika. Pojedyncza poprawnie działająca czynność nie zastępuje pełnych testów, ale pozwala wychwycić problemy wymagające wyjaśnienia.
Trzeba też zachować ostrożność przy przypisywaniu odpowiedzialności. Publiczna strona mogła zostać zmieniona po zakończeniu współpracy albo być obecnie utrzymywana przez inny podmiot. Zauważony problem warto więc zestawić z pytaniem o datę realizacji i aktualny zakres opieki.
Jak czytać PageSpeed Insights bez nadinterpretacji
PageSpeed Insights prezentuje dane laboratoryjne z Lighthouse oraz, gdy są dostępne, dane rzeczywistych użytkowników z Chrome UX Report.[5] Wynik laboratoryjny pochodzi z kontrolowanego testu i nie jest tym samym co doświadczenie wszystkich osób korzystających ze strony. Dane terenowe również nie pojawią się przy każdej realizacji.
Wśród Core Web Vitals można sprawdzić Largest Contentful Paint, czyli LCP, Interaction to Next Paint, czyli INP, oraz Cumulative Layout Shift, czyli CLS.[6] Ich interpretacja powinna odpowiadać aktualnej dokumentacji i uwzględniać kontekst urządzenia. Progi oraz zestaw metryk mogą się zmieniać, a pojedynczy pomiar nie zastępuje danych terenowych.
W praktyce wynik jest podstawą do zadania pytań: czy wykonawca mierzył wydajność, jakie ograniczenia miała realizacja i które elementy zależały od zewnętrznych rozwiązań. Nie należy na jego podstawie tworzyć rankingu wykonawców ani wyciągać wniosków o całej jakości projektu.
Dostępność: co można ocenić wstępnie
Jeżeli dostępność jest istotnym wymaganiem projektu, ogólna deklaracja nie wystarczy. Ocena powinna odnosić się do konkretnych kryteriów WCAG.[7] Automatyczne narzędzie nie sprawdza jednak wszystkich kryteriów i samo nie potwierdza pełnej zgodności.
Na etapie portfolio można wstępnie zwrócić uwagę na możliwość obsługi klawiaturą, czytelność treści, komunikaty formularzy i zachowanie interaktywnych elementów. Taka obserwacja pomaga przygotować pytania, lecz nie jest audytem dostępności ani pełnym testem użyteczności.
Porównaj portfolio wykonawców w jednej macierzy
Portfolio kilku wykonawców najlepiej zestawić według tych samych kryteriów. W macierzy należy oddzielić informacje potwierdzone od deklaracji i od danych, których nie udało się uzyskać. Brak danych nie oznacza wyniku negatywnego, ale wskazuje, o co trzeba dopytać.
Kryterium
Co potwierdza portfolio
Co sprawdzić lub o co zapytać
Ocena / brak danych
Działające realizacje
Możliwość otwarcia i samodzielnego przetestowania strony
Czy projekt jest nadal dostępny i kiedy został wykonany?
Potwierdzone, niepotwierdzone albo do wyjaśnienia
Zakres udziału
Opis roli wykonawcy i wykonanych etapów
Kto odpowiadał za UX, wygląd, treści, kod i wdrożenie?
Potwierdzone, deklarowane albo brak danych
Dopasowanie projektu
Podobieństwo celu, odbiorców, funkcji i skali
Które doświadczenia odnoszą się do planowanego zlecenia?
Wysokie, częściowe albo niewystarczające dane
Wersja mobilna
Działanie układu i funkcji na telefonie
Czy można przejść najważniejszą ścieżkę użytkownika?
Bez widocznych problemów, wymaga wyjaśnienia albo brak testu
Kluczowe funkcje
Działanie menu, formularzy i potrzebnych interakcji
Kto wdrożył funkcje i kto utrzymuje je obecnie?
Potwierdzone, częściowo sprawdzone albo brak dostępu
Wydajność
Pomocnicze wyniki dla konkretnej strony
Czy dostępne są dane terenowe i jakie były warunki pomiaru?
Sygnał pomocniczy albo brak danych
Dostępność
Widoczne rozwiązania i ewentualny opis wymagań
Jakie kryteria WCAG sprawdzono i w jaki sposób?
Potwierdzony zakres, deklaracja albo brak danych
Opis projektu
Cel, problem, decyzje i zakres prac
Czy case study wskazuje ograniczenia i podział odpowiedzialności?
Opis szczegółowy, ogólny albo niedostępny
Nie należy mechanicznie sumować ocen, jeśli projekt ma wymaganie krytyczne, takie jak konkretna integracja lub dostępność. Brak właściwego doświadczenia w takim obszarze może mieć większe znaczenie niż kilka mocnych sygnałów dotyczących estetyki.
Macierz jest praktycznym narzędziem selekcji, a nie zwalidowaną skalą. Pomaga zdecydować, kogo zaprosić do rozmowy i jakie luki wyjaśnić. Nie odpowiada natomiast na wszystkie pytania o komunikację, terminowość, koszty, bezpieczeństwo, utrzymanie ani rezultaty biznesowe. Te elementy wymagają osobnej weryfikacji oferty, procesu współpracy i warunków umowy.
Najczęstsze pytania
Czy brak realizacji z mojej branży wyklucza wykonawcę?
Nie zawsze. Istotne może być podobieństwo celu, funkcji, odbiorców i skali projektu. W przedsięwzięciach o szczególnych wymaganiach doświadczenie branżowe może jednak mieć większe znaczenie. Samo dopasowanie nie gwarantuje powodzenia nowej realizacji.
Czy wysoki wynik w PageSpeed Insights oznacza, że wykonawca jest dobry?
Nie. Wynik dotyczy konkretnej strony i warunków pomiaru. Jest pomocniczym sygnałem, a nie pełną oceną wykonawcy, użyteczności lub całego projektu.
Czy automatyczny test wystarczy do oceny dostępności strony?
Nie. Automatyczne narzędzia nie oceniają wszystkich kryteriów WCAG i nie potwierdzają samodzielnie pełnej zgodności. Mogą jedynie wesprzeć wstępną diagnozę.
