Blog Metlivi

Jak produkty czatowe dla osób szukających towarzystwa powinny rozpoznawać, że użytkownik chce zakończyć rozmowę?

Produkt czatowy dla osób szukających towarzystwa powinien traktować jasny komunikat o zakończeniu jako instrukcję, rozpoznać, kiedy żądana czynność jest ukończona, i umożliwić użytkownikowi przerwę bez konieczności wyjaśniania jej powodów. Gdy rozmowa dobiegnie końca, powinien krótko ją zamknąć i pozostawić następny ruch użytkownikowi. Praktycznym sposobem zaprojektowania takiego rozwiązania jest uporządkowanie sygnałów według ich jednoznaczności, nadanie pierwszeństwa wyraźnym prośbom i unikanie domysłów na podstawie nastroju użytkownika lub jego milczenia.

30 września 20266 min czytaniaAutor: Metlivi Editorial Team
Sekcja 1

Zacznij od słów użytkownika, a nie od teorii na temat jego nastroju

Wiadomości takie jak „stop”, „skończyłem”, „wystarczy”, „do widzenia” lub „zostawmy to na tym” bezpośrednio wskazują, że użytkownik chce zakończyć rozmowę. Uwzględnij te zwroty i ich naturalne warianty w mechanizmie obsługi zakończenia. Traktuj je jako instrukcje sterujące w całej rozmowie, także podczas aktywności twórczej lub gdy system zadaje pytanie.

Jest to zgodne z uznanymi wytycznymi dotyczącymi projektowania rozmów. Google zaleca respektowanie wyrażeń takich jak „skończyłem” i „nieważne”, a także odradza podważanie decyzji osoby, która chce przerwać niedokończone zadanie, jeśli oznaczałoby to niewielką stratę postępów. Amazon Lex podobnie definiuje intencję zakończenia dla zwrotów wskazujących, że użytkownik chce zakończyć interakcję. (Wytyczne Google dotyczące kończenia rozmów; wbudowana intencja zakończenia w Amazon Lex)

Odpowiedź produktu powinna raz potwierdzić przyjęcie instrukcji, a następnie zakończyć turę. Na przykład: „Rozumiem. Możemy na tym skończyć”. Po takim potwierdzeniu nie zadawaj kolejnego pytania, nie zachęcaj do dalszej rozmowy ani nie proś o uzasadnienie decyzji. Polecenie zakończenia nie powinno przeradzać się w krótkie negocjacje, w których użytkownik musi się powtarzać.

Sekcja 2

Traktuj ukończenie zadania jako naturalny moment na zakończenie

Użytkownik może skończyć bez mówienia „stop”. Może poprosić o krótkie opowiadanie i je otrzymać, wybrać pomysł na weekendową aktywność lub dokończyć poprawianie wiadomości. Gdy żądany wynik zostanie dostarczony i żadna część zadania nie pozostaje nierozwiązana, system może zamknąć rozmowę krótkim komunikatem, na przykład „Oto gotowa wersja” lub „Masz już plan na sobotę”. Nie musi automatycznie dopisywać: „Co jeszcze chcesz zrobić?”

To wniosek projektowy wynikający z zaleceń, by odpowiedzi w rozmowie były krótkie, trafne i skupione na zadaniu. Lista kontrolna Amazon dotycząca projektowania rozmów zaleca ograniczanie liczby kroków i podawanie istotnych komunikatów, a także odradza przerywanie doświadczenia niezwiązaną z nim ofertą. Zastosowanie tego do czatów dla osób szukających towarzystwa sugeruje, że pytania uzupełniające powinny zależeć od rzeczywistego kolejnego kroku, zamiast pojawiać się po każdej ukończonej odpowiedzi. (Zasady projektowania rozmów dla Amazon Alexa)

