Przez 8 lat tworzenia stron internetowych widziałem setki briefingów. Niektóre były doskonałe – konkretne, szczegółowe, z jasnymi celami. Inne… cóż, przypominały bardziej listę życzeń do Świętego Mikołaja niż profesjonalny dokument projektowy. Oto pięć najczęstszych błędów, które kosztują czas, pieniądze i nerwy obu stron.
1. „Chcemy stronę jak Apple, ale tańszą”
Problem: Klienci często przychodzą z referencjami do wielomilionowych projektów korporacji, nie zdając sobie sprawy z różnicy w budżecie i zasobach.
Dlaczego to szkodzi: Apple wydaje miliony dolarów na design, UX research, testing i development. Porównywanie małego projektu do takiego giganta jest jak oczekiwanie, że warsztat samochodowy zbuduje Formułę 1 za cenę Fiata 126p.
Lepsze podejście: Zamiast „jak Apple” napisz konkretnie co Ci się podoba – czy to minimalizm, typografia, sposób prezentacji produktów? Dostarcz screenshoty konkretnych elementów z opisem dlaczego Ci się podobają.
Przykład z praktyki: Klient przyszedł z referencją do strony Tesla. Po rozmowie okazało się, że chodziło mu o duże zdjęcia produktów i minimalistyczny design. Zamiast kopiować cały koncept Tesla, stworzyliśmy własne rozwiązanie w jego budżecie, które zachowało te elementy które mu się podobały.
2. Brak konkretnych celów biznesowych
Problem: „Chcemy modernę stronę” to nie jest cel biznesowy. To jak powiedzenie „chcę jechać szybko” nie określając dokąd.
Dlaczego to szkodzi: Bez jasnych celów nie da się zmierzyć sukcesu projektu. Developer nie wie na czym się skupić, a klient nie wie czy dostał to czego potrzebował.
Co powinno być w briefingu:
- Konkretne cele: zwiększenie konwersji o 30%, pozyskanie 50 leadów miesięcznie
- Grupa docelowa: „właściciele małych firm, 35-50 lat, szukający usług IT”
- Kluczowe akcje użytkownika: wypełnienie formułaru, pobranie katalogu, zamówienie callback
Lepsze podejście: Zacznij od pytania „co ma się stać po uruchomieniu strony?”. Jeśli nie potrafisz odpowiedzieć konkretnie, to prawdopodobnie nie potrzebujesz jeszcze strony, tylko strategii biznesowej.
3. „Treści dostarczymy później”
Problem: To klasyk gatunku. Klient zamawia stronę, ale treści „przygotuje później”, bo „to przecież tylko teksty”.
Dlaczego to paraliżuje projekt:
- Design bez treści to design w próżni
- Nie wiadomo ile sekcji będzie potrzebnych
- Struktura nawigacji może się całkowicie zmienić
- Optymalizacja SEO staje się niemożliwa
Rzeczywiste konsekwencje: Projekt wydłuża się o 2-3 miesiące, bo gotowy design trzeba przerabiać pod rzeczywiste treści. Zamiast planowanych 6 tygodni, projekt trwa 4 miesiące.
Rozwiązanie: Przed rozpoczęciem prac technicznych musisz mieć:
- Wszystkie teksty (przynajmniej w 90%)
- Zdjęcia lub jasny plan sesji
- Listę wszystkich podstron
- Schematy formularzy
4. Decydowanie komitetowo bez wyznaczenia decision makera
Problem: „Musi to zaakceptować cała rada/zespół/rodzina” brzmi demokratycznie, ale w praktyce oznacza paraliteż decyzyjną.
Typowy scenariusz:
- Tydzień 1: „Świetny projekt, tylko żona chce zmienić kolory”
- Tydzień 2: „Partner uważa, że menu powinno być po lewej”
- Tydzień 3: „Teść powiedział, że jego kumpel zrobił by to inaczej”
- Tydzień 4: „Wracamy do pierwszej wersji”
Dlaczego to zabija projekt: Każda iteracja kosztuje czas i pieniądze. Brak jasnej hierarchii decyzyjnej oznacza nieskończone poprawki i frustrację wszystkich stron.
Rozwiązanie: Wyznacz jedną osobę odpowiedzialną za finalne decyzje. Inne osoby mogą dawać feedback, ale to decision maker ma ostatnie słowo. Ustal to na początku i zapisz w umowie.
5. Niejasny budżet i harmonogram
Problem: „Budżet elastyczny, terminy orientacyjne” to recepta na katastrofę.
Częste wymówki:
- „Nie wiemy ile to może kosztować”
- „Zależy nam na jakości, nie na czasie”
- „Budżet uzgodnimy jak zobaczymy projekt”
Dlaczego to nie działa:
- Developer nie wie jakie rozwiązania proponować
- Brak ram czasowych prowadzi do scope creep
- Projekt może kosztować 5x więcej niż pierwotnie planowano
Lepsze podejście:
- Ustal konkretny budżet: „mamy 15,000 zł na cały projekt”
- Określ sztywne terminy: „uruchomienie musi nastąpić do 15 marca”
- Zdefiniuj co jest w cenie podstawowej, a co jako dodatki
Przykład dobrego briefingu finansowego: „Budżet: 20,000 zł na stronę podstawową + 3,000 zł buffer na ewentualne zmiany. Termin: uruchomienie do końca lutego. Priorytet: jakość wykonania nad dodawaniem funkcji.”
Jak przygotować dobry briefing – checklist
Przed spotkaniem przygotuj:
Cele biznesowe – konkretne, mierzalne Budżet – realny i zweryfikowany Terminy – sprawdzone z kalendarzem wydarzeń biznesowych Referencje – z opisem co konkretnie Ci się podoba Treści – przynajmniej szkice i strukturę Decision maker – osoba z prawem ostatecznej decyzji Konkurencja – analiza 3-5 podobnych firm Grupa docelowa.
Podczas briefingu:
- Zadawaj pytania „dlaczego?” zamiast akceptować powierzchowne odpowiedzi
- Zapisuj wszystko – pamięć zawodzi
- Ustal jasne kryteria akceptacji każdego etapu
- Określ proces komunikacji i częstotliwość spotkań
Dobry briefing to fundament udanego projektu. Jego przygotowanie zajmuje czas, ale ten czas zwraca się z nawiązką podczas realizacji. Pamiętaj – developer to nie jasnowidz, a projekt strony to nie zagadka do odgadnięcia.
Im więcej informacji dostarczysz na początku, tym lepszy będzie efekt końcowy i tym mniej niespodzianek pojawi się po drodze. Inwestycja w solidny briefing to inwestycja w sukces całego projektu.
