Zaproszenie już przyszło. Dlaczego trafiam do niewłaściwego konta?

„Nie możesz przyjąć tego zaproszenia”. To dość chłodne powitanie kogoś, kogo przed chwilą zaprosiliśmy. Zwłaszcza gdy wiadomość przyszła na właściwy adres, przycisk wyglądał zachęcająco, a na ekranie nikt nie wyjaśnia, że przeglądarka pamięta inne konto. Użytkownik próbuje jeszcze raz. Zapraszający wysyła kolejną wiadomość. Po chwili mają już dwa linki i ten sam problem.

Zaproszenie jest propozycją konkretnego dostępu: dla osoby, do organizacji, w określonej roli. Nie jest zwykłą rejestracją ani odnośnikiem do strony głównej. Projekt powinien zachować te zależności od wysłania wiadomości do rozpoznawalnego wyniku. Dotyczy to także odbiorcy, który jest już zalogowany, ale nie tak, jak przewiduje zaproszenie.

Przyjmijmy fikcyjny portal współpracy pracowni Obrys z podwykonawcami. Administratorka zaprasza Tomasza do projektu katalogu. Używa jego służbowego adresu, a Tomasz ma otwarte prywatne konto w tym samym portalu. Nie zakładamy, że oba konta można automatycznie połączyć. Musimy najpierw pokazać mu, które konto właśnie działa i jak wrócić do zaproszenia po jego zmianie.

Wiadomość zaprasza do konkretnej relacji

Jeszcze przed kliknięciem Tomasz powinien rozpoznać nadawcę, organizację oraz cel. „Dołącz do nas” jest za mało precyzyjne, gdy współpracuje z kilkoma pracowniami. Wiadomość może powiedzieć, że Obrys zaprasza do współpracy przy katalogu, a przyjęcie otworzy wskazaną przestrzeń. Zakres ujawnianych szczegółów trzeba dopasować do charakteru projektu oraz zasad dostępu.

Rolę opisz przez możliwości istotne dla odbiorcy. „Współpracownik” może oznaczać oglądanie materiałów albo ich poprawianie. Jeśli zaproszenie pozwala dodawać fotografie, lecz nie zatwierdzać publikacji, warto to nazwać przed decyzją. Nie trzeba wklejać całej technicznej listy uprawnień. Trzeba wyjaśnić, do jakiej pracy zapraszamy Tomasza.

Rozróżnienie użytkownika, nabywcy i płatnika przydaje się również tutaj. Osoba przyjmująca zaproszenie nie zawsze zamawia usługę ani odpowiada za rozliczenie. Ekran nie powinien sugerować jej zakupu planu tylko dlatego, że w organizacji brakuje miejsca lub zapraszający wybrał niewłaściwą rolę. Taki problem może wymagać działania administratorki.

Przygotuj również odpowiedź dla osoby, która mówi: „Nie znam tej organizacji”. Odbiorca powinien móc zrezygnować lub znaleźć kontakt do wyjaśnienia sytuacji. Nie zmuszaj go do przyjęcia zaproszenia, aby dopiero w środku dowiedział się, kogo ma zapytać. Nadawca i cel mają być rozpoznawalne przed tym krokiem.

Zalogowanie nie rozstrzyga, komu przyznajemy dostęp

Pierwszy ekran po otwarciu linku powinien rozpoznać sytuację Tomasza. Jeśli nie jest zalogowany, prowadzi do odpowiedniej metody wejścia. Jeśli jest, pokazuje konto używane do przyjęcia zaproszenia. Powitanie samym imieniem „Tomasz” niczego nie rozstrzyga, kiedy oba konta mają takie samo imię i fotografię.

GitHub opisuje konkretną regułę zaproszeń do organizacji: przy zaproszeniu przez e-mail adres musi odpowiadać potwierdzonemu adresowi osobistego konta odbiorcy. Instrukcja nie dotyczy kont zarządzanych Enterprise Managed Users.

Nasz portal może mieć inny model. Projektant potrzebuje go poznać, zanim przygotuje komunikat „adresy się nie zgadzają”. Czy liczy się podstawowy adres konta, także dodatkowy potwierdzony adres, czy tożsamość konkretnego dostawcy logowania? Podobnie wyglądające e-maile nie stanowią same w sobie reguły łączenia kont. Komunikat powinien wynikać z faktycznego mechanizmu.

W wariancie z niewłaściwym kontem pokaż Tomaszowi obecną tożsamość i jasną czynność: „Zmień konto, aby przyjąć zaproszenie”. Jeśli ujawnienie pełnego zaproszonego adresu jest dopuszczone dopiero po dodatkowym potwierdzeniu, przygotuj odpowiedni wariant. Zakres pokazanych danych uzgodnij z osobą odpowiedzialną za dostęp do zaproszeń.