Są wyjątki. Jeśli prośba składa się z kilku części, produkt powinien zrealizować wszystkie obiecane elementy lub jasno powiedzieć, co jeszcze pozostało. Jeśli użytkownik prosi o wersję roboczą i poprawki, zwrócenie samej wersji roboczej nie oznacza ukończenia zadania. Jednak gdy uzgodniony zakres zostanie zrealizowany, otwarte pytanie może sprawić, że zakończona interakcja wyda się niedokończona. Zwięzłe zakończenie zapobiega cichemu rozszerzaniu zadania użytkownika przez system.

Sekcja 3

Ułatw wyrażenie przerwy i wznowienie rozmowy

Przerwa różni się od zakończenia. Zwroty „zróbmy przerwę”, „wrócę do tego”, „chwileczkę” lub „zapisz to na później” mogą sygnalizować, że użytkownik chce odpocząć, zachowując dotychczasową pracę. Jeśli produkt obsługuje historię rozmów lub zapisane wersje robocze, może prostym językiem potwierdzić, co pozostanie dostępne. Jeśli nie może zachować bieżącego stanu, a to ograniczenie ma znaczenie, powinien powiedzieć o tym, zanim użytkownik odejdzie.

Pozostaw kontrolę nad przerwą użytkownikowi. Nie wymagaj wyjaśnień ani nie podsuwaj powodów przerwy. Jeśli produkt ma widoczny przycisk pauzy lub zamknięcia, opisz go jasno i zapewnij przewidywalny skutek. Wytyczne W3C dotyczące kontroli użytkownika mówią, że zmiany kontekstu powinny być inicjowane przez użytkownika lub mieć mechanizm wyłączania; zasada ta przemawia za czytelnymi kontrolkami i przewidywalnym zachowaniem przy przechodzeniu między stanami. (Wytyczne W3C dotyczące zmiany na żądanie)

Produkt powinien też rozróżniać przerwę od wyraźnego zakończenia na podstawie słów i działań dostępnych w interfejsie. Jeśli funkcja na to pozwala, przerwa może zachować wersję roboczą lub bieżące miejsce w zadaniu. Zakończenie powinno zamknąć obecną interakcję. Nie twierdź, że rozmowa została zapisana, jeśli tak się nie stało, i nie traktuj wyjścia z aplikacji ani milczenia jako prośby o wysłanie kolejnych wiadomości.

Sekcja 4

Ustal jasną kolejność dla sygnałów niejednoznacznych i wyraźnych

Praktyczna hierarchia sygnałów do wdrożenia:

Wyraźne polecenie zakończenia lub pożegnanie: niezwłocznie zakończ rozmowę.

Wyraźna prośba o przerwę lub zapisanie: wstrzymaj rozmowę lub zapisz jej stan, jeśli to możliwe, a następnie krótko potwierdź wynik.

Ukończona prośba: podaj żądany wynik i zakończ bez wymuszania kolejnej tury.

Niejasna wiadomość: zadaj jedno krótkie pytanie doprecyzowujące tylko wtedy, gdy niejednoznaczność uniemożliwia wykonanie zadania.

Milczenie: poczekaj lub zakończ aktywną sesję zgodnie ze zwykłym działaniem produktu; nie wyciągaj wniosków o stanie emocjonalnym użytkownika.

Ta kolejność to praktyczna propozycja projektowa, a nie opublikowana miara ani uniwersalny klasyfikator. Jej celem jest zapobieganie sytuacjom, w których bezpośrednie instrukcje są unieważniane przez słabsze przypuszczenia. Na przykład „Wystarczy” powinno mieć pierwszeństwo przed przewidywaniem systemu, że powiązana sugestia może być mile widziana. Pytanie takie jak „Czy chcesz tutaj skończyć, czy zapisać to na później?” jest odpowiednie tylko wtedy, gdy sformułowanie użytkownika rzeczywiście nie wyjaśnia, który rezultat ma nastąpić.

Jeśli produkt umożliwia działanie o istotnych konsekwencjach lub istnieje ryzyko utraty znacznej ilości pracy, potwierdzenie może pomóc ją ochronić. Sformułuj je konkretnie i tak, by łatwo było na nie odpowiedzieć: „Zakończyć teraz i odrzucić tę wersję roboczą?” W zwykłej rozmowie, w której utracone postępy byłyby niewielkie, ponowne potwierdzanie tworzy niepotrzebne utrudnienie. Wytyczne Google wskazują na to samo rozróżnienie: nie potwierdzaj ponownie wyjścia, chyba że utracone zostałyby znaczne postępy. (Wytyczne Google dotyczące kończenia rozmów)

