Instrukcja rozwiązywania problemu powinna pomagać wybrać następne działanie na podstawie tego, co klient rzeczywiście widzi. Lista „odśwież, wyloguj się, zmień przeglądarkę” często zaciera ślady i każe wszystkim wykonać te same próby. Dla jednego objawu przygotuj krótkie drzewo: pytanie, możliwe odpowiedzi, bezpieczny krok oraz wynik pozwalający zakończyć albo przejść dalej. Taką konstrukcję można opublikować w bazie wiedzy bez budowania osobnego narzędzia diagnostycznego.
Nazwij objaw, zanim zaczniesz zgadywać przyczynę
Objaw zapisz w języku obserwacji, na przykład „Po wybraniu eksportu nie widzę pliku”. Nie zaczynaj od tytułu „Awaria eksportera”, jeśli nie masz potwierdzonej przyczyny. Klient może mieć nieaktywny przycisk, brak uprawnienia albo pobrany plik w innym miejscu, a każdy z tych stanów wymaga innej drogi. W pierwszym akapicie wskaż, dla jakiego ekranu i działania przygotowano instrukcję, aby osoba z podobnym, lecz innym problemem nie weszła w błędną ścieżkę.
Zbierz trzy ostatnie zgłoszenia dotyczące tego objawu i wypisz dokładne komunikaty oraz ostatnie działanie poprzedzające problem. Usuń dane klienta, zachowując potrzebne nazwy elementów interfejsu. Jeżeli przypadki dotyczą tylko wybranej grupy, ich techniczne porównanie opisz oddzielnie, zgodnie z podejściem do błędów widocznych u części użytkowników. Artykuł dla klienta ma pokazać rozróżnienia dostępne na jego ekranie, a nie wszystkie hipotezy zespołu.
Zadaj pytanie, którego odpowiedź zmienia następny krok
Pytanie rozstrzygające ma prowadzić do różnych działań, a nie jedynie potwierdzać, że problem istnieje. „Czy eksport nie działa?” nie daje nowej informacji, natomiast „Czy przycisk Eksportuj jest aktywny?” rozdziela dwa stany możliwe do sprawdzenia. Dodaj opis rozpoznania: aktywny przycisk można wybrać, nieaktywny pozostaje niedostępny mimo wskazania kursorem. Unikaj pytań o wewnętrzne nazwy komponentów albo ustawienia, do których klient nie ma dostępu.
Rozpisz co najwyżej kilka odpowiedzi w jednym miejscu, tak aby użytkownik nie musiał porównywać całego ekranu z katalogiem usterek. Dla odpowiedzi „Nie wiem” przygotuj sposób obserwacji, na przykład wskazanie miejsca z komunikatem. Nie traktuj niepewności jako odpowiedzi „Nie”, bo skierujesz część osób do niewłaściwej gałęzi. Przejdź każdą drogę własnoręcznie i sprawdź, czy po pytaniu naprawdę zmienia się krok, a nie tylko jego opis.
Przypisz każdej gałęzi działanie i widoczny wynik
Bezpieczne działanie powinno być możliwe do wykonania bez usuwania danych, wyłączania zabezpieczeń ani zmiany ustawień całej organizacji. W przykładowej instrukcji eksportu zacznij od sprawdzenia wyboru raportu, komunikatu o dostępie i listy pobrań. Nie proponuj instalacji dodatków ani ponownego tworzenia raportu, jeśli dostępne obserwacje tego nie uzasadniają. Tabela pokazuje trzy różne odnogi jednego objawu; nie opisuje rzeczywistego eksportera Meetlead.
Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Obserwacja | Bezpieczne działanie | Dalsza droga |
|---|---|---|
| Przycisk eksportu jest nieaktywny | Sprawdź, czy wybrano raport i zakres | Po wyborze ponownie oceń przycisk |
| Przycisk działa, pojawia się komunikat o uprawnieniu | Poproś administratora o sprawdzenie dostępu | Nie powtarzaj eksportu bez zmiany dostępu |
| Pobieranie rusza, ale pliku nie widać | Sprawdź listę pobrań przeglądarki | Znajdź plik lub zapisz dokładny komunikat |
Po każdym działaniu dopisz konkretny wynik, na przykład „Przycisk stał się aktywny” albo „Na liście pobrań widzisz nazwę pliku”. Zamiast „Jeżeli pomogło, zakończ” podaj, co trzeba zaobserwować, aby uznać zadanie za wykonane. Gdy wynik jest inny, wskaż dokładnie następną gałąź, bez polecenia rozpoczęcia całego artykułu ponownie. Klient powinien móc wrócić do ostatniego potwierdzonego stanu po przypadkowym przełączeniu zakładki, dlatego nazwij kolejne odnogi i używaj tych samych nazw także w odsyłaczach prowadzących dalej.
Zapisz pełny przebieg zamiast samych haseł
Przykładowa instrukcja może brzmieć: „Otwórz raport, z którego chcesz pobrać plik, i sprawdź przycisk Eksportuj. Jeśli jest nieaktywny, wybierz raport oraz zakres wymagany na tym ekranie, a następnie ponownie sprawdź przycisk. Jeśli jest aktywny, wybierz go jeden raz i odczytaj komunikat. Komunikat o uprawnieniu oznacza przejście do sprawdzenia dostępu, a rozpoczęte pobieranie oznacza przejście do listy pobrań przeglądarki”. Każde zdanie ma tu obserwowalny warunek.
Druga część może mówić: „Jeżeli widzisz plik na liście pobrań, otwórz go i sprawdź, czy dotyczy wybranego raportu. Jeśli zamiast pliku pojawia się błąd, zapisz treść komunikatu oraz godzinę próby i nie powtarzaj działania w pętli”. To przykład do dostosowania do własnej aplikacji, nie gotowa porada dla dowolnego błędu pobierania. Informacje z zatrzymanej gałęzi mogą zasilić opis zadania wynikającego z błędu klienta bez proszenia go o odtworzenie wszystkiego jeszcze raz.
Google w wytycznych pisania procedur zaleca jasno określić zadanie i kontekst kroków. Poniższe drzewo jest proponowaną metodą redakcyjną, a nie opisem automatycznej diagnostyki produktu.
Oddziel warunek startu od ścieżki naprawy
Warunek startu sprawdza, czy klient w ogóle może wykonać zadanie, natomiast gałąź naprawy bada już zaobserwowany problem. Wymagana rola albo wcześniej utworzony raport należą na początek instrukcji jako warunki. Nie każ osobie bez dostępu przechodzić przez pobieranie, zmianę przeglądarki i inne próby, aby dopiero na końcu odkryła ograniczenie. Sposób zapisania takiego początku opisujemy w artykule o warunkach wstępnych instrukcji.
Dodaj wyraźny punkt zatrzymania tam, gdzie samodzielna droga się kończy. Może to być brak dostępu do ustawienia, komunikat wymagający interwencji administratora albo powtórzenie tego samego błędu po jednym uzasadnionym kroku. Powiedz, jakie informacje warto zachować: nazwę ekranu, komunikat i wynik ostatniego działania. Nie wymagaj haseł, plików z danymi ani pełnego zrzutu konta, jeżeli do rozróżnienia gałęzi wystarcza opis. Tak samo działa to przy odrzuconej karcie podarunkowej: wystarczy końcówka kodu i komunikat, co pokazuje poradnik o tym, co zrobić, gdy voucher prezentowy nie działa.
Sprawdź drzewo z osobą, która nie zna rozwiązania
Próba redakcyjna polega na przejściu instrukcji bez dopowiadania brakujących kroków przez autora. Daj drugiej osobie jeden opisany stan i poproś o wskazanie następnego działania na podstawie samego artykułu. Zanotuj miejsca, gdzie musi odgadnąć nazwę przycisku, znaczenie wyniku albo sposób powrotu. Jeśli pyta o przyczynę błędu, sprawdź, czy w tekście przypadkiem nie zamieniłeś obserwacji w niepotwierdzone wyjaśnienie.
W Meetlead MeetAI i bazie wiedzy możesz sprawdzić dostępne możliwości publikacji pomocy oraz pracy zespołu z artykułami. Najpierw przygotuj jedno dobrze opisane drzewo, a następnie porównaj je z faktycznym ekranem i uprawnieniami odbiorcy. Po zmianie interfejsu ponownie przejdź gałęzie, szczególnie punkty, które zależą od nazwy komunikatu lub miejsca przycisku. Artykuł pozostaje czytelny tylko wtedy, gdy jego rozróżnienia nadal istnieją w produkcie.
Pytania o instrukcje rozwiązywania problemów
Ile gałęzi powinien mieć artykuł? Tyle, ile potrzeba do odróżnienia najważniejszych widocznych stanów jednego objawu. Zacznij od dwóch lub trzech pytań, a dalsze odmiany dodawaj dopiero wtedy, gdy zmieniają zalecane działanie.
Jeśli drzewo obejmuje wiele ekranów i odrębnych zadań, rozdziel artykuły oraz połącz je nazwanymi odsyłaczami. Czytelnik powinien wiedzieć, dlaczego przechodzi do innej instrukcji.
Czy można zalecić odświeżenie strony? Tak, jeśli znasz jego skutek dla bieżącego zadania i poprzedzisz je sprawdzeniem niezapisanej pracy. Opisz, co zostanie zachowane, a czego klient powinien wcześniej dopilnować, wyłącznie na podstawie sprawdzonego zachowania aplikacji.
Nie używaj odświeżenia jako domyślnego kroku dla każdej gałęzi. Jeden uzasadniony krok powinien kończyć się oceną wyniku, a nie nieskończoną serią ponownych prób.
