Długi ogon
Nie przesadzaj
Na etapie wymagań określono zrozumiały zestaw kluczowych przypadków użycia. Pamiętaj o tych priorytetach i unikaj dodawania do tej listy przypadków skrajnych. Gdy przejdziemy do szczegółów, pojawią się nowe scenariusze, które wcześniej nie były przez Ciebie brane pod uwagę. Zanim poszerzysz zakres projektu, aby uwzględnić te nowe scenariusze, dobrze się zastanów nad jego skutkami.
| Głowa | Treść | Długi ogon |
|---|---|---|
|
Najważniejsze przypadki użycia To najważniejsze i najczęstsze ścieżki rozmów użytkowników w ramach tej funkcji. Skup się głównie na tym, aby te ścieżki były wygodne dla użytkowników. |
Objazdy Takie działania są rzadsze i często nie odnoszą się bezpośrednio do celu, ale są mniej skuteczne. Poświęć czas na odpowiednie wsparcie zespołu finansowego, ale nie trać czasu na wpisywanie słów. |
Przypadki progowe To bardzo nietypowe ścieżki. Zastanów się, czy ogólne komunikaty, takie jak „Przykro mi, nie wiem, jak pomóc”, są wystarczająco dobre lub czy możesz podać bardziej szczegółowe informacje, używając podobnego rozwiązania, które jest praktycznie nieprzydatne. |
Aby uniknąć przeoczenia projektu, użyj reguły 80/20, czyli zasady Pareta.
W przypadku projektowania rozmów ta reguła mówi, że nie wszystkie ścieżki są sobie równe. 80% użytkowników podąża za 20% najczęstszymi ścieżkami w oknie dialogowym. Dlatego inwestuj odpowiednie zasoby, aby osiągnąć jak najlepsze wyniki.
I podobnie, jeśli chodzi o kompromis pod względem doskonałości i kompletności. Dopracowanie ostatnich 20% projektu może zająć 80% pracy. W takich przypadkach niedopracowane rozwiązanie może być „dobre”.
Typowe objazdy
Pomiędzy kluczowymi przypadkami użycia i przypadkami skrajnymi to często spotykane objazdy. Zwykle są to nowe scenariusze, które nie były brane pod uwagę, dopóki nie zostaną ujawnione podczas testowania lub wykryte podczas programowania. Najczęściej wymagają one dłuższej, mniej bezpośredniej obsługi na alternatywnej ścieżce.
Oto kilka typowych objazdów do rozważenia:
Rozłączone konta
W takim przypadku użytkownik nie połączył konta.
Nieobsługiwane działania
Użytkownicy mogą prosić o podjęcie działań, których Twoja akcja nie obsługuje.
Zasięg intencji
Projekt rozmowy obejmuje spisanie scenariusza jednej połowy dialogu. Mamy nadzieję, że jest wystarczająco ciekawy, aby każdy mógł zabrać głos. Gdy projektujesz stronę z długiego ogona, skup się na tym, co użytkownik może powiedzieć na każdym jej etapie, aby określić zamiary.
Intencja odzwierciedla powiązanie między wypowiedzią użytkownika a działaniem. Na przykład komunikat „Czy lubisz pizzę?” zawiera zamiary „tak” i „nie”. Z każdym zamiarem powinny być powiązane różne wyrażenia treningowe, takie jak „tak” i „nie” oraz odmiany takie jak „Uwielbiam to” czy „To brudne”. Waga może być ważona na podstawie częstotliwości występowania. Intencje mogą także zawierać adnotację, na przykład sklasyfikowanie „świeżego mozzarelly” jako formy pizzy w odpowiedzi użytkownika „tylko wtedy, gdy jest przyrządzona ze świeżej mozzarelli”.
Jeśli używasz Dialogflow, przejdź tutaj, aby dowiedzieć się więcej.
Zapobieganie występowaniu błędów jest lepsze niż rozwiązywanie problemów po ich wystąpieniu.
Tak.
uwzględnić zamiar wyrazu „gotowe” wraz z wyrażeniami typu „Gotowe” lub „To wszystko”.
Nie.
Jeśli akcja oczekuje tylko pytań o I/O, odpowiedź użytkownika spowoduje wyświetlenie błędu o braku dopasowania.
Obsługa błędów
Nawet jeśli są zdecydowane intencje, wciąż może się zdarzyć błąd. Użytkownicy mogą wyłączyć skrypt, pozostając w stanie cichym (braku wejścia) lub mówiąc nieoczekiwanego błędu (braku dopasowania). Używaj komunikatów o błędach, które delikatnie nakłaniają użytkowników do powrotu na ścieżkę lub zmiany oczekiwań.
Dobre postępowanie z błędami zależy od kontekstu, więc monity „Brak danych wejściowych” i „Brak dopasowania” muszą być tworzone dla każdego etapu w oknie dialogowym.