„Chcemy tylko odświeżyć stronę.”
To może być całkiem rozsądne założenie.
Strona działa. Nie ma awarii. Formularz wysyła wiadomości. Podstrony otwierają się poprawnie. Firma nadal używa domeny w stopkach maili, ofertach i materiałach handlowych. Nie ma powodu burzyć czegoś tylko dlatego, że powstało kilka lat temu.
Problem zaczyna się później.
Trzeba dodać nową usługę, ale nie bardzo wiadomo, gdzie ją umieścić. Główna oferta firmy zmieniła się na tyle, że dotychczasowy układ strony głównej prowadzi klienta do rzeczy, które nie są już najważniejsze. Pojawiły się mocniejsze realizacje i dowody, ale obecna strona nie ma dla nich sensownego miejsca. Firma zaczęła pracować z większym klientem B2B, lecz formularz, język i struktura nadal odpowiadają prostszemu procesowi sprzedaży sprzed kilku lat.
Każda z tych rzeczy wygląda osobno jak poprawka.
Dopiero kiedy zaczyna się je wdrażać, wychodzi na jaw, że jedna zmiana pociąga następną. Nowa oferta wymaga przebudowy nawigacji. Zmiana nawigacji odsłania problem z architekturą podstron. Nowa architektura wymaga napisania treści od nowa. Nowe treści nie mieszczą się w starych szablonach. Stare szablony wynikają z technologii i modelu edycji, który miał obsługiwać zupełnie inną stronę.
Wtedy pytanie przestaje brzmieć:
„Co jeszcze poprawić?”
Zaczyna brzmieć:
„Czy nadal poprawiamy stronę, czy już tylko obchodzimy jej stare założenia?”
To jest właściwa granica między modernizacją a przebudową.
Strona może działać poprawnie i być już złą bazą
Najłatwiej zauważyć stronę wymagającą interwencji wtedy, gdy problem jest widoczny.
Układ rozpada się na telefonie. Formularz nie działa. Serwis jest bardzo wolny. Treści są nieaktualne. Technologia nie jest wspierana. Takie sytuacje wymagają działania, ale sama ich obecność jeszcze nie odpowiada na pytanie, czy trzeba przebudować całą stronę.
Awarię można naprawić.
Nieaktualny tekst można zmienić.
Słaby komponent można zastąpić.
Nawet stary wygląd można odświeżyć bez burzenia całego systemu, jeżeli to, co znajduje się pod nim, nadal odpowiada firmie.
Znacznie trudniejsza jest sytuacja, w której strona technicznie działa, ale została zbudowana dla decyzji, które przestały być aktualne.
Kiedyś firma mogła mieć trzy proste usługi. Dzisiaj jedna z nich stała się głównym kierunkiem, druga jest tylko uzupełnieniem, a trzecia została zastąpiona bardziej złożonym procesem. Kiedyś klient przychodził głównie z polecenia i potrzebował potwierdzenia numeru telefonu. Dzisiaj porównuje kilku wykonawców, oczekuje dowodów, chce zrozumieć sposób współpracy i dopiero wtedy decyduje się na kontakt.
Strona nadal może wyglądać poprawnie.
Tyle że opowiada o firmie według starej kolejności.
I właśnie dlatego jej wiek jest słabym kryterium decyzji o przebudowie.
Pięcioletnia strona może być dobrą bazą, jeżeli firma przez ten czas zmieniła się niewiele, a architektura była rozsądnie zaprojektowana.
Dwuletnia strona może wymagać przebudowy, jeżeli od początku została zbudowana wokół błędnego obrazu oferty, klienta albo procesu sprzedaży.
Nie przebudowuje się strony dlatego, że jest stara. Przebudowuje się ją wtedy, gdy stare stały się jej założenia.
Pierwsza poprawka testuje więcej niż wygląd
Załóżmy, że firma chce mocniej pokazać jedną usługę.
Jeżeli strona ma sensowną strukturę, taka zmiana powinna być stosunkowo lokalna. Można zmienić priorytet na stronie głównej, rozbudować odpowiednią podstronę, poprawić linkowanie i dopasować wezwanie do kontaktu.
System przyjmuje nową decyzję.
Nie trzeba udawać, że wszystko zostało zaprojektowane od nowa.
Ale może być inaczej.
Nowa usługa nie pasuje do starego menu. Żeby zrobić dla niej miejsce, trzeba zmienić nazwy innych pozycji. To odsłania fakt, że kilka podstron łączy w sobie różne tematy tylko dlatego, że kiedyś tak było wygodniej. Po ich rozdzieleniu okazuje się, że strona główna prowadzi do starego podziału oferty. Po zmianie strony głównej zaczynają nie pasować CTA. Po zmianie CTA wychodzi na jaw, że formularz zbiera informacje odpowiednie dla dawnego sposobu sprzedaży.
Jedna decyzja biznesowa przeszła przez pięć warstw strony.
To nie oznacza automatycznie, że serwis trzeba wyrzucić.
Ale jest ważnym sygnałem diagnostycznym.
W BLISK można to potraktować jako test naprawialności.
Nie pytamy w nim, ile błędów ma strona.
Pytamy, czy problem można naprawić bez zachowywania założenia, które ten problem stworzyło.
Jeżeli odpowiedź brzmi „tak”, poprawka ma sens.
Jeżeli za każdym razem trzeba dopisywać wyjątek, tworzyć alternatywną ścieżkę, powielać treść albo wciskać nowy element w strukturę zaprojektowaną dla innej firmy, koszt kolejnych zmian nie jest już głównym problemem.
Problemem staje się baza.
Lokalny problem pozostaje lokalny
Dobra poprawka kończy się mniej więcej tam, gdzie się zaczęła.
Jeżeli firma ma wartościową strukturę strony, ale zdjęcia i warstwa wizualna przestały odpowiadać pozycji marki, można zmienić design bez wymyślania biznesu od nowa.
Jeżeli komunikacja jest właściwa, lecz obecna technologia utrudnia utrzymanie albo rozwój, można przeprowadzić zmianę techniczną z zachowaniem dużej części architektury treści.
Jeżeli jedna konkretna podstrona nie odpowiada już ofercie, można ją przebudować bez naruszania całego serwisu.
To są zdrowe przypadki modernizacji.
Przebudowa staje się kandydatem dopiero wtedy, gdy zmiana przestaje być lokalna nie dlatego, że wykonawca chce powiększyć projekt, lecz dlatego, że ta sama nieaktualna decyzja jest zapisana w wielu miejscach jednocześnie.
Może być zapisana w menu, strukturze podstron, kolejności informacji, szablonach, języku, sposobie prezentowania dowodów i ścieżce kontaktu.
Naprawiając każdy z tych elementów osobno, można przez długi czas uzyskiwać coraz ładniejszą wersję tego samego ograniczenia.
To jest moment, w którym redesign zaczyna pełnić funkcję maskowania problemu zamiast jego rozwiązania.
Najbardziej ryzykowna jest nowa skóra na starej logice
Pełny redesign brzmi jak duża zmiana, dlatego łatwo zacząć od bezpieczniejszego wariantu: nowa typografia, świeższe kolory, większe zdjęcia, inne przyciski, współczesne animacje.
Efekt może wyglądać znacznie lepiej.
Ale jeżeli klient nadal przechodzi przez tę samą nieaktualną strukturę, firma kupiła nowy wygląd starego sposobu myślenia.
To szczególnie niebezpieczne, ponieważ wizualna poprawa potrafi na jakiś czas zamknąć temat.
Strona wygląda nowocześnie, więc trudniej zauważyć, że oferta nadal jest poukładana według dawnego modelu. Że najważniejsze dowody pozostają schowane. Że trzy grupy klientów prowadzone są jedną ścieżką. Że nawigacja odzwierciedla wewnętrzne działy firmy zamiast pytań odbiorcy. Że kontakt nadal rozpoczyna się w miejscu, w którym klient nie ma jeszcze wystarczających informacji do decyzji.
Design nie jest winny.
Po prostu otrzymał zadanie odnowienia warstwy, która nie była głównym problemem.
Jeżeli trzeba zachować starą logikę tylko dlatego, że jest już wdrożona, modernizacja zaczyna pracować dla strony, a nie dla firmy.
Przebudowa nie oznacza wyrzucenia wszystkiego
Decyzja o budowie nowego systemu od fundamentu nie powinna oznaczać cyfrowej amnezji.
Stara strona może zawierać bardzo wartościowe elementy.
Może mieć treści, które nadal odpowiadają na właściwe pytania. Dobre realizacje. Zdjęcia. Dane analityczne. Adresy podstron istniejące od lat. Materiały pobierane przez klientów. Linki prowadzące z innych serwisów. Widoczność wypracowaną przez określone treści.
Przebudowa nie powinna niszczyć tych zasobów tylko po to, żeby wszystko było „nowe”.
Powinna rozdzielić to, co warto zachować, od struktury, która nie powinna już decydować o przyszłości strony.
To ważne także technicznie.
Jeżeli przebudowa zmienia adresy URL albo strukturę serwisu, migracja powinna zostać zaplanowana, a nie potraktowana jako automatyczny efekt publikacji nowej wersji. Google Search Central opisuje przy takich zmianach między innymi przygotowanie mapowania starych i nowych adresów, wdrożenie przekierowań, aktualizację linków wewnętrznych i monitorowanie serwisu po zmianie.
Nowa strona od fundamentu nie oznacza więc: usuń starą i zacznij z pustą kartką.
Oznacza: przestań dziedziczyć błędne założenia, ale nie wyrzucaj sprawdzonych zasobów razem z nimi.
Nie każda trudna zmiana oznacza przebudowę
Tu łatwo przesadzić w drugą stronę.
Jeżeli przy każdej większej modyfikacji wykonawca dochodzi do wniosku, że „najlepiej będzie zrobić wszystko od nowa”, firma powinna zapytać dlaczego.
Nowa strona nie jest nagrodą za znalezienie kilku problemów.
Musi istnieć związek pomiędzy problemami.
Jeżeli stara strona ma nieaktualny wygląd, ale jej logika nadal działa, nie ma powodu przebudowywać całej architektury.
Jeżeli problemem jest źle działający formularz, nie trzeba na tej podstawie zmieniać pozycjonowania firmy.
Jeżeli firma potrzebuje lepszego modelu późniejszych aktualizacji, sam ten fakt nie oznacza, że trzeba pisać wszystkie treści od początku. Ten temat ma własną funkcję i wymaga osobnej diagnozy modelu zmian.
Przebudowa jest uzasadniona wtedy, gdy można wskazać jedno albo kilka starych założeń nadrzędnych, które powodują problemy w wielu warstwach.
To zasadnicza różnica.
Lista usterek mówi, ile rzeczy można poprawić.
Diagnoza pokazuje, dlaczego te rzeczy wymagają poprawy jednocześnie.
Granica przebudowy pojawia się wtedy, gdy znika sens kolejnej poprawki
Firma nie musi umieć samodzielnie zaprojektować nowej architektury, żeby podjąć rozsądną decyzję.
Musi natomiast wiedzieć, czego oczekuje od następnego etapu.
Jeżeli obecna strona nadal potrafi przyjąć dzisiejszą ofertę, właściwe dowody i aktualną ścieżkę klienta bez tworzenia kolejnych wyjątków, warto ją zachować i poprawić.
To często jest lepsza decyzja niż pełna przebudowa.
Jeżeli jednak kolejne zmiany wymagają dokładania alternatywnych ścieżek, powielania tych samych informacji, obchodzenia szablonów, wciskania nowych usług w dawny podział albo zachowywania nieaktualnych elementów tylko dlatego, że cały system jest od nich zależny, inwestowanie w następne poprawki przestaje być ostrożnością.
Staje się odkładaniem decyzji.
Dlatego przed redesignem nie zaczynałbym od pytania:
„Co na tej stronie wygląda staro?”
Zacząłbym od innego:
„Czy dzisiejsza firma nadal mieści się w decyzjach, według których zbudowano tę stronę?”
Jeżeli tak — poprawiajmy.
Jeżeli nie — warto najpierw zaprojektować właściwy system, a dopiero później jego wygląd.