Większość porad o zmianie nazwy kończy się na wyborze nowej nazwy. To łatwiejsza połowa. Trudniejsza to przeniesienie tysięcy ludzi, którzy już znają twój produkt, dodali go do zakładek, powiedzieli o nim koledze i wpisali twoją starą nazwę do własnych dokumentów. Zrób to źle, a nie tylko wydasz pieniądze — nauczysz użytkowników, że twoja nazwa to niepewna informacja, co jest dziwną rzeczą do wpojenia ludziom, których najbardziej chcesz, by cię pamiętali.
Zanim więc wygenerujesz choćby jednego kandydata, odpowiedz na pytanie, które faktycznie rządzi projektem: czy ta zmiana nazwy warta jest dezorientacji, którą wywoła? Czasem wyraźnie tak. Często jest to projekt próżnościowy, który po cichu spala rozpoznawalność budowaną latami.
Kiedy zmiana nazwy jest uzasadniona
Zmiana nazwy zarabia na swoje zakłócenie, gdy obecna nazwa czyni aktywną szkodę, a nie tylko wtedy, gdy ktoś w zespole się nią znudził. Cztery sytuacje przekraczają tę poprzeczkę.
Konflikt znaku towarowego albo żądanie prawne to najjaśniejszy przypadek — nie masz tu głosu, a zwłoka tylko podnosi koszt. Prawdziwy zwrot kategorii jest następny: jeśli wystartowałeś jako „InvoiceNest”, a biznes jest teraz pełną platformą księgową, nazwa stała się pułapem, a każdy potencjalny klient, który ją czyta, niedocenia, co robisz. Fuzja albo przejęcie wymusza pytanie, gdy dwie nazwy nie mogą obie przetrwać na jednym produkcie. I wreszcie nazwa, która aktywnie wprowadza w błąd — sugeruje funkcję, którą usunąłeś, rynek, który opuściłeś, albo skalę, której nigdy nie miałeś — warta jest wymiany, bo kosztuje cię w zgłoszeniach do wsparcia i niedopasowanych oczekiwaniach co tydzień.
Zauważ, czego nie ma na tej liście. „Założycielom nigdy się nie podobała”, „konkurent ma fajniejszą nazwę”, „przerobiliśmy stronę i nazwa wydała się stara” — to zmiany próżnościowe. Wymieniają realną, zbankowaną rozpoznawalność na uczucie. Jeśli ludzie już wpisują twoją nazwę w okno wyszukiwania i cię znajdują, ten nawyk to aktywo w bilansie. Zmieniaj nazwę ponad nim tylko, gdy nazwa jest zobowiązaniem większym, niż nawyk jest aktywem.
Wybierz następcę, który redukuje dezorientację z założenia
Oto dźwignia, którą większość zespołów pomija: sama nowa nazwa może wykonać za ciebie sporo pracy przejściowej. Następca, który dzieli dźwięk, kształt albo inicjał ze starą nazwą, pozwala użytkownikom przenieść istniejącą pamięć naprzód, zamiast zaczynać od zera.
Powiedzmy, że schodzisz z „Postmark” dla narzędzia do wiadomości. „Parcel” zachowuje P i dwusylabowy rytm, więc ktoś, kto połowicznie pamięta starą nazwę, wciąż ląduje blisko nowej. „Zephyra” to niezła nazwa w oderwaniu, ale jako następca nie dzieli niczego z tym, co było wcześniej — każdy strzęp rozpoznawalności resetuje się do zera, a ty płacisz pełną cenę za świadomość jeszcze raz. Zachowanie pierwszej litery chroni też drobiazgi, o których zapominasz: glif favikony, monogram ikony aplikacji, handle z @, po który ludzie sięgają z pamięci.
To nie reguła do wymuszania — zwrot kategorii czasem domaga się czystego zerwania właśnie dlatego, że chcesz zrzucić stare skojarzenia. Ale gdy twoim celem jest ciągłość, traktuj fonetyczne albo wizualne pokrywanie się jako cechę do wyselekcjonowania, a nie przypadek. Jeśli ważysz kandydatów, pomaga przepuścić ich przez szczerą krytykę zapamiętywalności i ryzyka pisowni, zamiast ufać entuzjazmowi pokoju; to dokładnie taki test pod presją, jaki dobry generator nazw produktów jest zbudowany, by stosować.
Poprowadź przejście na moście
Najużyteczniejszym mechanizmem w zmianie nazwy jest most: „NowaNazwa (dawniej StaraNazwa)”. Pojawia się wszędzie, gdzie pojawia się nazwa — nagłówek strony, wpis w sklepie z aplikacjami, ekran logowania, stopka faktury, nazwa nadawcy e-maila. Jego całym zadaniem jest złapać osobę, która szuka starej nazwy, i zapewnić ją, że jest we właściwym miejscu.
Trzymaj most dłużej, niż wydaje się konieczne. Zgrubna wskazówka: trzymaj „dawniej StaraNazwa” eksponowane przez pierwsze trzy miesiące, utrzymaj w cichszej formie (stopka, centrum pomocy, podtytuł w sklepie) przez sześć do dwunastu, i zdejmij dopiero, gdy własna analityka pokaże, że wyszukiwania i wzmianki starej nazwy w zgłoszeniach ucichły. Usunięcie mostu to ostatni krok zmiany nazwy, a nie pierwszy — zespoły, które zrywają go wcześnie, bo nowa nazwa „ustabilizowała się wewnętrznie”, zapominają, że wnętrze to jedyna publiczność, która nigdy go nie potrzebowała.
Chroń hydraulikę: przekierowania, wyszukiwanie i zapis
Wszystko, czym użytkownik albo wyszukiwarka docierali dawniej, musi wciąż się rozwiązywać. Przekieruj starą domenę na nową przekierowaniami trwałymi (301), mapując każdą starą ścieżkę na jej konkretny nowy odpowiednik, a nie zrzucając wszystkich na stronę główną — przekierowania ścieżka-do-ścieżki przekazują autorytet wyszukiwania, który już zdobyłeś, i lądują ludzi tam, gdzie zmierzali.
Zaktualizuj kanoniczny zapis nazwy produktu we wszystkich miejscach, które kontrolujesz, ale rzadko o nich myślisz: tytuł i podtytuł w sklepie z aplikacjami, ekrany zgody OAuth, deskryptory rozliczeniowe na wyciągach kart klientów (niedopasowany deskryptor wywołuje obciążenia zwrotne), nazwy nadawców e-maili transakcyjnych i dokumentacja API. Potem obsłuż dług, którego nie w pełni kontrolujesz — poradniki, odpowiedzi na forach i recenzje osób trzecich, które wciąż używają starej nazwy. Nie naprawisz ich wszystkich, dlatego właśnie most i przekierowania mają znaczenie: pokrywają długi ogon, którego osobiście nie przepiszesz.
Ogłoś to raz, jasno i w dobrym czasie
Powiedz użytkownikom, zanim odkryją zmianę przypadkiem. Krótki baner w aplikacji albo jednorazowy modal przy następnym logowaniu — „Jesteśmy teraz NowaNazwa. Ten sam produkt, ten sam login, te same dane” — zabija najczęstsze zgłoszenie do wsparcia przy zmianie nazwy, którym nie jest „czemu zmieniliście nazwę”, tylko „czy padłem ofiarą phishingu / czy was przejęto / czy moje konto jest bezpieczne”. Odpowiedz najpierw na pytanie o bezpieczeństwo; historia za nazwą to przypis, którego większość użytkowników nie potrzebuje.
Co do czasu, oddziel zmianę nazwy od innych ryzykownych zdarzeń. Nie wypuszczaj dużej wersji, zmiany cennika i zmiany nazwy w tym samym tygodniu — jeśli coś się zepsuje, nie będziesz wiedział, którą zmianę winić, a użytkownicy obwinią najbardziej widoczną, którą jest nowa nazwa. Wybierz spokojny okres, unikaj dni wokół dużego wydania i daj wsparciu gotową odpowiedź oraz uprzedzenie, zanim cokolwiek ruszy.
Wzorzec ku przestrodze
Jest utarty tryb awaryjny wart nazwania bez wymieniania nazw: produkt, który zmienia nazwę wielokrotnie w krótkim czasie. Firma bazodanowa, która zmieniła nazwę dwa razy w trzy lata, nie tylko wydawała pieniądze za każdym razem — nauczyła własnych użytkowników, żeby przestali uczyć się jej nazw, bo nazwa wciąż okazywała się tymczasowa. Rozpoznawalność kumuluje się tylko, jeśli pozwolisz jej usiąść. Każda zmiana nazwy resetuje ten zegar, więc celem nie jest zmieniać nazwę dobrze i często; celem jest zmieniać ją rzadko i sprawić, by każda się przyjęła.
Traktuj zmianę nazwy jako migrację, a nie premierę. Uzasadnij ją wobec rozpoznawalności, którą wydajesz, wybierz następcę niosącego starą pamięć naprzód, poprowadź ją na widocznym moście, chroń przekierowania i zapis, i ogłoś raz, z odpowiedzią na pytanie o bezpieczeństwo z góry. Zrób tak, a większość użytkowników zaktualizuje etykietę w głowach i pójdzie dalej — co dla zmiany nazwy jest najlepszym możliwym rezultatem.