Powiadomienia pod kontrolą: klient chce wyciszyć temat, nie zniknąć z systemu

Ewa wycisza projekt, bo ktoś poprawia w nim podpisy pod czterdziestoma fotografiami. Nie chce czterdziestu wiadomości. Chce natomiast dowiedzieć się, że czeka na nią decyzja o publikacji. Gdy ustawienie brzmi „Powiadomienia: włączone / wyłączone”, musi wybrać pomiędzy spokojem a wiedzą o własnym zadaniu. To kiepski formularz negocjacji z aplikacją.

Przykład jest fikcyjny: projektujemy portal, w którym kilka firm przygotowuje materiały do wspólnego katalogu. Ewa zatwierdza wybrane kolekcje, czasem komentuje zdjęcia, a część projektów tylko obserwuje. Ustawienia powinny odpowiadać tym różnicom. Nie projektujemy tu prawnych zasad kontaktu marketingowego ani gwarancji doręczenia. Ustalamy, co użytkownik może świadomie wybrać i jak pozna skutek tego wyboru.

Jedna etykieta „powiadomienie” potrafi obejmować nowy komentarz, przypomnienie o terminie, e-mail z wynikiem działania i systemowy dymek na telefonie. Dopóki zespół nie rozdzieli tych rzeczy, wygodny ekran będzie jedynie eleganckim pilotem do nieznanego urządzenia.

Temat jest czymś innym niż miejsce dostarczenia

Najpierw nazwij zdarzenia, które rzeczywiście interesują Ewę. Dodanie komentarza w obserwowanej kolekcji ma inny ciężar niż przypisanie jej decyzji do wykonania. Drobna aktualizacja fotografii nie musi od razu przerywać pracy. Dla każdego zdarzenia ustal odbiorcę, powód poinformowania oraz drogę do odpowiedniej części projektu.

Dopiero później wybieraj kanały. To samo zdarzenie może pojawić się w panelu, w e-mailu i na urządzeniu. Trzy zaznaczenia nie powinny oznaczać trzech różnych obowiązków. Są trzema sposobami dotarcia do tej samej sprawy. Jeśli przeczytanie jednego komunikatu zmienia pozostałe, produkt powinien to jasno określić; jeśli nie, nie nazywaj wszystkich kopii jedną zsynchronizowaną skrzynką.

GitHub w instrukcji ustawień powiadomień rozdziela rodzaje obserwowanej aktywności i sposoby otrzymywania informacji. Można wybrać określone zdarzenia repozytorium; udział w rozmowie lub wzmianka o osobie stanowią osobny powód subskrypcji.

W naszym portalu podobne rozróżnienie pomaga nazwać ustawienia, bez kopiowania całego modelu GitHub. Ewa może chcieć e-maili o zadaniach przypisanych jej bezpośrednio, a aktualizacje obserwowanych kolekcji oglądać tylko w panelu. Przycisk „Wyłącz e-mail” powinien zmienić kanał, nie usunąć przypisanego zadania ani wycofać jej z projektu.

Rozpisanie preferencji może zacząć się od czterech konkretnych zdań użytkowniczki:

• „Chcę wiedzieć, że ktoś poprosił mnie o decyzję”. To wybór rodzaju zdarzenia.
• „Nie potrzebuję tego również w telefonie”. To wybór kanału.
• „Drobne aktualizacje przeczytam razem po południu”. To wybór częstotliwości, jeśli produkt obsługuje podsumowania.
• „Przez godzinę nie chcę żadnych przerw w tej kolekcji”. To czasowe wyciszenie o określonym zakresie.

Zamiana tych czterech zdań na jeden suwak usuwa znaczenie, którego użytkownik właśnie potrzebuje. Nie trzeba jednak pokazywać całej tabeli kombinacji przy pierwszym wejściu. Można zacząć od zrozumiałych grup i rozwijać szczegóły tam, gdzie występuje rzeczywista decyzja.

„Wycisz” musi mieć dopełnienie

Jeśli Ewa wybiera wyciszenie przy konkretnej kolekcji, oczekuje skutku dotyczącego tej kolekcji. Globalne wyłączenie całego konta byłoby zaskoczeniem. Przy ustawieniach organizacji trzeba dodatkowo wskazać firmę. Osoba pracująca w kilku przestrzeniach może chcieć innych reguł dla każdej z nich.

Nazwij rezultat przed potwierdzeniem: „Wycisz aktualizacje kolekcji Jesień do jutra”. Pokaż, czy obejmuje to wszystkie kanały i co dzieje się z bezpośrednimi prośbami o decyzję. Jeśli te ostatnie nadal będą przychodzić, użytkowniczka powinna dowiedzieć się o tym w tym samym miejscu. Dopisek ukryty w długiej pomocy nie wyjaśnia skutku przycisku.