Zmiana konta nie powinna oznaczać utraty celu. Po logowaniu Tomasz ma wrócić do tej samej propozycji współpracy, a nie do pustego pulpitu z prośbą o odnalezienie wiadomości. To przypomina powrót po wygaśnięciu sesji, ale zachowywanym elementem jest tu zaproszenie oraz jego aktualny stan. Nie kopiujemy po prostu dowolnego wcześniejszego formularza.

Dokumentacja Microsoft Entra B2B opisuje wybór konta, gdy nazwa logowania pasuje jednocześnie do konta organizacyjnego Entra i osobistego konta Microsoft. Pokazuje też, że przebieg przyjęcia zależy od skonfigurowanych dostawców tożsamości.

To użyteczne rozróżnienie dla rozmowy z wykonawcą. Sam przycisk „Zaloguj przez…” nie musi wyjaśniać, którego profilu dostawcy używa Tomasz. Projekt logowania kluczem dostępu również oddziela metodę wejścia od konta, które otwiera. Zaproszenie powinno zachować to rozróżnienie także po udanym potwierdzeniu tożsamości.

W trakcie tej drogi Tomasz może mieć niezapisaną pracę na prywatnym koncie. Nie zaskakuj go nagłym wylogowaniem wszystkich kart. Ustal zakres zmiany i pokaż potrzebną informację przed opuszczeniem pracy. Jeżeli portal pozwala wybrać inne konto tylko w osobnym przebiegu, opisz tę drogę konkretnie. Instrukcja nie może brzmieć jak zalecenie usunięcia całej historii przeglądarki z powodu jednego zaproszenia.

Wybór konta może potrwać. W tym czasie administratorka wycofa zaproszenie albo zmieni proponowaną rolę. Przed ostatecznym przyjęciem ekran powinien odtworzyć aktualne warunki. Jeżeli Tomasz oglądał możliwość edycji, a teraz ma otrzymać tylko podgląd, nie wystarczy po cichu zmienić małego napisu. Pokaż nowy zakres i pozwól zdecydować na jego podstawie. Widok sprzed logowania nie dowodzi aktualności propozycji.

Link może być poprawny, ale zaproszenie już nieaktualne

Tomasz otwiera wiadomość po urlopie. Zamiast przycisku przyjęcia widzi informację o wygaśnięciu. Powinna ona odróżnić utratę ważności od braku dostępu na używanym koncie oraz od wycofania propozycji przez administratorkę. Te stany wymagają różnych dalszych działań. Ogólne „Błąd” nie podpowiada, czy zmienić konto, czy poprosić o nowe zaproszenie.

W standardowej instrukcji GitHub oczekujące zaproszenie wygasa po siedmiu dniach. Właściciel organizacji może ponowić albo anulować wygasłe zaproszenie. To reguła tego produktu, a nie zalecany termin dla każdego portalu.

Dla Obrysu czas ważności wynika z uzgodnionych zasad. W wiadomości pokaż konkretny termin wraz ze zrozumiałym odniesieniem do czasu. Po wygaśnięciu daj dostępną drogę: prośbę o nowe zaproszenie albo kontakt z osobą, która może je wysłać. Przycisk „Wyślij ponownie” jest uczciwy tylko wtedy, gdy odbiorca rzeczywiście może uruchomić tę czynność.

Prośba o ponowienie nie jest jeszcze nowym zaproszeniem. Tomasz powinien odróżnić przyjęcie swojej prośby od potwierdzenia wysłania wiadomości. Administratorka może potrzebować sprawdzić adres lub zakres współpracy. Jeśli nowe zaproszenie już istnieje, ekran powinien pomóc znaleźć aktualną drogę zamiast nakłaniać do tworzenia kolejnych.

Zaplanuj też otwarcie starego linku po ponowieniu. Czy poprzednia propozycja została zastąpiona, czy nadal jest ważna? To decyzja mechanizmu zaproszeń, ale jej wynik musi mieć własny komunikat. W naszym przykładzie wycofany link nie przyznaje dostępu. Tomasz dostaje informację, że powinien skorzystać z aktualnej wiadomości, bez sugerowania, że ma zakładać nowe konto.

Jeśli portal oferuje odmowę, rozstrzygnij również jej skutek. Tomasz może nie chcieć udziału w tym katalogu, choć nadal współpracuje z Obrysem przy innym. Etykieta „Odrzuć zaproszenie do katalogu” nie powinna oznaczać opuszczenia całej organizacji. Po potwierdzeniu pokaż, czego dotyczyła decyzja. Administratorka potrzebuje odróżnić świadomą odmowę od zaproszenia, na które nikt jeszcze nie odpowiedział.

