Istnieje działająca strona produkcyjna z katalogiem produktów, kartami modeli i stronami informacyjnymi.
Stos technologiczny frontend:
— Next.js;
— React;
— TypeScript;
— istniejący system komponentów;
— środowiska staging i produkcyjne.
Jest zatwierdzony kierunek wizualny i projekt nowej strony głównej. Należy go wdrożyć w istniejącym projekcie, dostosować do desktop/tablet/mobile i doprowadzić wszystkie główne typy stron do jednolitej, zaktualizowanej stylistyki.
Pełny redesign produktu i zmiana logiki biznesowej nie są wymagane.
OBOWIĄZKOWY ZAKRES
1. Nowa strona główna
— zrealizować stronę główną według dostarczonego projektu;
— zachować istniejącą funkcjonalność, linki i routingu;
— poprawnie podłączyć zatwierdzone sekcje i CTA;
— wykorzystać istniejące dane i API;
— przewidzieć poprawne wyświetlanie dynamicznej treści.
Główne typy sekcji:
— nagłówek/nawigacja;
— hero;
— bloki informacyjne;
— karty modeli/ofert;
— bloki analityczne lub market insight;
— sekcje CTA;
— stopka.
Dokładny skład sekcji zostanie dostarczony wybranemu wykonawcy wraz z makietą.
2. Responsywność
Należy zrealizować:
— desktop;
— tablet;
— mobile;
— pośrednie rozdzielczości;
— poprawne zachowanie siatek, kart, menu, przycisków i typografii;
— brak poziomego scrolla i konfliktów wizualnych.
3. Typografia i ogólne style
— wdrożyć nowe zatwierdzone czcionki;
— doprowadzić rozmiary, wagi, line-height i odstępy do jednolitego systemu;
— zaktualizować style przycisków, kart, pól, badge'ów i nagłówków;
— w miarę możliwości wykorzystać wspólne design tokens lub zmienne CSS;
— nie dublować stylów osobno dla każdej strony bez potrzeby.
4. Ujednolicenie istniejących stron
Sprawdzić i doprowadzić do nowej stylistyki główne typy stron:
— katalog;
— karta modelu / PDP;
— strony informacyjne;
— nagłówek;
— stopka;
— formularze;
— okna modalne;
— istniejące CTA;
— stany loading / empty / error, jeśli już występują w projekcie.
Chodzi o wizualne ujednolicenie istniejących komponentów, a nie o pełny indywidualny redesign każdej strony.
5. Katalog
Sprawdzić:
— siatkę kart;
— obrazy;
— nazwę, referencję i cenę;
— filtry i sortowania;
— przyciski i linki;
— wyświetlanie desktop/mobile;
— stany loading i empty;
— brak wizualnych przesunięć podczas ładowania.
6. PDP
Sprawdzić:
— galerię;
— główny blok informacyjny;
— cenę i CTA;
— sekcje analityczne;
— tabele i metryki;
— About Watch;
— układ desktop/mobile;
— długie nazwy, referencje i brakujące dane.
Należy zachować obecną funkcjonalność i istniejące kontrakty API.
7. Nagłówek i Stopka
— jednolita stylistyka na wszystkich stronach;
— responsywna nawigacja;
— mobilne menu;
— poprawne stany active/hover/focus;
— brak rozbieżności między stroną główną, katalogiem i PDP.
8. Stany interfejsu
Dla dynamicznych bloków sprawdzić:
— loading;
— puste dane;
— błąd API;
— niewystarczające dane;
— brakujący obraz;
— brakująca cena;
— długi tekst;
— mobilne wyświetlenie.
Nie jest wymagane opracowywanie nowej skomplikowanej logiki biznesowej. Należy poprawnie wizualizować już istniejące stany.
9. Jakość i wydajność
— nie pogorszyć SEO i bieżącej indeksacji;
— zachować poprawne metadane i semantyczne HTML;
— nie tworzyć krytycznych przesunięć układu;
— optymalizować obrazy i czcionki;
— uwzględnić reduced motion dla animacji;
— sprawdzić podstawową dostępność: stany focus, kontrast, nawigacja klawiaturą;
— nie podłączać ciężkich bibliotek bez uzasadnionej potrzeby.
10. Staging i QA
— wdrożyć zmiany na staging;
— sprawdzić główne typy stron;
— sprawdzić desktop, tablet i mobile;
— usunąć wizualne i responsywne błędy;
— po akceptacji wykonać wdrożenie produkcyjne;
— zapewnić poprawę błędów w zrealizowanym zakresie nie mniej niż 7 dni kalendarzowych po publikacji.
WYNIK PRACY
— Pull Request z kodem frontendowym;
— zrealizowana nowa strona główna;
— responsywne desktop/tablet/mobile;
— jednolite czcionki, karty i podstawowe komponenty UI;
— wizualnie zatwierdzone katalog, PDP i strony informacyjne;
— wdrożenie staging;
— poprawa znalezionych błędów wizualnych;
— wdrożenie produkcyjne;
— krótki opis zmienionych komponentów;
— 7-dniowy okres naprawy błędów po akceptacji.
KRYTERIA AKCEPTACJI
1. Strona główna odpowiada dostarczonemu projektowi.
2. Wszystkie sekcje poprawnie działają na desktop, tablet i mobile.
3. Nagłówek i stopka są jednolite na wszystkich stronach.
4. Katalog i PDP wizualnie odpowiadają nowemu systemowi.
5. Obecna funkcjonalność strony nie jest naruszona.
6. Kontrakty API i logika backendowa nie zostały zmienione bez uzgodnienia.
7. Brak poziomego scrolla i krytycznych przesunięć układu.
8. Czcionki i obrazy ładują się poprawnie.
9. Stany loading, empty i error są wyświetlane bez uszkodzenia układu.
10. Zmiany zostały sprawdzone na staging i wdrożone w produkcji.
11. Poprawiono błędy wizualne wykryte podczas akceptacji w ramach uzgodnionego zakresu.
CO NIE JEST WYMAGANE
— opracowanie backendu;
— zmiana logiki biznesowej;
— stworzenie nowego katalogu lub CMS;
— opracowanie nowego API;
— pełny redesign każdej strony informacyjnej;
— nowe funkcje użytkownika, które nie są zawarte w makietach;
— opracowanie skomplikowanego systemu designu od podstaw;
— stworzenie nowego projektu zamiast dopracowania istniejącego;
— zmiana struktury SEO bez osobnego uzgodnienia.
WYMAGANIA WOBEC WYKONAWCY
— pewna znajomość Next.js / React / TypeScript;
— doświadczenie w pracy z istniejącymi projektami produkcyjnymi;
— jakościowe responsywne cięcie;
— doświadczenie w wdrażaniu projektów z Figma;
— podejście komponentowe;
— pewna praca z CSS / CSS Modules / Tailwind lub istniejącym systemem projektu;
— zrozumienie Core Web Vitals;
— Git / Pull Request workflow;
— umiejętność pracy przez staging.
W ODPOWIEDZI NALEŻY KONIECZNIE PODAĆ
1. Stała cena za pełny obowiązkowy zakres.
2. Czas realizacji w dniach roboczych.
3. Ocena w godzinach.
4. Kiedy można zacząć.
5. Linki do 2–3 odpowiednich projektów na Next.js/React.
6. Czy jest doświadczenie w pracy z katalogami, kartami produktów lub interfejsami analitycznymi.
7. Co będzie potrzebne do dokładnej oceny przed rozpoczęciem pracy.
8. Czy w cenę wchodzą:
— staging;
— responsywne QA;
— wdrożenie produkcyjne;
— poprawa błędów;
— 7-dniowy okres naprawy błędów.
Szablonowe odpowiedzi bez przeglądania wymagań i bez konkretnej oceny nie będą rozpatrywane.
Dostęp do produkcji na pierwszym etapie nie jest udostępniany. Praca rozpoczyna się po ograniczonym przeglądzie kodu i wdrażana jest przez staging.