Slack opisuje czasowe wstrzymanie powiadomień oraz harmonogram ciszy. Dokumentacja wskazuje również wyjątek: nadawca wiadomości bezpośredniej może raz dziennie powiadomić o pilnej sprawie mimo wstrzymania. Zakres wyciszenia ma więc znaczenie razem z wyjątkami.

Dla katalogu możemy przyjąć inne zasady. Jeśli Ewa wycisza wyłącznie aktualizacje, napisz „Wycisz aktualizacje”, zamiast „Nie przeszkadzać”. Jeżeli istnieje wyjątek dla przydzielonego zadania, pokaż go jako część reguły. Nie należy nazywać każdej wiadomości pilną tylko dlatego, że jej autor zaznaczył odpowiednie pole. Właściciel produktu musi ustalić, kto może używać tego wyjątku i do czego służy.

Czasowe ustawienie potrzebuje widocznego końca. „Do jutra” może być wygodną etykietą wyboru, ale potwierdzenie powinno wyjaśniać moment wznowienia według czasu pokazywanego użytkowniczce. Stałe wyłączenie jest inną decyzją. Nie przywracaj powiadomień po arbitralnym okresie, jeśli ekran obiecał wyciszenie bez terminu.

Przy regule powtarzanej, na przykład ciszy wieczornej, sprawdź również zmianę dnia i strefy czasu. To nie musi oznaczać projektowania pełnego kalendarza, lecz wymaga jawnej odpowiedzi, według którego zegara działa harmonogram. W cyklicznych terminach ten sam problem dotyczy zachowania reguły w kolejnych datach. Sam zapis „codziennie 18–8” nie wyjaśnia, czy po zmianie strefy nadal chodzi o wieczór i poranek Ewy.

Wyciszenie powinno dać się odnaleźć i odwrócić. Krótki komunikat przy kolekcji może pokazać jego zakres, koniec i przycisk wznowienia. Gdy jedynym śladem pozostaje chwilowy dymek po kliknięciu, Ewa następnego dnia nie wie, czy powiadomienia nie przyszły z powodu własnego wyboru, czy awarii.

Jeśli kolekcja ma własne ustawienie, pokaż jego relację do reguły konta. Można napisać: „Korzysta z ustawienia konta: tylko przydzielone zadania” albo „Własny wybór dla tej kolekcji: bez e-maili”. Powrót do reguły konta jest wtedy osobną, rozpoznawalną czynnością. Sam pusty przełącznik nie mówi, czy oznacza wyłączenie, brak wyboru czy korzystanie z ustawienia nadrzędnego.

Po zmianie reguły konta Ewa powinna wiedzieć, czy wyjątek kolekcji nadal obowiązuje. Dla naszego katalogu przyjmijmy, że tak: wyjątek pozostaje widoczny, dopóki Ewa go nie usunie. Odbiór obejmie więc kolekcję bez wyjątku i kolekcję z własnym wyborem. Dopiero ich porównanie pokaże, czy opis hierarchii zgadza się z wynikiem.

Zgoda urządzenia nie zastępuje preferencji produktu

Ewa włączyła wiadomości o decyzjach na telefonie. Strona nie ma jednak pozwolenia przeglądarki na systemowe powiadomienia. To dwa różne ustawienia. Ekran może poprawnie zapamiętać wybór Ewy, a mimo to nie mieć możliwości pokazania dymka. Status „Włączone” bez wyjaśnienia tej zależności tworzy obietnicę, której użytkowniczka nie potrafi sprawdzić.

MDN opisuje wynik prośby strony o pozwolenie na powiadomienia: zgoda, odmowa lub nieznana decyzja. W ostatnim przypadku aplikacja zachowuje się jak przy odmowie. Prośba powinna wynikać z działania użytkownika.

Projekt może więc pokazać osobno preferencję i dostępność kanału: „Wybrane dla zadań przypisanych tobie; przeglądarka blokuje powiadomienia”. Dalszy przycisk ma prowadzić do rzeczywiście dostępnej czynności. Nie pokazuj przycisku obiecującego kolejną prośbę, jeśli potrzebna jest zmiana ustawienia przeglądarki. Nie oznaczaj również całego konta jako wyciszonego, gdy blokada dotyczy jednego urządzenia.

Przy uprawnieniach kamery, mikrofonu i lokalizacji także rozdzielamy wybór w produkcie od pozwolenia środowiska. Tutaj dochodzi jeszcze kwestia dotarcia wiadomości. Nawet uzyskana zgoda na wyświetlanie nie jest dowodem, że konkretne powiadomienie dotarło i zostało zauważone. Komunikat potwierdzający zmianę preferencji powinien mówić o zapisaniu ustawienia.

Sprawdź też nieudany zapis samych preferencji. Po wyłączeniu kanału suwak może zmienić położenie od razu, zanim serwer potwierdzi wybór. W razie błędu Ewa musi zobaczyć, czy nadal obowiązuje poprzednia reguła. Nie zostawiaj wyłączonego wizualnie kanału z komunikatem „spróbuj później”, jeśli wiadomości wciąż będą wysyłane. Zachowaj również pozostałe wybory, aby ponowienie nie wymagało ustawiania wszystkiego od początku.

