Discovery przed projektem strony: zakres, deliverables i o ile realnie skraca to wdrożenie.

„Discovery” to krótka faza rozpoznawcza przed startem prac projektowych i programistycznych. Celem jest zminimalizowanie ryzyka: doprecyzować cele biznesowe, wymagania, zakres funkcji, strukturę treści, kryteria akceptacji i plan migracji. Dzięki temu zespół nie „rysuje na czuja”, a po wdrożeniu jest mniej poprawek i poślizgów. W praktyce w małych i średnich firmach discovery trwa od kilku dni do 2–3 tygodni i jest tańsze niż późniejsze zmiany „po fakcie”.

Po co to robić, jeśli „wiemy, czego chcemy”

Wiele zespołów ma ogólny obraz („nowoczesna strona, szybka, ładna”), ale diabeł tkwi w szczegółach: jakie dokładnie cele mierzymy, kto przygotowuje treści, jak wygląda proces ofertowania, co z integracjami (CRM, płatności), jakie są ograniczenia prawne i dostępności. Discovery zbiera to w jednym miejscu, ustala priorytety i zamienia życzenia w decyzje. Efekt to spójny plan, który daje przewidywalny budżet i harmonogram.

Co przynosi discovery (namacalne korzyści)

Po pierwsze—krótszy czas wdrożenia: gdy decyzje zapadają wcześniej, unikamy cofania się o całe sprinty. Po drugie—mniej poprawek: kryteria akceptacji i makiety zmniejszają ryzyko „to nie tak miało wyglądać”. Po trzecie—realny zakres: priorytetyzujemy „must have” vs. „nice to have”, więc nie rozdmuchujemy budżetu. Po czwarte—jasne role: wiemy, kto pisze teksty, kto zatwierdza, kto odpowiada za integracje i testy.

Zakres discovery w MŚP: co minimum, co opcjonalne

Minimum to: cele i metryki (np. zapytania, CVR, czas do pierwszego kontaktu), persony i scenariusze użytkowników, mapa informacji (co i gdzie na stronie), szkic architektury (menu, kluczowe podstrony), makiety low-fi dla kluczowych ekranów, lista funkcji z priorytetami, decyzje o treściach (kto tworzy, ile znaków, jakie media), plan migracji starej strony, wstępny plan testów i kryteria akceptacji. Opcjonalnie: przegląd analityki i SEO, audyt wydajności obecnej strony, proof-of-concept integracji.

Jak wygląda proces krok po kroku

Startujemy krótkim warsztatem (1–2 spotkania po 90 minut), w którym biorą udział właściciel biznesowy, przedstawiciel sprzedaży/obsługi, osoba od treści i osoba techniczna. Na bazie warsztatów zespół projektowy przygotowuje makiety low-fi kluczowych widoków (np. strona główna, usługa/produkt, oferta/koszyk, kontakt). Równolegle powstaje mapa treści (co trzeba napisać/zgromadzić) i lista wymagań funkcjonalnych. Na finał robimy przegląd, nanosimy poprawki i zamykamy „Definition of Ready”—czyli warunki, po których można ruszyć z projektem graficznym i developmentem.

Najważniejsze deliverables (co dostajesz na koniec)

• One-pager celów i metryk: po co robimy stronę, co uznajemy za sukces i jak to zmierzymy.
• Mapa informacji i architektura: drzewo nawigacji, priorytety sekcji, wytyczne dla SEO i dostępności.
• Makiety low-fi kluczowych podstron: układ treści i funkcji bez „ładnych obrazków”.
• Backlog funkcji z priorytetami: „must/should/could” wraz z kryteriami akceptacji.
• Plan treści: lista materiałów do stworzenia/migracji, odpowiedzialni i terminy.
• Plan testów i przeglądów: kto, kiedy i co sprawdza (w tym dostępność i wydajność).

O ile realnie discovery skraca wdrożenie

W małych projektach, gdzie wcześniej „szliśmy od razu w makiety hi-fi”, discovery potrafi ściąć 20–30% czasu całego projektu, bo decyzje zapadają szybciej, a odrzucone pomysły nie pochłaniają sprintów. W średnich wdrożeniach z integracjami oszczędności bywają większe: unikamy kosztownych przeróbek na etapie developmentu i testów UAT. Klucz to dyscyplina: discovery nie może się ciągnąć—ma zamykać otwarte pytania, a nie otwierać nowe bez końca.

Makieta low-fi kontra projekt graficzny

Makieta low-fi to szkic układu: co po czym następuje, jakie bloki treści i przyciski są potrzebne, gdzie idą elementy zaufania (dowody, referencje, FAQ). Nie oceniamy jeszcze stylistyki. Dzięki temu autor treści wie, co napisać, projektant wie, co rozmieścić, a programista wie, co będzie klikalne. Gdy makiety są zatwierdzone, projekt graficzny idzie szybciej i bez „niespodzianek”.

Treści: największe ryzyko projektu