Sekcja 5

Niech komunikat kończący będzie krótki i kompletny

Komunikat kończący powinien spełniać jeden cel: jasno pokazywać, że system zrozumiał użytkownika i że interakcja została zakończona lub wstrzymana. Odpowiednie przykłady:

Zakończenie: „Dobrze. Na tym skończymy”.

Ukończone zadanie twórcze: „Oto poprawiony wiersz”.

Przerwa z zapisaniem pracy: „Wstrzymano. Twoja wersja robocza jest zapisana na tym czacie”.

Przerwa bez funkcji zapisu: „Dobrze. Możesz wrócić do tego czatu później, ale nie mogę zapisać osobnej wersji roboczej”.

Używaj wyłącznie komunikatów zgodnych z rzeczywistym działaniem produktu. Unikaj emocjonalnych apeli, wypowiedzi wzbudzających poczucie winy i nowych pytań. Zakończenie może być serdeczne, ale nie powinno wymagać od użytkownika uspokajania systemu ani kontynuowania interakcji. Celem projektu jest jasne zakończenie, któremu użytkownik może zaufać.

Sekcja 6

Testuj sytuacje graniczne, nie tylko oczywiste polecenia

Sprawdź krótkie przykłady rozmów z codziennego użytkowania: bezpośrednie polecenie zakończenia podczas opowiadania historii, „wystarczy” po rekomendacji, ukończone zadanie pisemne, prośbę o przerwę w połowie oraz niejednoznaczne „może później”. Sprawdź, czy każdy przypadek prowadzi do zamierzonego działania i czy po wyraźnym poleceniu zakończenia lub ukończeniu zadania nie pojawia się pytanie uzupełniające.

Sprawdź też fałszywe alarmy. W zdaniu „Przestań używać tego zwrotu i spróbuj innego” słowo „przestań” występuje w ramach instrukcji dotyczącej zadania, a niekoniecznie jako prośba o zakończenie czatu. Interpretuj słowa w kontekście, a jednocześnie zapewnij osobny przycisk zakończenia na wypadek, gdyby system błędnie zrozumiał wypowiedź. Dokumentacja Amazon opisuje wbudowaną intencję zakończenia dla typowych zwrotów oznaczających zakończenie; produkt czatowy dla osób szukających towarzystwa może zastosować tę samą podstawową koncepcję i dostosować rozpoznawanie do interfejsu tekstowego lub głosowego. (Wbudowana intencja zakończenia w Amazon Lex)

Śledź praktyczne błędy, takie jak kolejne pytanie po prośbie o zakończenie, nieistotny komunikat po ukończonym zadaniu lub utrata pracy po przerwie mimo sugestii, że została zapisana. Są to obserwowalne kontrole działania, a nie oceny tego, co czuje użytkownik. Pomagają zespołom ulepszać interakcję bez prób diagnozowania użytkowników na podstawie ich słów.

Sekcja 7

Prosta zasada uprzejmego zakończenia

Gdy użytkownik wyraźnie kończy rozmowę, zakończ ją. Gdy uzgodnione zadanie jest ukończone, zamknij rozmowę krótkim komunikatem. Gdy użytkownik prosi o przerwę, pozostaw mu kontrolę i wyjaśnij dostępne opcje zapisu. Zadaj pytanie uzupełniające tylko wtedy, gdy jest potrzebne do ukończenia prośby lub wyjaśnienia rzeczywistej niejednoznaczności. Dzięki temu produkty czatowe dla osób szukających towarzystwa mogą konkretnie rozpoznawać zakończenia, pozostawiając użytkownikowi codzienne wybory, decyzję o czasie i kontynuacji.

Warto przeczytać

Eksploruj dalej ten temat