Brief na stronę internetową ma sprawić, że firma i wykonawcy rozmawiają o tym samym rezultacie. Nie musi zawierać gotowej technologii ani projektu ekranów. Powinien wyjaśnić cel, odbiorców, zakres treści, funkcje, materiały, ograniczenia i odpowiedzialności na tyle dokładnie, aby porównać propozycje bez zgadywania.
- Dlaczego projekt powstaje i po czym poznacie, że jest użyteczny.
- Kto korzysta ze strony i jakie zadania wykonuje.
- Jakie treści, podstrony, funkcje i integracje są potrzebne.
- Co już istnieje: domena, dane, materiały, systemy i wyniki.
- Kto dostarcza, zatwierdza, publikuje i utrzymuje każdy element.
- Jakie są ramy budżetu, terminu, odbioru i dalszej opieki.
Opisz problem firmy i zachowanie użytkownika, nie „nowoczesny wygląd”
Dobry brief zaczyna się od powodu projektu. Strona może nie zdobywać właściwych zapytań, źle przedstawiać obecną ofertę, wymagać pomocy przy każdej aktualizacji albo nie obsługiwać nowego procesu. Opisz stan dziś oraz zmianę, którą projekt ma wprowadzić. „Chcemy nowoczesnej strony” jest oczekiwaniem estetycznym, nie celem biznesowym.
Zapisz najważniejsze działanie o wartości: wysłanie zapytania o określoną usługę, zakup, rezerwacja, pobranie dokumentacji, zapis na wydarzenie lub samodzielne znalezienie odpowiedzi. Dodaj działania wspierające, ale nie próbuj nadać najwyższego priorytetu wszystkim. Hierarchia pomaga ocenić stronę główną, menu i pomiar.
| Słaby zapis | Lepszy zapis | Co można zaprojektować |
|---|---|---|
| Nowoczesna strona | Wyjaśnić nową ofertę i zdobywać zapytania B2B | Architekturę oferty, dowody i kontakt |
| Więcej ruchu | Rozwijać widoczność poradników powiązanych z usługami | Huby, content plan i linkowanie |
| Łatwy kontakt | Kierować trzy typy spraw do właściwych osób | Formularz, routing i potwierdzenia |
| Lepszy sklep | Ułatwić dobór wariantu i ograniczyć zwroty | Filtry, dane produktu i pomoc |
Odbiorców opisuj przez sytuację, wiedzę i obawy. Nie potrzebujesz fikcyjnych imion. Wystarczy: kierownik utrzymania ruchu szukający zamiennika pompy, rodzic porównujący placówki albo właściciel mieszkania zgłaszający awarię. Dodaj pytania z rozmów i dane, których potrzebują przed decyzją.
Ustal miernik i punkt startowy. Dla formularza może to być liczba wartościowych zgłoszeń, ale potrzebna jest definicja wartościowego kontaktu. Dla obsługi — liczba spraw rozwiązanych bez telefonu. Dla sklepu — dokończone zakupy i błędy wyboru wariantu. Nie obiecuj wzrostu bez danych, budżetu i testu.
Rozpisz strony, odpowiedzialność treści i elementy poza zakresem
Lista „strona główna, o nas, oferta, kontakt” nie wystarcza do wyceny. W sekcji oferta może kryć się pięć lub pięćdziesiąt podstron. Utwórz proste drzewo z typami stron i przybliżoną liczbą elementów. Dla sklepu podaj kategorie, produkty, warianty i filtry. Dla portalu — huby, kategorie i typy artykułów.
Każdy typ strony powinien mieć odpowiedzialność. Strona usługi wyjaśnia zakres i prowadzi do zapytania. Karta produktu prezentuje dane oraz zakup. Case study pokazuje wykonanie. Kontakt pomaga wybrać kanał. Jeśli dwa URL-e mają odpowiadać na to samo pytanie, ryzyko duplikacji pojawia się już w briefie.
Obecne URL-e, treści, pliki, funkcje i wyniki.
Typy stron, hierarchia i odpowiedzialność.
Źródła, autorzy, redakcja i akceptacja.
Zadanie, dane wejściowe i oczekiwany rezultat.
Co nie wchodzi do pierwszej wersji projektu.
Dodaj listę elementów poza zakresem. Może obejmować sklep, drugą wersję językową, migrację archiwum, sesję zdjęciową, copywriting, integrację CRM albo stałą opiekę. Brak tej listy sprawia, że strony rozumieją słowo „kompletna” inaczej. Element można zaplanować na kolejny etap, ale trzeba przygotować architekturę, jeśli rozwój jest realny.
Przykładowa oferta producenta opakowań foliowych pokazuje, dlaczego brief B2B musi zebrać rodziny produktów, materiały, wymiary, warianty wykonania, usługi i zastosowania. Jedna pozycja „oferta” w spisie podstron nie oddaje pracy potrzebnej do uporządkowania takich danych.
Jeżeli nie masz mapy, zacznij od procesu opisanego w poradniku o strukturze strony internetowej. Nie narzucaj wykonawcy gotowego menu, jeśli nie znasz zależności. Przekaż dane, pytania klientów i priorytety, a następnie oczekuj uzasadnionej architektury.
Opisuj funkcję przez zadanie, dane i rezultat
„Potrzebujemy formularza” nie mówi, jakie sprawy obsługuje, jakie pola zbiera, dokąd trafia wiadomość i co widzi użytkownik po wysłaniu. Dobra specyfikacja funkcji opisuje aktora, sytuację, dane wejściowe, reguły, wynik, błędy i osoby odpowiedzialne po stronie firmy. Zakres wdrożeniowy można doprecyzować z pomocą poradnika o formularzu kontaktowym WordPress.
| Funkcja | Co opisać | Pytanie odbiorowe |
|---|---|---|
| Formularz | Sprawy, pola, odbiorca, CRM i potwierdzenie | Czy zgłoszenie dotarło i ma właściciela? |
| Rezerwacja | Zasoby, terminy, płatność, anulacja i status | Czy termin jest jednoznacznie potwierdzony? |
| Wyszukiwarka | Zakres, filtry, sortowanie i brak wyników | Czy znajduje właściwy element po języku użytkownika? |
| Strefa klienta | Role, logowanie, dane, uprawnienia i odzyskanie | Czy użytkownik widzi wyłącznie swoje zasoby? |
| Newsletter | Zgoda, double opt-in, segmenty i wypisanie | Czy cały cykl działa zgodnie z deklaracją? |
Wymień integracje wraz z właścicielem konta, dokumentacją i środowiskiem testowym. CRM, płatności, system magazynowy, rezerwacje, newsletter, mapy i analityka mogą wymagać dostępu oraz pracy po stronie dostawcy. Nie wpisuj hasła ani klucza do briefu. Ustal bezpieczny sposób przekazania dopiero wykonawcy.
Określ urządzenia i warunki użycia. „Responsywna” jest wymaganiem bazowym, ale formularz terenowy może działać na słabym łączu i w rękawicach, a panel B2B głównie na desktopie. Mobile nie jest pomniejszonym widokiem; priorytety, kolejność i interakcje wymagają osobnej kontroli.
Dodaj wymagania dostępności: klawiatura, focus, etykiety, kontrast, powiększenie, teksty alternatywne, napisy i komunikaty błędów. Jeśli projekt podlega konkretnemu standardowi lub przepisom, podaj zakres i osobę odpowiedzialną za formalny odbiór. Nie traktuj automatycznego skanera jako pełnego audytu.
Zinwentaryzuj treści, design i właścicieli decyzji
Wypisz, co już istnieje: logo w formacie wektorowym, księga marki, kolory, fonty, zdjęcia, filmy, opisy, cenniki, dokumentacja, regulaminy i tłumaczenia. Przy każdym elemencie zaznacz właściciela, aktualność, prawa do użycia i potrzebę poprawy. Plik znaleziony na dysku nie jest automatycznie materiałem gotowym do publikacji.
Jeżeli treści dopiero powstaną, określ odpowiedzialność. Kto prowadzi research, przeprowadza wywiady, pisze, sprawdza merytorycznie i zatwierdza? W jakim formacie trafiają do projektu i do kiedy? Opóźnienie tekstów oraz zdjęć często blokuje projekt bardziej niż implementacja, dlatego harmonogram musi je obejmować.
- Identyfikacja: logo, warianty, fonty, kolory i zasady użycia.
- Copy: oferta, pytania klientów, dane firmy i ton komunikacji.
- Media: zdjęcia, wideo, zgody, opisy i pliki źródłowe.
- Dowody: realizacje, opinie, certyfikaty i aktualny zakres.
- Dokumenty: regulaminy, polityki, instrukcje i wersje językowe.
- Właściciele: osoba zatwierdzająca każdy rodzaj informacji.
Inspiracje wizualne dodawaj z komentarzem. „Podoba mi się ta strona” jest zbyt nieprecyzyjne. Napisz, czy chodzi o typografię, rytm, sposób prezentacji produktu, nawigację czy fotografię. Wskaż również przykłady niepożądane i powód. Inspiracja nie jest zgodą na kopiowanie projektu.
Zatwierdzony design system lub makieta stają się źródłem prawdy dla implementacji. Brief opisuje kontekst i wymagania, ale nie zastępuje kompletnego projektu. Jeśli brakuje stanu formularza, menu mobile albo karty produktu, trzeba go zaprojektować i zatwierdzić, a nie improwizować podczas kodowania.
Zabezpiecz wartość obecnej strony i zaplanuj utrzymanie
Przy przebudowie dołącz inwentaryzację obecnych URL-i, ruchu, konwersji, linków, treści, formularzy i plików. Oznacz, co zostaje, co się zmienia i co może zostać usunięte. Decyzja o skasowaniu strony nie powinna wynikać wyłącznie z wyglądu albo małego ruchu bez zbadania jej roli.
Mapa migracji przypisuje każdy stary adres do zachowanego URL-a, właściwego nowego celu albo uzasadnionego statusu usunięcia. Nie przekierowuj wszystkiego na stronę główną. Zmiana systemu nie wymaga zmiany każdego adresu. Procedurę techniczną opisuje poradnik o przekierowaniach 301.
WordPress, SaaS, sklep platformowy lub rozwiązanie dedykowane są środkami. Najpierw opisz treści, role, funkcje, integracje i utrzymanie. Wykonawca powinien uzasadnić wybór w odniesieniu do tych danych.
W briefie zapisz wymagania SEO: research, architektura, migracja, title i description, canonicale, mapa XML, robots, dane strukturalne, indeksacja i pomiar. Nie ograniczaj ich do instalacji wtyczki. Ustal również, kto ma dostęp do Google Search Console i analityki oraz kto weryfikuje dane po starcie.
Opieka po publikacji obejmuje aktualizacje, kopie, monitoring, formularze, poprawki i rozwój treści. Określ, co wchodzi w gwarancję wykonania, a co w stałą usługę. Zapisz właścicieli domeny, hostingu, DNS, poczty, licencji i kont zewnętrznych. Firma powinna móc odzyskać dostęp bez wyłącznej zależności od jednej osoby.
Podaj ramy, żeby porównywać ten sam zakres
Budżet pomaga dobrać rozwiązanie i etapowanie. Nie musi być jedną sztywną kwotą; może być przedziałem i listą priorytetów. Ukrycie budżetu nie sprawia, że wykonawcy wycenią identycznie. Jeśli każdy zakłada inny zakres treści, integracji i testów, oferty pozostaną nieporównywalne.
Harmonogram powinien zawierać zależności: dostarczenie materiałów, projekt, akceptacje, wdrożenie, migrację, integracje, testy i publikację. Podaj wydarzenia o stałej dacie, np. kampanię lub sezon, ale nie wymuszaj terminu sprzecznego z zakresem. Zapytaj wykonawcę o ryzyka i elementy po stronie firmy.
| Obszar | Co porównać | Czego nie mylić |
|---|---|---|
| Zakres | Liczba typów stron, funkcje, treści i migracja | Liczba ekranów z kompletnością projektu |
| Proces | Research, projekt, akceptacje i testy | Liczba spotkań z jakością decyzji |
| Technologia | Uzasadnienie, licencje i możliwość rozwoju | Nazwa narzędzia z efektem biznesowym |
| Odbiór | Kryteria techniczne, wizualne i zadaniowe | Brak błędów z profesjonalnym designem |
| Utrzymanie | Aktualizacje, reakcja, kopie i właściciele | Hosting z opieką nad całą stroną |
Poproś o wycenę pozycjami i listę założeń. Jeżeli wykonawca zakłada, że klient dostarcza gotowe teksty, powinno to być jawne. Jeżeli cena obejmuje tylko stronę główną i jeden szablon podstrony, również. Dzięki temu można porównać koszt tej samej pracy, a nie trzy różne interpretacje hasła „strona firmowa”.
Zapisz kryteria odbioru. Techniczne obejmują statusy, formularze, integracje, responsywność, dostępność i wydajność. Wizualne wymagają porównania renderu z zatwierdzonym projektem na desktopie i mobile. Treściowe dotyczą kompletności, faktów, języka i metadanych. Nie uznawaj samego uruchomienia strony za pełny odbiór.
Na końcu wskaż sposób podejmowania decyzji i osoby zatwierdzające. Wielu sprzecznych akceptujących bez właściciela prowadzi do pętli poprawek. Dla istotnych zmian zapisuj decyzję, powód i wpływ na zakres. Sam brief może ewoluować, ale każda zmiana powinna być świadoma.
Gdy dokument jest gotowy, użyj go jako wejścia do procesu opisanego w poradniku jak stworzyć stronę internetową dla firmy. Przygotowanie nie zastępuje projektowania, lecz daje mu właściwe dane i ogranicza ryzyko, że wykonawca będzie zgadywał biznes, treść oraz priorytety.