Podobnie e-mail wymaga rozpoznawalnego adresata. Jeśli konto ma kilka adresów, pokaż, który służy wybranemu kanałowi. Zmiana adresu kontaktowego firmy nie musi automatycznie zmieniać osobistych powiadomień Ewy. Tę zależność ustala produkt, a ekran ma ją uczciwie przedstawiać. Przy niepotwierdzonym adresie pokaż wymagany krok, zamiast zapewniać, że wiadomości już trafiają do skrzynki.

Takie reguły warto zestawić ze sposobem ograniczania przerwań w pracy zespołu. Sam panel nie wyjaśni, co zespół uznaje za pilne i gdzie trafi sprawa bez natychmiastowej odpowiedzi. W naszym przykładzie Ewa ma nadal własną listę decyzji; wyciszenie dymków nie usuwa odpowiedzialności za katalog.

Co ma zostać po wyciszeniu

Wyciszenie aktualizacji nie musi usuwać informacji z historii kolekcji. Ewa może chcieć wrócić do niej po godzinie i zobaczyć, co zmieniło się podczas ciszy. Jeśli produkt tak działa, zaprojektuj drogę do zaległych zdarzeń. Jeśli historia obejmuje tylko wybrane działania, nazwij ten zakres, zamiast obiecywać kompletny zapis wszystkiego.

Nie trzeba po wznowieniu wysyłać osobnej wiadomości za każdą pominiętą drobną zmianę. Można pokazać podsumowanie lub oznaczyć nowe zdarzenia w panelu. Najpierw jednak ustal, co robi faktyczny mechanizm: odkłada dostarczenie, pomija powiadomienia czy przygotowuje zbiorczą wiadomość. Te warianty tworzą inne oczekiwania co do chwili zakończenia ciszy.

Podsumowanie ma własne znaczenie. Jeśli o 16:00 przychodzi informacja o prośbie, na którą Ewa odpowiedziała już o 15:00, treść nie powinna twierdzić, że decyzja nadal czeka. Można pokazać zdarzenie jako element historii albo pominąć je według uzgodnionej reguły. Powiadomienie o dawnym zdarzeniu i aktualny stan zadania wymagają różnych zdań.

Przy wiadomościach niezbędnych do konkretnego przebiegu nazwij ich rolę. Użytkownik proszący o link do odzyskania dostępu powinien rozpoznać, że uruchamia tę wiadomość świadomie. Nie chowaj takiej czynności pod ogólną kategorią „aktualności”. Zarazem uznanie wiadomości za potrzebną w procesie nie rozstrzyga jej podstaw prawnych. Ten artykuł porządkuje projekt, nie zastępuje odrębnej oceny komunikacji.

Z wiadomości transakcyjnych warto zachować zasadę zgodności zdarzenia, tytułu i dalszego działania. Z ustawień musi wynikać, którą część tej komunikacji człowiek kontroluje. Nie należy przedstawiać ograniczonej preferencji jako przycisku „Nigdy już do mnie nie pisz”, jeśli produkt nadal przewiduje określone wyjątki.

Odbiór na zdarzeniu, którego miało nie być

Do sprawdzenia wybierz konkretne konto i kolekcję z danymi próbnymi. Wycisz aktualizacje, dodaj nowy komentarz z drugiego konta, a następnie przypisz Ewie decyzję. Porównaj oba wyniki z opisem ustawienia. Sam widok zapisanego suwaka nie pokaże, czy mechanizm odróżnia zdarzenia tak samo jak projekt.

Powtórz próbę dla różnych kanałów. Sprawdź także przypadek, w którym systemowe pozwolenie jest zablokowane, choć preferencja produktu została włączona. Osoba odbierająca projekt powinna odróżnić brak zapisanego wyboru od niedostępności urządzenia oraz od niepotwierdzonego dostarczenia. Nie wszystko, czego nie widać na telefonie, oznacza tę samą usterkę.

Przy zmianie reguły zajrzyj do wiadomości już oczekujących. Ewa może wyłączyć e-mail chwilę po powstaniu zdarzenia, a jeszcze przed wysyłką podsumowania. Uzgodnij, w którym momencie uwzględniana jest preferencja, i sprawdź wynik. Jeśli zmiana obejmuje dopiero przyszłe zdarzenia, informacja przy zapisie powinna to wyjaśnić, szczególnie gdy wcześniejsze wiadomości mogą jeszcze nadejść.

W Aeneia Design materiałem do pracy może być mapa zdarzeń oraz obecne ekrany ustawień. Pozwoli połączyć język z rzeczywistym zachowaniem. Ewa chce podjąć decyzję o publikacji bez czterdziestu osobnych powiadomień, że ktoś właśnie poprawił kolejny przecinek w podpisie.