Weryfikacja tożsamości w procesie onboardingu to jeden z tych momentów, w których użytkownik jednocześnie chce szybko skończyć i czuje, że „od tego zależy bezpieczeństwo”. Jeśli ekran „Zweryfikuj swoją tożsamość” nie prowadzi krok po kroku, pojawia się zgadywanie: czy mam kliknąć gdzieś indziej, czy coś przygotować, czy to potrwa długo, czy to się uda. A weryfikacja ma działać jak instrukcja, nie jak test.
W tym poradniku pokazujemy, jak pisać komunikaty UX do KYC: tak, aby cel był jasny, następny krok widoczny, wymagane elementy podane w prostych słowach, a alternatywy i błędy prowadziły do działania. Skupimy się na układzie treści, języku bezpieczeństwa oraz mikrocopy „co przygotować” — czyli na tym, co realnie ogranicza tarcie i błędy w formularzach.
Jeśli chcesz, żeby użytkownik wiedział „co dalej” bez frustracji, potraktuj ten ekran jak mapę: krótko informuje, ale przede wszystkim prowadzi.
Dlaczego ekran „zweryfikuj tożsamość” jest wyjątkowy (i wrażliwy na tarcie)
Cel komunikatu: prowadzić do następnego kroku
Komunikat w onboardingie KYC nie może kończyć się na wyjaśnieniu „dlaczego”. Użytkownik potrzebuje przede wszystkim odpowiedzi na pytanie: co mam zrobić teraz. To dlatego, że weryfikacja tożsamości zwykle uruchamia się w chwili, gdy człowiek ma już zamiar przejść dalej, a jednocześnie nie chce ryzykować błędu. Dobrze napisany ekran łączy więc cel z akcją: informuje, po co jest krok, i od razu pokazuje kolejny ruch w tej samej kolejności, w jakiej użytkownik wykona działania.
Praktycznie oznacza to strukturę „od intencji do wykonania”: najpierw jedno zdanie, które ustawia kontekst, potem lista kroków, a dopiero na końcu szczegóły. W praktyce copy działa wtedy jak nawigacja — ogranicza zgadywanie, bo użytkownik widzi dokładnie, gdzie jest teraz i co dalej.
Komunikacja bezpieczeństwa: prosty język, czytelna forma
W obszarze bezpieczeństwa łatwo popaść w niepotrzebny dystans: zdania mogą brzmieć jak komunikaty administracyjne albo techniczne, a to zwiększa niepewność. Niezależnie od tego, jak działa proces pod spodem, warstwa user-facing powinna być czytelna i oparta o proste polecenia. Pomaga tu podejście „reading to do”: część tekstu ma być nie tyle do zrozumienia, co do wykonania.
Co to daje w praktyce? Po pierwsze, krótkie zdania i bez żargonu. Po drugie, czytelna forma dopasowana do interakcji na telefonie: użytkownik przewija, klika i wykonuje zadania, więc treść musi szybko przełożyć się na działanie. Po trzecie, komunikaty nie powinny tworzyć wrażenia, że użytkownik „próbuje na ślepo”. Nawet jeśli pojawiają się dodatkowe okoliczności, ekran ma prowadzić w tym samym rytmie: co przygotować, co zrobić, i kiedy przejść dalej.
Co musi się znaleźć na ekranie: cel → kroki → wymagania
Kroki, które użytkownik ma zobaczyć (w tej logice)
Jeśli ekran ma spełniać swoje zadanie, użytkownik powinien widzieć kroki w takiej logice, by nie zastanawiał się nad kolejnością. Dobry układ startuje od działania, które uruchamia proces w interfejsie (np. akceptacja lub przejście dalej), a kończy na wykonaniu wymaganych ujęć. W praktyce weryfikacja tożsamości zwykle obejmuje serię czynności w krótkim sekwencyjnym przebiegu: użytkownik zgadza się na kontynuację, wykonuje zdjęcia dokumentu oraz przeprowadza weryfikację autentyczności (np. kamerą lub selfie), a na końcu dopiero przechodzi do dalszych elementów onboardingu.
Ważne jest też, by komunikat nie „zasypywał” szczegółami od razu. Nawet jeśli proces ma kilka etapów, użytkownik nie powinien czytać instrukcji jak instrukcji instalacji. Zamiast tego pokaż kroki jako listę lub uporządkowane fragmenty treści, które można wykonać po kolei.
Wymagania: dokument + selfie, plus instrukcje wykonawcze
Obok kroków musi pojawić się konkret: co użytkownik ma przygotować, aby weryfikacja mogła przejść. To miejsce na jasną listę wymagań opisanych user-facing. Z perspektywy UX writingu kluczowe jest, by użytkownik wiedział, że potrzebuje zarówno dokumentu tożsamości (ze zdjęciem), jak i elementu weryfikacji autentyczności (np. selfie lub potwierdzenia kamerą). Same hasła typu „przygotuj dokument” zwykle nie wystarczają, bo użytkownik nie wie, jak przygotować wykonanie tak, żeby później nie wracać.
Dlatego instrukcje wykonawcze powinny być krótkie i praktyczne. Zamiast długiego wyjaśnienia, podaj wskazówki dotyczące jakości ujęć oraz zgodności danych. W komunikacie może to brzmieć jak instrukcja do wykonania: dokument ma być czytelny, zdjęcie ma pokazywać wymagane elementy, a selfie ma oddać to, co jest potrzebne do weryfikacji w procesie. W efekcie tekst ogranicza liczbę błędów, bo użytkownik nie próbuje „domyślać się”, tylko robi dokładnie to, co wspiera akceptowalny rezultat.
Alternatywne ścieżki bez chaosu: jak je nazwać i kiedy oferować
Język do alternatyw: „wybierz drogę”, nie „zacznij od nowa”
Nie każdy użytkownik przejdzie proces dokładnie w tej samej formie — to normalne. Na poziomie komunikacji nie chodzi o to, by „przewidywać problemy”, tylko by przygotować alternatywy tak, żeby nie tworzyły wrażenia chaosu lub porażki. Dlatego alternatywy najlepiej opisywać jako wybór drogi w ramach tego samego celu: użytkownik ma dalej wykonać weryfikację, tylko inaczej technicznie.
W praktyce pomocny jest język, który nie resetuje kontekstu. Zamiast sugerować „zacznij od nowa”, ustaw komunikat jako kontrolowany wybór: „jeśli nie możesz wykonać weryfikacji w aktualny sposób, wybierz inną opcję”. Wtedy użytkownik rozumie, że to nadal prowadzi do zakończenia onboardingu i że zmienia tylko sposób realizacji. Równie ważne jest, aby jasno powiedzieć, kiedy alternatywa jest właściwa — niech decyzja nie będzie „w ciemno”, tylko powiązana z konkretną sytuacją i tym, co widzi na ekranie.
Język komunikatów w obszarze bezpieczeństwa: plain language i czytelna forma
Co zmienia się w błędach: od informacji do naprawy
Komunikaty o błędach w KYC nie powinny być tylko informacją „nie wyszło”. W UX writingu to jest moment, w którym użytkownik najbardziej potrzebuje kolejnego kroku. Najgorsza wersja błędu to taka, która nie mówi, co zrobić teraz: wtedy człowiek wraca do wcześniejszych pól albo rezygnuje. Lepsza wersja to zamiana frustracji na instrukcję naprawy.
Jak to pisać? Utrzymuj prosty język i formułę „sprawdź → popraw → spróbuj ponownie” w obrębie oficjalnego interfejsu procesu. Gdy pojawia się odrzucenie albo problem z wykonaniem elementu (np. ujęciem dokumentu), komunikat powinien wskazywać praktyczne działania: spróbować w inny sposób ustawienia ujęcia, ponowić wykonanie zdjęcia w warunkach, które wspierają poprawność, albo sprawdzić komunikaty w interfejsie. Warto też dodać krótką informację o zgodności danych: jeśli proces wymaga porównania elementów z dokumentu z danymi w koncie, to komunikat może przypominać o tym wprost, ale w neutralnym, nietechnicznym języku.
W efekcie błąd przestaje brzmieć jak wyrok, a zaczyna działać jak instrukcja serwisowa: użytkownik wie, co ma skorygować, i może wrócić do działania bez dodatkowej niepewności.
Mikrocopy „co przygotować” przed startem: szybka checklistka
Przykładowa logika checklisty (bez wchodzenia w szczegóły techniczne)
Najwięcej tarcia powstaje często zanim użytkownik w ogóle zacznie. Dlatego mikrocopy „co przygotować” przed weryfikacją ma sens, nawet jeśli to tylko kilka linijek na górze ekranu. Taka checklistka powinna być krótka, konkretna i nastawiona na wykonanie. Z punktu widzenia UX writingu dobrze, gdy obejmuje 3–5 elementów i prowadzi użytkownika do właściwego startu.
Proponowana logika jest następująca: dokument → warunki wykonania → selfie/weryfikacja kamerą → zgodność danych → co zrobić, gdy proces się nie udaje. To daje użytkownikowi mentalny plan działania, zanim pojawi się moment podjęcia kroku (np. gdy ekran przechodzi do etapu zdjęć). W praktyce możesz to ująć jako listę lub krótkie punkty w jednej sekcji, tak aby użytkownik nie musiał wracać i szukać brakującego elementu w połowie procesu.
Checklistka powinna też zawierać jeden spokojny zwrot „co dalej, jeśli pojawi się problem”, który kieruje do kontrolowanej alternatywy w ramach procesu. W ten sposób tekst nie zwiększa stresu, tylko daje poczucie prowadzenia.
Przykładowy układ treści (szablon) dla ekranu „Zweryfikuj tożsamość”
Gdzie umieścić alternatywy i naprawę, żeby użytkownik nie „odpinał się”
Szablon ekranu warto układać tak, by alternatywy i komunikaty naprawcze były dostępne tam, gdzie użytkownik ich potrzebuje — bez szukania po całym interfejsie. Dobrym standardem jest trzymanie jednej ścieżki „prowadzącej”: nagłówek i cel na początku, kroki w kolejności wykonania, a wymagania jako krótkie wskazówki przy etapie, do którego są potrzebne. Wtedy treść nie miesza się z decyzjami, a użytkownik wykonuje zadanie zgodnie z ruchem ekranu.
Alternatywy umieść w tej samej strefie, w której użytkownik podejmuje decyzję o metodzie wykonania — najlepiej jako jedno, czytelne miejsce typu „inne opcje” na etapie, gdy proces nie startuje albo użytkownik widzi, że aktualna forma mu nie odpowiada. Komunikaty naprawcze natomiast powinny pojawiać się w kontekście błędu, jako instrukcje „co teraz”, zorientowane na działanie w obrębie interfejsu. Jeśli komunikat błędu będzie mówił, co użytkownik ma sprawdzić i jak ponowić próbę, to zmniejsza prawdopodobieństwo „odpinania się” od procesu (np. zamknięcia okna lub cofania do wcześniejszych etapów bez sensu).
Tak ułożony ekran wspiera to, co w UX writingu najważniejsze: spójność kolejnego kroku. Użytkownik nie tylko rozumie, co robi, ale też widzi, że nawet w razie problemu jest następna, konkretna akcja.
Podsumowując: ekran KYC działa najlepiej, gdy komunikaty są pisane jako „reading to do” — cel jest jasny, a kolejne kroki prowadzą do wykonania bez zgadywania. Kluczowe elementy treści to jednozdaniowy sens procesu, uporządkowane kroki oraz wymagania (dokument i weryfikacja autentyczności) opisane wprost i w prostym języku. Alternatywy i błędy powinny zawsze kierować do kontrolowanej następnej akcji, a nie do chaosu czy niepewności. Skontaktuj się z Aleteksty.pl, aby omówić artykuły, teksty na stronę, opisy produktów lub regularną obsługę treści.