Strony często opóźniają się przez teksty i materiały. Discovery powinno zliczyć wszystko: które podstrony wymagają nowych treści, które migrujemy, jakie zdjęcia/wideo są potrzebne, kto je dostarcza i do kiedy. Ustal też minimalne wymagania jakości: długość akapitów, ton, listy kontrolne SEO (nagłówki, meta, alt). Jasne zasady oszczędzają dziesiątki maili „a jak to opisać”.

Wydajność i Core Web Vitals: decyzje na starcie

O szybkości strony decydujemy już w discovery: polityka obrazów (formaty, kompresja, lazy loading), wybór czcionek (ile odmian), komponenty interaktywne (czy są potrzebne), zasady osadzania skryptów (np. mapy, wideo). Jeśli od razu ustalimy limity i sposób ładowania, łatwiej utrzymać dobre wskaźniki LCP/INP/CLS bez „odchudzania” projektu w ostatniej chwili.

Dostępność (WCAG) bez wielkiej rewolucji

W discovery warto przyjąć kilka prostych zasad: kontrasty zgodne z wytycznymi, logiczna kolejność nagłówków, etykiety dla formularzy, klikalne obszary o odpowiedniej wielkości, focus widoczny z klawiatury, tekst alternatywny dla obrazów informacyjnych. To „tanio” zaplanowane elementy, które później bardzo trudno się nadrabia.

Role i odpowiedzialności

Potrzebny jest właściciel biznesowy (decyzje, priorytety), osoba od treści (koordynacja copy i materiałów), projektant (makiety) i osoba techniczna (sprawdza wykonalność, integracje). Jeśli to zewnętrzna agencja—po stronie klienta przyda się „sponsor” z mandatem do decyzji. Brak decydenta wydłuża wszystko najbardziej.

Jak unikać „scope creep”

Na koniec discovery zamykamy zakres: spis funkcji i ekranów z priorytetami oraz kryteriami akceptacji. Każda nowa potrzeba trafia do „parkingu” i jest oceniana później (np. faza 2). To pozwala wystartować, zamiast w nieskończoność dopieszczać listę życzeń.

Model wyceny discovery w małej firmie

Są dwa proste podejścia: stała wycena za pakiet deliverables (np. warsztaty, 5 makiet, mapa treści, backlog) albo rozliczenie za dzień pracy z limitem (np. 3–5 dni). W obu przypadkach deklarujemy, co dokładnie oddajemy i kiedy. To buduje zaufanie i porządkuje współpracę już na starcie.

Jak mierzyć jakość discovery

Po wdrożeniu sprawdź: ile zmian funkcjonalnych wpadło po zatwierdzeniu makiet, czy harmonogram utrzymał się w 80–90%, ile błędów dotyczyło „niedomówień” w treści i architekturze, czy wskaźniki wydajności i dostępności mieszczą się w ustalonych widełkach. Jeśli tak—discovery dowiozło wartość.

Plan na 10 dni roboczych (przykład)

Dzień 1: warsztat celów, metryk i ryzyk. Dzień 2: persony i scenariusze; lista treści do stworzenia/migracji. Dzień 3–4: makiety low-fi kluczowych widoków. Dzień 5: przegląd i poprawki. Dzień 6: backlog funkcji z priorytetami i kryteriami akceptacji. Dzień 7: decyzje o wydajności, dostępności i integracjach. Dzień 8: plan treści (odpowiedzialni, terminy). Dzień 9: plan testów (w tym wstępne kroki UAT). Dzień 10: podpisanie „Definition of Ready” i start projektu graficznego.

Typowe błędy i jak ich uniknąć

• Brak decydenta po stronie klienta—spotkania bez konkluzji.
• Makiety hi-fi zamiast low-fi—dyskusja o kolorach zamiast o treści i funkcji.
• Niedoszacowanie treści—„zrobimy później”, a potem projekt stoi.
• Brak kryteriów akceptacji—ciągłe „jeszcze jedno drobiazg”.
• Pominięcie dostępności i wydajności—później drogie poprawki.

Podsumowanie

Discovery to szybka, konkretna inwestycja w porządek: cele, zakres, makiety i plan treści. W zamian dostajesz krótsze wdrożenie, mniej poprawek i przewidywalny budżet. W realiach MŚP wystarczy tydzień–dwa i mały zespół decyzyjny, by przygotować projekt do sprawnego startu. Lepiej zdecydować na papierze, niż przerabiać gotowy kod.

Źródła

https://www.nngroup.com/articles/ux-discovery-kickoff/ — Nielsen Norman Group: dobre praktyki fazy discovery i warsztatów startowych

https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works — GOV.UK Service Manual: jak przebiega faza discovery w projektach usług i serwisów

https://developers.google.com/search/docs/fundamentals/creating-helpful-content — Google Search Central: tworzenie użytecznych treści i struktury informacji

https://www.w3.org/WAI/standards-guidelines/wcag/ — W3C WAI: wytyczne dostępności WCAG i materiały wdrożeniowe