Zamknij konto — ale co z projektami całego zespołu?

Przycisk „Usuń konto” zajmuje niewiele miejsca. Jego znaczenie może się jednak rozciągać od jednej osoby do całej pracowni. Czy zniknie możliwość logowania? Członkostwo w zespole? Projekty, które założyła ta osoba? A może wspólna przestrzeń, do której jutro wróci pięciu współpracowników? Czerwony kolor nie odpowiada na żadne z tych pytań. Potrafi jedynie podnieść ciśnienie jeszcze przed wyborem.

Dobry projekt zakończenia dostępu zaczyna się od nazwania operacji i jej zakresu. Dopiero potem dobiera ostrzeżenie, potwierdzenie oraz dalszą drogę. Nie chodzi o zatrzymanie użytkownika za wszelką cenę. Człowiek powinien móc odejść, rozumiejąc, co zostawia zespołowi i co rzeczywiście przestaje działać.

Prześledźmy hipotetyczny portal do uzgadniania projektów opakowań. Marta kończy współpracę z pracownią, ma własne konto i należy do dwóch zespołów. W jednym jest jedyną osobą z rolą właściciela. Wspólne projekty mają komentarze klienta, pliki i terminy. To fikcyjny przykład projektowy, nie opis działania wdrożonego portalu ani obietnica jego funkcji.

Najpierw rzeczownik, potem ostrzeżenie

„Konto” bywa wygodnym skrótem dla projektanta i pułapką dla odbiorcy. Jeżeli jedna tożsamość daje dostęp do kilku zespołów, opuszczenie jednego z nich nie musi wymagać usunięcia tej tożsamości. Na ekranie trzeba pokazać nazwę zespołu, rolę osoby i skutek wybranej czynności. W innym miejscu można udostępnić zamknięcie całego konta.

W naszym portalu Marta wybiera „Opuść zespół Drukarnia”. Otrzymuje informację, że jej członkostwo w tym zespole zakończy się, a konto nadal da dostęp do drugiej pracowni. Nie powinna zobaczyć ogólnego „Twoje konto zostanie usunięte”. Gdy wybiera trwałe zamknięcie konta, zakres jest szerszy i wymaga pokazania obu przynależności.

Slack opisuje dezaktywację konta oddzielnie dla każdej przestrzeni i zaznacza, że wysłane wiadomości oraz pliki nie zostaną przez nią usunięte. To zachowanie konkretnej usługi. Pokazuje, dlaczego koniec dostępu osoby i los jej wkładu trzeba nazwać osobno, zamiast ukrywać oba pod słowem „konto”.

Przygotuj rozróżnienia w modelu własnego produktu: konto osoby, członkostwo w zespole, własność projektu i cała przestrzeń. Nie muszą być czterema sąsiadującymi czerwonymi przyciskami. Mogą należeć do różnych ekranów i ról. Opis oraz potwierdzenie powinny odnosić się do tej samej rzeczy, którą system rzeczywiście zmieni. „Opuść Studio” i „Usuń przestrzeń Studio wraz z projektami” nie mogą prowadzić do identycznego okna z pytaniem „Czy na pewno?”. Osoba musi rozpoznać różnicę także wtedy, gdy otworzy ten ekran z dawnego odnośnika, bez wcześniejszej wizyty w ustawieniach.

W procedurze odejścia pracownika i przekazania dostępów zespół ustala odpowiedzialności także poza jednym narzędziem. Samoobsługowy ekran nie zastąpi tej pracy. Może natomiast pokazać zależności rozpoznawane przez portal, zanim Marta potwierdzi zakończenie dostępu.

Nie mieszaj tej drogi z blokadą po moderacji i prośbą o ponowną ocenę. Osoba pozbawiona możliwości publikowania nie powinna otrzymać komunikatu sugerującego, że dobrowolnie zamknęła konto. Potrzebuje informacji o właściwym stanie oraz dostępnej drodze wyjaśnienia. Powód ograniczenia należy do modelu komunikacji, nie tylko do technicznej listy kodów błędu.

Współpraca ma pozostać wykonalna

W drugim zespole Marta jest jedynym właścicielem. Przycisk wyjścia nie powinien prowadzić do pustego „Operacja niemożliwa”. Pokaż konkretną zależność: „Jesteś jedyną właścicielką zespołu Studio. Przekaż tę rolę, aby opuścić zespół”. Dalszy krok ma prowadzić do wyboru uprawnionej osoby, nie do ogólnej strony pomocy.

GitHub wymaga od jedynego właściciela organizacji rozwiązania kwestii jej własności przed usunięciem osobistego konta. Rozróżnia też zasoby należące do osoby od wypowiedzi w cudzych repozytoriach. Nie przenosimy całej tej reguły do portalu opakowań; potrzebujemy własnej decyzji o każdym rodzaju zasobu.

