Checkout to ostatnie miejsce, w którym użytkownik jeszcze może się wycofać. Gdy przy wyborze delivery time slot (okna czasowego dostawy) coś jest niejasne, pojawia się frustracja: „gdzie kliknąć?”, „czemu zniknęło?”, „dlaczego nie mogę przejść dalej?”. Wtedy problem nie jest tylko w mechanice — duży udział ma UX writing, czyli komunikacja w samym interfejsie.
W praktyce chodzi o to, by użytkownik wiedział, co ma znaczyć każde pole, co jest wymagane, jak wybór zależy od konfiguracji i dostępności oraz co zrobić w chwili walidacji. WooCommerce w funkcji zbierania delivery date/time w checkout wymaga wyboru daty, a przy jej braku pokazuje komunikat błędu („Delivery date is required”). Ty nie zawsze możesz zmienić treść błędu systemowego — ale możesz przygotować treści „przed” nim, tak aby błąd nie był zaskoczeniem.
W tym poradniku pokażemy, jak zaprojektować etykiety, placeholdery, instrukcje i komunikaty w sytuacjach brzegowych, bez obiecywania dostępności „na pewno” i bez przerzucania winy na użytkownika. Zrobimy to językiem, który ma prowadzić: krok po kroku, spokojnie, konkretnie.
Dlaczego copy w checkout ma znaczenie przy delivery time slot
W checkout użytkownik nie czyta „dla wiedzy”. Skanuje. Podejmuje decyzję w pośpiechu. Jeśli w tym momencie komunikaty są zbyt ogólne albo pojawiają się dopiero, gdy mechanika już zablokowała przejście, rośnie ryzyko porzucenia koszyka.
Dlatego copy przy delivery time slot powinno spełniać trzy role naraz: uprzedzać (co będzie dalej), prowadzić (co dokładnie wybrać) oraz oswajać (dlaczego wybór może być ograniczony). Dobrze zaprojektowany mikrotekst redukuje „martwe końce”, czyli sytuacje, gdy użytkownik próbuje wybrać coś losowo, a system nie pozwala.
W ujęciu funkcjonalnym ważna jest logika „delivery intent”, opisana w dokumentacji: gdy opcja zbierania preferencji dostawy jest włączona, użytkownik nie może dokończyć checkoutu bez wskazania wymaganej daty. Dodatkowo, przy włączonej selekcji czasu, wybór czasu może być opcjonalny — zależnie od konfiguracji. To oznacza, że komunikaty muszą być dopasowane do tego, co jest naprawdę wymagane, a co tylko bywa dodatkiem.
Na końcu dochodzi jeszcze walidacja. Gdy użytkownik nie wybierze daty, pojawia się komunikat błędu: „Delivery date is required”. Twoim zadaniem jest sprawić, by użytkownik nie dochodził do tej blokady „z niewiedzy”. Copy ma przygotować go wcześniej, tak by błąd był raczej potwierdzeniem: „tak, to właśnie tu trzeba wybrać datę”, a nie frustracją.
Co użytkownik musi zrozumieć, zanim zobaczy listę slotów
Zanim użytkownik zobaczy listę dostępnych okien czasowych, musi zrozumieć zależność między krokami. W dokumentacji pojawia się kluczowy mechanizm: dostępność i logika wyboru wynikają z konfiguracji dostawy oraz zasad wyboru. Co to oznacza w języku UX writing?
Po pierwsze: użytkownik ma wiedzieć, że sloty nie działają w próżni. W praktyce selekcja okien czasowych jest powiązana z wyborem daty i regułami skonfigurowanymi w dostawie (np. podziałem dni na time frames). Po drugie: jeśli funkcja delivery intent jest włączona, pole „delivery date” jest wymagane, a bez niego nie da się przejść dalej.
Po trzecie: time selection może być opcjonalny zależnie od ustawień. Najważniejsze dla komunikacji jest to, że copy powinno odróżniać „must-have” od „nice-to-have”. Jeśli czas jest opcjonalny, nie warto pisać o nim jak o jedynej drodze. Jeśli natomiast system ma wymagać daty, etykieta i podpowiedź muszą to podkreślać.
W praktyce możesz myśleć o tym tak: najpierw tłumaczysz „dlaczego wybór jest ograniczony”, potem pokazujesz „jak wybrać” i dopiero na końcu (w walidacji) mówisz „co teraz”. Tak minimalizujesz sytuację, w której użytkownik widzi listę slotów, ale nie rozumie, skąd się wzięła ani czego system oczekuje przed nią.
Uwaga praktyczna dla zespołów wdrożeniowych i marketingowych: jeśli w checkout masz dwa tryby prezentacji (np. blok estymacji albo kalendarz wyboru daty), copy powinno wspierać wybrany tryb. W dokumentacji WooCommerce opisano, że „Checkout display” może determinować, czy pojawia się estymacja, czy pole/kalendarz do wyboru daty — a to zmienia, jak użytkownik interpretuje komunikaty.
Etykiety i placeholdery: jak pisać komunikaty przy „Preferred Delivery Date”
Jeśli w checkout widzisz pole z nazwą „Preferred Delivery Date”, potraktuj to jako punkt kotwiczenia całego procesu. Użytkownik powinien od razu zrozumieć: to jest preferencja terminu dostawy, a nie tylko „informacja techniczna”. Dodatkowo — skoro system wymaga wyboru daty, etykieta i placeholder powinny wzmacniać tę intencję.
W dokumentacji wskazano, że pole ma label (etykietę) oraz placeholder zawierający najwcześniejszy dostępny termin. To jest gotowy materiał do UX copy: użytkownik ma się opierać na tym, co system prezentuje jako pierwszy możliwy wybór, zamiast zgadywać.
Jak to ubrać w słowa?
- Label: nie zostawiaj użytkownika z samym skrótem. Jeśli etykieta brzmi „Preferred Delivery Date”, warto, by komunikacja obok (nawet jednym zdaniem) potwierdzała, że chodzi o preferowaną datę dostawy.
- Placeholder: potraktuj go jak „wejście w proces”. Skoro placeholder zawiera najwcześniejszy dostępny termin, nie rób dodatkowego zamieszania tekstem, który mówi „wybierz datę”, ale nie dodaje nic ponad to.
- Wymagalność: oznaczenie pola jako wymagane (np. wizualny znak przy polu) powinno być spójne z tym, co komunikujesz w tekście. Jeśli w UI wiesz, że walidacja zadziała, nie pisz, że wybór jest „mile widziany”.
- Język: unikaj sformułowań typu „kliknij”, „zaznacz” bez wskazania, co dokładnie ma być wybrane i po co.
Dobrym testem redakcyjnym jest pytanie: „czy użytkownik potrafiłby uzupełnić pole poprawnie bez czytania całej strony?”. Jeśli odpowiedź brzmi „raczej tak”, to etykieta i placeholder spełniają swoją rolę. Jeśli użytkownik musi dopytać, gdzie jest najbliższy dostępny termin albo czy data jest wymagana — w tej sekcji wciąż brakuje jednego zdania, które zdejmie niepewność.
Pamiętaj też o bezpieczeństwie komunikacji: nie obiecuj, że wybrana data zawsze będzie możliwa ani że lista będzie identyczna dla każdego. W dokumentacji podkreślono, że dostępność wyboru jest ograniczona konfiguracją. Copy ma informować o mechanice, a nie zastępować system.
Instrukcje w UI: jak opisać zależność slotów od konfiguracji i dostępności
Jeśli chcesz, by komunikacja delivery time slot minimalizowała „znikanie opcji” albo „nie wiem, czemu nie ma godzin”, kluczowe są instrukcje w UI. WooCommerce opisuje ustawienie „Delivery instructions”, które może wyświetlać dodatkowe informacje nad polem wyboru daty w sekcji „Delivery details”. To dokładnie miejsce na podpowiedź o zależnościach.
W tej podpowiedzi nie chodzi o techniczny opis systemu. Chodzi o uspokojenie użytkownika: „okna czasowe wynikają z reguł i tego, co dostępne dla wybranej daty”. W praktyce instrukcja powinna odpowiedzieć na dwa pytania, zanim użytkownik zacznie klikać.
- Co wybieram jako pierwszy krok? Jeśli pole daty jest wymagane, instrukcja ma to wprost wspierać.
- Dlaczego lista może wyglądać inaczej? Bo wybór wynika z ustawionych time frames i dostępności (a więc konfiguracji dostawy).
W języku UX writing unikaj winienia użytkownika za brak znalezienia slotu. Zamiast „nie wybrałeś poprawnej daty” lepiej pisać „dostępne okna pojawiają się zgodnie z zasadami dla wybranej daty”. Dzięki temu sytuacja wygląda na przewidywalną, a nie na błąd w interfejsie.
Pomocne jest także dopasowanie do trybu prezentacji w checkout. Dokumentacja WooCommerce wskazuje, że rozszerzenie może wyświetlać blok estymacji albo umożliwiać wybór daty (kalendarz), zależnie od ustawienia „Checkout display”. Jeśli użytkownik widzi estymację, twoja instrukcja powinna podpowiadać interpretację („to szacowany termin” itp.), a jeśli ma kalendarz — wspierać proces wyboru.
Na koniec jedna ważna zasada redakcyjna: instrukcja ma przygotować do tego, że dostępność jest zależna od konfiguracji i może się zmieniać. Nie obiecuj kompletności listy ani stałej puli godzin. To nie tylko uczciwe, ale też chroni przed wrażeniem „klikam, a UI nie działa”.
Walidacja i błąd „Delivery date is required”: jak pisać komunikaty, gdy termin jest wymagany
W dokumentacji WooCommerce jest jasno opisane zachowanie: jeśli użytkownik nie wybierze daty, system pokaże komunikat błędu przy próbie złożenia zamówienia, np. „Delivery date is required”. Oznacza to, że w twoim planie copy muszą pojawić się dwie warstwy: wcześniejsze podpowiedzi (żeby do błędu nie dochodziło) oraz komunikacja w momencie walidacji (żeby błąd był zrozumiały i prowadzący).
Nie zakładaj, że zawsze da się personalizować treść systemowego błędu. Dlatego lepiej zaplanować treści „obok”, które zredukują zaskoczenie. Co konkretnie robić?
- Przed walidacją: użyj etykiety i placeholderu tak, by użytkownik widział, że data ma być wskazana, a najbliższy dostępny termin jest już podany przez system.
- Przed walidacją: dodaj instrukcję (delivery instructions) wyjaśniającą zależność slotów od konfiguracji i dostępności, tak aby użytkownik rozumiał logikę wyboru.
- W momencie walidacji: upewnij się, że użytkownik potrafi wrócić do właściwego pola i uzupełnić brak. Walidacja jest wtedy „jasna referencja”, a nie zagadka.
- Ton: brak moralizowania. System mówi „date required”, a ty możesz podpowiedzieć spokojnie „wybierz wymagany termin”, bez dopisywania „zrobiłeś błąd”.
W praktyce najlepsze mikrocopy wokół walidacji to takie, które działa jak mapa. Jeśli system blokuje przejście, to użytkownik potrzebuje odpowiedzi tylko na jedno: „co mam zrobić teraz?”. W twojej komunikacji (w UI przed błędem) powinno to już być obecne.
Jeżeli w checkout masz ustawienia, które zmieniają widoczność elementów (estymacja vs wybór), sprawdź, czy w obu wariantach użytkownik nadal rozumie, że datę trzeba wskazać. W przeciwnym razie walidacja stanie się pierwszym momentem, w którym pojawia się informacja o wymaganiu — a to najgorszy scenariusz dla UX.
Gdy slotów nie da się wybrać: co komunikować, żeby nie eskalować frustracji
Użytkownik może trafić na sytuacje brzegowe: brak dostępnych okien w danym kontekście, zmieniająca się lista slotów po wyborze daty albo moment, w którym klikane opcje nie dają efektu. Copy nie naprawi konfiguracji, ale może sprawić, że problem będzie czytelny.
Jak to nazwać? W duchu dokumentacji, która podkreśla ograniczenia dostępności wynikające z konfiguracji i zasad wyboru, komunikat nie powinien udawać, że „sloty powinny być”. Lepiej pisać o sytuacji: „w tym momencie dostępne są ograniczone okna dla wybranej daty” lub „nie ma dostępnych opcji w tym zakresie”.
Jednocześnie daj kierunek działania. Jeśli wybór daty jest wymagany, to prawdopodobnie najbardziej sensowny krok to zmiana daty i powrót do wyboru czasu (jeśli time selection jest oferowany jako opcja). Jeśli czas jest opcjonalny — uprzedź, że nie zawsze trzeba go wskazywać, ale datę należy mieć ustawioną.
Dbaj też o długość tekstu. W checkout nie ma miejsca na elaboraty. Komunikat ma powiedzieć: co się stało i co zrobić teraz, w możliwie krótkim zdaniu.
Najważniejsza zasada: nie eskaluj „winą po stronie użytkownika”. Nie sugeruj, że „źle wybrał” ani że „powinien kliknąć gdzie indziej”. Zgodnie z mechaniką, sloty zależą od konfiguracji i dostępności, więc komunikat powinien delikatnie oddać, że to reguły systemu decydują o tym, co jest widoczne.
Checklisty dla copy do checkoutu (delivery date/time slot) + jak to wdrożyć w briefie
Poniższa checklisty pomoże zespołom marketingu i e-commerce przygotować mikrocopy tak, by wspierało wybór delivery time slot oraz minimalizowało zaskoczenie walidacją. Traktuj je jak część briefu: nie jako „ładne hasła”, tylko jako elementy, które trzeba zredagować i wkleić we właściwe miejsca w UI.
- Label i wymagalność: potwierdź, że etykieta przy polu „Preferred Delivery Date” i wizualne oznaczenie wymagania są spójne z komunikacją. Użytkownik ma rozumieć, że bez daty nie przejdzie dalej.
- Placeholder: wykorzystaj informację o najwcześniejszym dostępnym terminie (tam, gdzie jest w UI). Nie wprowadzaj dodatkowymi zdaniami sprzeczności ani niepowtarzaj tego, co placeholder już komunikuje.
- Instrukcja nad polem: przygotuj miejsce na „delivery instructions” (tam, gdzie jest dostępne w konfiguracji), aby wyjaśnić, że okna czasowe zależą od konfiguracji i dostępności.
- Kolejność kroków: w treści prowadź w logice „najpierw data, potem (opcjonalnie) czas”. Jeśli time selection jest opcjonalne w twoim setupie, nie rób z czasu warunku przejścia.
- Walidacja: załóż, że system może pokazać błąd „Delivery date is required”. Twoje wcześniejsze komunikaty mają sprawić, by użytkownik wiedział, co trzeba uzupełnić, zanim zobaczy błąd.
- Scenariusz „brak slotów”: zapisz krótkie brzmienie komunikatu, które nazywa sytuację jako ograniczenie dostępności zgodne z regułami, oraz podaje kolejny krok (np. zmień datę).
Jak to wdrożyć w briefie? Wystarczy, że dodasz sekcję „Mikrocopy checkout delivery intent” z polami do wypełnienia: treść etykiety, propozycja treści instrukcji nad polem (w ramach „delivery instructions”), wariant komunikatu dla sytuacji, gdy czas jest opcjonalny oraz scenariusz „co zrobić, gdy slotów nie ma”. Dzięki temu copy powstaje jako system komunikatów, a nie pojedyncze zdanie przypadkowo podpięte pod UI.
Na koniec pamiętaj, że twoim celem nie jest zmiana mechaniki ani „obejście” walidacji. Twoim zadaniem jest dopasowanie języka do tego, co system wymaga i pokazuje. Gdy użytkownik rozumie zależności, walidacja przestaje zaskakiwać, a wybór delivery time slot przestaje być polowaniem na godziny. Skontaktuj się z Aleteksty.pl, aby omówić artykuły, teksty na stronę, opisy produktów lub regularną obsługę treści.