Inaczej wygląda link użyty już skutecznie. Jeśli Tomasz wróci do niego z właściwego konta, można wskazać istniejącą współpracę i przejście do projektu. Nie trzeba odgrywać przyjęcia po raz drugi. Jeżeli używa innego konta, samo wcześniejsze przyjęcie przez uprawnioną osobę nie powinno otwierać projektu temu nowemu profilowi.

Administratorka też potrzebuje prawdziwego wyniku

Wysłanie wiadomości nie oznacza, że Tomasz dołączył. Lista zaproszeń powinna odróżniać oczekiwanie, potwierdzone przyjęcie i stan wymagający działania. Nie zastępuj tych informacji jednym zielonym statusem „Gotowe”. Status powinien nazywać potwierdzone zdarzenie: utworzenie zaproszenia, przekazanie wiadomości do wysyłki albo dołączenie osoby do organizacji.

Potwierdzenie ma zawierać rozpoznawalną osobę, organizację i uzgodnioną rolę. Jeżeli konto Tomasza używa innej nazwy niż adres wpisany podczas zapraszania, przedstaw wynik tak, żeby dało się rozpoznać związek bez ręcznego śledztwa. Nie dopisuj jednak „przeczytano”, jeśli system potrafi potwierdzić tylko przyjęcie.

Przy poprawianiu literówki w adresie nie udawaj, że nic się nie zmieniło. Administratorka musi wiedzieć, czy modyfikuje istniejące zaproszenie, wycofuje je i tworzy następne, czy poprawia wyłącznie dane kontaktowe już istniejącej osoby. Te działania mają inne skutki dla wysłanych linków. Zwykła etykieta „Edytuj” nie powinna ukrywać zmiany odbiorcy dostępu.

Na liście zaproszeń przyda się również rozpoznawalna data i zakres ostatniej czynności. Po ponowieniu wiadomości pokaż wynik tej próby obok wcześniejszej informacji o utworzeniu zaproszenia. W razie błędu wysyłki zachowany rekord może nadal istnieć. Zespół powinien wiedzieć, czy poprawia adres, ponawia komunikację, czy tworzy propozycję dostępu od początku. Tę różnicę sprawdź w widoku odbiorcy po kolejnej wiadomości.

Gdy Tomasz ma już dostęp, próba ponownego zaproszenia powinna ujawnić tę sytuację. Może potrzebna jest zmiana roli, dołączenie do innego projektu lub tylko przesłanie drogi wejścia. To trzy inne decyzje niż utworzenie członkostwa. Rozpoznanie istniejącej relacji zapobiega mnożeniu kont i oczekujących propozycji tej samej pracy.

Slack wyjaśnia, że ten sam e-mail może służyć w wielu przestrzeniach, ale konta tych przestrzeni pozostają osobne. Samo podobieństwo adresu nie przesądza więc o wspólnym koncie produktu.

Przy przełączaniu firm w portalu powraca ta sama praktyczna potrzeba: użytkownik ma rozpoznać miejsce, do którego właśnie wszedł. Po przyjęciu pokaż nazwę Obrysu oraz projekt katalogu. Nie kończ na ogólnym „Sukces”, po którym Tomasz nadal nie wie, gdzie pracować.

Pierwsze zadanie jest lepszym finałem niż konfetti

Potwierdzenie przyjęcia może prowadzić do wskazanego materiału albo wyjaśniać, na co Tomasz jeszcze czeka. Jeśli administratorka musi osobno udostępnić projekt, członkostwo w organizacji nie powinno udawać gotowości do edycji katalogu. Pusta strona z zachętą „utwórz swój pierwszy projekt” byłaby w tej sytuacji szczególnie nietrafna: zaprosiliśmy człowieka do cudzej, już rozpoczętej pracy.

W pierwszym użyciu narzędzia liczy się zadanie osoby, nie obowiązkowa wycieczka po interfejsie. Tomasz może potrzebować otworzyć fotografie i dodać jedną uwagę. Ten konkretny cel warto zachować przez logowanie, zmianę konta i potwierdzenie dostępu. Długie wprowadzenie nie naprawi zgubionej relacji z projektem.

Przy odbiorze użyj dwóch kont o wyraźnie różnych adresach oraz zaproszenia do przygotowanej organizacji. Przejdź najpierw niewłaściwym kontem, zmień je i sprawdź wynik również po stronie administratorki. Osobno otwórz zaproszenie wycofane, wygasłe i wcześniej przyjęte. Każda próba ma skończyć się rozpoznaniem stanu, bez zakładania następnego konta na wszelki wypadek.

W Aeneia Design można opracować ekrany, wiadomości i przejścia potrzebne do takiego przyjęcia współpracy. Zaproszenie spełni swój cel, kiedy Tomasz znajdzie właściwy katalog pod właściwym kontem, a administratorka zobaczy potwierdzony dostęp. Wtedy „miło cię widzieć” nie będzie już wymagało instrukcji odzyskiwania konta.