Przekazanie roli jest osobną czynnością. Jeżeli system wymaga akceptacji odbiorcy, wysłane zaproszenie oznacza oczekiwanie, a nie zakończony transfer. Jeżeli rola zmienia się od razu, komunikat powinien pokazać faktyczną zmianę. Marta musi wiedzieć, czy może już odejść, a nowy właściciel — co otrzymał.

Nie przekazuj roli osobie wybranej tylko z listy adresów e-mail. W naszym przykładzie odbiorca ma już należeć do właściwego zespołu i spełniać wymagania tej roli. Jeśli najpierw trzeba go zaprosić, pokaż tę zależność. Wysłanie zaproszenia do współpracy, dołączenie do zespołu i uzyskanie roli właściciela to kolejne stany, które mogą zakończyć się w różnym momencie.

Instrukcja przekazania organizacji GitHub zaleca nadanie roli nowej osobie i upewnienie się, że potrafi wejść do ustawień organizacji. To przydatny przykład potwierdzenia zdolności do działania. Samo pojawienie się nazwiska na liście nie wystarcza jako opis przejęcia odpowiedzialności.

W fikcyjnym portalu warto przejść przypadek, w którym wybrana osoba straciła uprawnienia, zanim zakończono przekazanie. Lista sprzed kilku minut nie może bezwarunkowo rozstrzygać obecnego stanu. Pokaż, co się zmieniło i jak ponowić wybór. Nie kończ członkostwa Marty, jeśli wymagany warunek pozostał niespełniony.

Sprawdź także projekty przypisane do konkretnej osoby. Jeżeli Marta przerwie porządkowanie po przekazaniu jednego z trzech projektów, powrót powinien pokazać dwa pozostałe oraz wynik wcześniejszej zmiany. Wymaganie rozpoczęcia całego procesu od nowa może skłonić ją do ponownego przekazania tego samego zasobu. Lista ma opisywać obecne zależności, a nie odtwarzać pierwszy widok niezależnie od wykonanych działań. „Właściciel zespołu” i „osoba akceptująca projekt dla klienta” mogą być różnymi rolami. Przekazanie pierwszej nie musi zmienić drugiej. Ekran zależności powinien odróżnić te przypadki i wskazać zadania, które wymagają decyzji, zamiast obiecywać automatyczne naprawienie wszystkich powiązań.

W projekcie Aeneia Design taki przebieg można rozrysować jako stany ekranów i przejścia między nimi: wyjście, zależność, przekazanie oraz wynik. Pozwala to omawiać zakres z wykonawcą na konkretnych sytuacjach, zanim czerwony przycisk otrzyma swoje ostateczne położenie.

Co Marta ma przeczytać przed potwierdzeniem

Ostatni ekran powinien opisywać wybraną operację. W naszym przykładzie przy opuszczeniu Studia pokazuje jego nazwę, utratę dostępu do wspólnych projektów i informację o ich dalszej dostępności dla pozostałych osób. Przy zamknięciu konta potrzebny jest szerszy zakres, obejmujący wszystkie rozpoznane przynależności. Nie dopisuj jednego zdania „dotyczy wszystkiego” do komunikatu o jednym zespole.

Zależności warto pokazać w postaci konkretnych pozycji. Projekt „Pudełko A” czeka na przekazanie osoby akceptującej. Projekt „Etykieta B” ma już nowego opiekuna. Nie wystarczy wspólna etykieta „Masz aktywne projekty”, jeśli po kliknięciu użytkownik nadal nie wie, który wymaga działania i jak je wykonać.

Osobno rozstrzygnij prywatne szkice. Przekazanie wspólnego projektu nie powinno po cichu udostępnić osobistych notatek, których autor nigdy nie dołączył do zespołu. Ekran może pokazać podział „materiały wspólne” i „prywatne szkice” oraz właściwe dostępne działania. W projektowaniu potrzebna jest mapa rzeczywistych praw do obiektów, nie tylko licznik plików przypisanych do nazwiska.

Treść potwierdzenia ma odpowiadać sposobowi wykonania. Jeśli zamknięcie jest natychmiastowe i nieodwracalne, nie obiecuj późniejszego powrotu przyciskiem w mailu. Jeśli istnieje odroczenie lub możliwość anulowania, podaj właściwy moment i drogę. Odróżnij rezygnację przed zleceniem od anulowania już zaplanowanej operacji.

Atlassian opisuje dla samodzielnego usunięcia konta czternastodniowy okres, w którym można anulować zlecenie. Po jego zakończeniu usunięcie jest trwałe. To właściwość opisanej usługi i typu konta, nie termin do automatycznego wklejenia do dowolnego portalu. Nasz ekran musi wynikać z własnego procesu.

Wpisanie nazwy zespołu może być sposobem dodatkowego potwierdzenia szczególnie poważnej operacji, lecz nie zastąpi opisu skutku. Człowiek potrafi bezbłędnie przepisać „Studio” i nadal sądzić, że usuwa tylko własny dostęp. Najpierw trzeba wyjaśnić różnicę, a potem dobrać uzasadniony poziom potwierdzenia. Nie każde wyjście z pojedynczego projektu wymaga takiej samej ceremonii.

Powód rezygnacji może pomóc rozwijać usługę, ale nie powinien przysłonić samej decyzji. Jeżeli pytanie jest dobrowolne, pokaż możliwość pominięcia. Pauza lub zmiana pakietu może być trafną alternatywą, gdy odpowiada potrzebie. Nie umieszczaj jej tak, by właściwego zamknięcia nie dało się odnaleźć. Samo otwarcie ekranu nie powinno zmieniać ról. Jeżeli jednak Marta zdążyła już osobno przekazać projekt, rezygnacja z zamknięcia konta nie może ukrywać tego faktu. Przy powrocie do pracy pokaż aktualny stan: konto pozostało aktywne, a wcześniej zatwierdzone przekazania nadal obowiązują według zasad portalu.

Po kliknięciu potrzebny jest prawdziwy stan

Wysłane żądanie nie zawsze oznacza wykonanie. Jeżeli operacja czeka, ekran powinien to powiedzieć oraz wskazać konto lub nazwę zespołu, którego dotyczy. Gdy kończy się błędem, Marta ma wiedzieć, czy nadal należy do zespołu. Ogólne wylogowanie po utracie połączenia może wyglądać jak sukces, mimo że niczego nie zmieniono.

Gdy potwierdzenie nie dotarło, a sieć jest niedostępna, komunikat powinien uczciwie wskazać brak potwierdzenia. Sprawdzenie wyniku nastąpi dopiero po odzyskaniu kontaktu z usługą. Nie zachęcaj do kolejnego zlecenia jako jedynego sposobu wyjścia z niepewności. Projekt stanu oczekiwania ma przewidywać ustalenie wyniku poprzedniej operacji, a wykonawca powinien potwierdzić, jak system rozpoznaje jej powtórzenie.

Przy zakończonym wyjściu nie zostawiaj otwartego edytora sprawiającego wrażenie, że można nadal zapisywać. Inna karta przeglądarki może pozostać na dawnym widoku. Projekt powinien przewidzieć odmowę dalszego zapisu, wyjaśnienie zmiany dostępu i bezpieczną drogę do aktualnego stanu. To nie oznacza samoistnej gwarancji technicznego odwołania wszystkich sesji; jej wykonanie wymaga osobnego sprawdzenia.

Los materiałów opisz według potwierdzonych zasad. Retencja i usuwanie kopii danych obejmują więcej niż widok profilu. Zniknięcie awatara nie uzasadnia komunikatu „wszystkie dane zostały usunięte”, jeśli operacja nie ma takiego zakresu. Wątpliwości o obowiązki i prawa do danych wymagają właściwego rozstrzygnięcia poza samym projektem ekranu.

Nie łącz także zamknięcia osobistego konta z wycofaniem całej usługi dla klientów. W pierwszym przypadku pozostali użytkownicy mogą dalej pracować. W drugim zmienia się ich wspólna droga. Nazwa operacji, komunikaty i kontakt powinny odpowiadać temu, która sytuacja rzeczywiście występuje.

Po zamknięciu konta droga wyjaśnienia nie może wymagać zalogowania do tego samego konta. Wskaż kanał odpowiadający faktycznej obsłudze oraz sposób identyfikacji sprawy. Wiadomość potwierdzająca nie musi zawierać nazw wszystkich poufnych projektów. Może potwierdzać zakres operacji i pozwalać odnieść się do niej bez rozsyłania zawartości zespołu poza portal.

Do odbioru wybierz próbę z dwiema osobami i wspólnym projektem. Jedna odchodzi po poprawnym przekazaniu roli. Druga nadal otwiera projekt i wykonuje przewidziane zadanie. Osoba odchodząca widzi potwierdzenie właściwego zakresu. W protokole zapisz osobno wynik dla odchodzącej osoby i dla pozostającego zespołu. Przycisk można odebrać dopiero wtedy, gdy zakończył właściwy dostęp, a projekt pozostał dostępny zgodnie z ustaloną decyzją.