Zmieniam pakiet. Co stanie się z moimi projektami?

„Od 1 grudnia: pakiet Mały. Dwa aktywne projekty. Twoje siedem dotychczasowych projektów pozostanie do odczytu”. Taki komunikat mówi więcej niż karta z sześcioma zielonymi haczykami. Jeszcze nie rozstrzyga wszystkiego: czy dwa wybrane projekty będzie można edytować, kto je wybiera i co stanie się z linkami wysłanymi klientom?

To propozycja komunikatu dla fikcyjnego portalu pracowni projektowej. Firma ogranicza pakiet po zakończeniu większego zlecenia. Ma już wykonane materiały, zaproszonych klientów i ustawione przypomnienia. Nie wybiera usługi od zera. Podejmuje decyzję o dalszej pracy na tym, co istnieje.

Projekt panelu zmiany powinien więc pokazać skutki dla tej konkretnej przestrzeni. Nazwa pakietu jest skrótem. Człowiek chce wiedzieć, czy jutro otworzy projekt, poprawi komentarz i odbierze odpowiedź klienta. Niższy pakiet nie powinien wymagać doktoratu z porównywania przypisów.

Porównuj obecny stan z przyszłym

Cennik usługi B2B pomaga rozpoznać zakres oferty. W panelu obecnego klienta sam cennik to za mało. Obok dostępnych możliwości trzeba pokazać, które z nich są używane i jak wpłynie na nie zmiana. „Mniej aktywnych projektów” pozostawia inne pytanie niż „masz siedem, a pakiet pozwala edytować dwa”.

Zacznij od skutków widocznych dla użytkownika: edycja, odczyt istniejących materiałów, tworzenie nowych i dalsze udostępnianie. Nie wrzucaj ich do jednego stanu „dostęp ograniczony”. Można oglądać projekt, ale nie dopisywać uwag; można nadal korzystać z działającej reguły, ale nie zmieniać jej ustawień.

Notion opisuje dla przejścia na Free istniejące automatyzacje działające dalej, lecz dostępne tylko do podglądu. Nie można ich wtedy edytować ani tworzyć nowych. To przykład rozdzielenia wykonania i edycji w konkretnym produkcie, a nie reguła, którą każdy portal powinien kopiować.

Slack wskazuje z kolei zatrzymanie istniejących workflow, czyli automatycznych przebiegów pracy, po przejściu na wersję bezpłatną. Nie będzie można tworzyć nowych. Podobna etykieta zmiany pakietu kryje więc inny skutek dla automatycznej pracy. Interfejs powinien pokazać decyzję własnego systemu.

W naszej pracowni zamiast rozbudowanej tabeli wszystkich funkcji najpierw pokaż trzy używane obszary: siedem projektów, linki dla czterech klientów i dwie reguły przypomnień. Przy każdym wskaż obecny oraz przyszły stan. Pełne porównanie pakietów nadal może być dostępne obok; podsumowanie skutków nie powinno zginąć wśród funkcji, z których firma nigdy nie korzystała.

Nie opisuj zachowanych materiałów słowem „bezpieczne”, jeśli ustalono jedynie możliwość ich odczytu. Powiedz, co będzie dostępne i przez jaką drogę. Czy można pobrać pliki? Czy działa historia? Czy dawne odnośniki prowadzą do tego samego widoku? Takie zdania da się porównać z działaniem produktu.

Siedem projektów i dwa miejsca do edycji

Przyjmijmy następującą regułę naszego przykładu: klient sam wybiera dwa projekty do dalszej edycji, a pozostałe pozostają do odczytu. To założenie projektowe, które właściciel usługi musiałby zatwierdzić przed wdrożeniem. Nie wynika z opisanych wyżej produktów.

Wybór powinien pokazywać nazwy projektów oraz ich obecny stan. Ustal, co liczy limit. Projekt zakończony, szkic i folder przeniesiony do archiwum mogą mieć różne znaczenie w usłudze. W naszym przykładzie miejsce zajmuje projekt wybrany do edycji, a nie każda historyczna pozycja. Pokaż to przy liczniku: „Wybrano 1 z 2 projektów do edycji”. Dzięki temu zamknięcie gotowej realizacji nie będzie wyglądało jak jej usunięcie tylko po to, by zwolnić miejsce.

Ktoś może chcieć zachować edycję małej, lecz wciąż trwającej realizacji, zamiast największego folderu. Automatyczne pozostawienie dwóch ostatnio otwieranych pozycji podjęłoby za niego decyzję, do której samo otwarcie pliku nie daje wystarczającej podstawy.

Przy każdej pozycji pokaż znaczenie wyboru: „Pozostanie do edycji” albo „Tylko odczyt po zmianie”. Nie wystarczy pole zaznaczenia bez wyjaśnienia, czy wybieramy elementy zachowywane, czy blokowane. Przy siedmiu projektach taki błąd da się jeszcze odkręcić w rozmowie. Przy kilkudziesięciu przestaje być zabawnym testem uważności.

Jeśli można później zamienić aktywny projekt, opisz tę możliwość przy wyborze. Jeżeli nie można, pokaż to przed zatwierdzeniem. Zasada musi być konkretna, bo wpływa na decyzję, czy ograniczyć pakiet już teraz. Nie pozostawiaj jej do odkrycia po pierwszym kliknięciu przycisku „Edytuj”.

Ograniczenie liczby współpracowników wymaga osobnego rozstrzygnięcia. Czy ktoś traci dostęp, czy tylko możliwość dopraszania następnych osób? Wybór aktywnych projektów nie powinien potajemnie wybierać także ludzi. Rozpisz te zależności i pokaż skutki przy zasobie lub osobie, której dotyczą.

Sama dyspozycja też ma wykonawcę. Osoba edytująca projekt nie musi mieć uprawnienia do zmiany pakietu całej firmy. Dla niej ekran może pokazać obecny zakres oraz drogę przekazania prośby właścicielowi przestrzeni. Nie opisuj wysłania takiej prośby jako zaplanowanej zmiany. Potwierdzenie powinno wskazywać, kto jeszcze podejmie decyzję. Właściciel z kolei potrzebuje widzieć, której przestrzeni dotyczy przycisk, zwłaszcza jeśli zarządza kilkoma klientami.

Przy udostępnianiu linku z określonym dostępem odbiorca potrzebuje rozpoznać zakres uprawnienia. Zmiana pakietu dodaje pytanie, czy ten zakres zostanie utrzymany. Jeśli odnośnik ma przestać działać, właściciel projektu powinien zobaczyć to przed zmianą, a klient później dostać zrozumiały stan zamiast błędu przypadkowej strony.

Dla projektu trwającego w chwili przejścia przygotuj również widok otwartego formularza komentarza. Pracownik może rozpocząć pisanie, zanim ograniczenie wejdzie w życie. Komunikat przy zapisie musi wyjaśnić, co przyjęto i co można zrobić z nieprzesłaną treścią. Nie chowaj utraty możliwości edycji pod ogólną awarią serwera.

Podobny przypadek dotyczy klienta zaproszonego do akceptacji. Jeśli pakiet blokuje jego odpowiedź od określonego terminu, informacja dla administratora nie wystarczy. Projekt potrzebuje odpowiedniego widoku również po stronie klienta, z nazwą realizacji i dalszą drogą kontaktu. Osoba z zewnątrz nie powinna dostawać zachęty do kupienia wyższego pakietu, którego nie może zmienić. To właściciel przestrzeni odpowiada za dostęp do swojego narzędzia.

Pauza ma własny zakres

Pauza bywa traktowana jak wielki przycisk zatrzymujący wszystko. W rzeczywistym produkcie trzeba ustalić, które działania zatrzymuje, a które pozostawia. Samo słowo nie mówi, czy klient widzi opublikowane materiały ani czy nadal przychodzą przypomnienia.

Shopify w opisie Pause and Build rozdziela dostęp do panelu i edycję produktów od wyłączonego checkoutu. Opisuje też zmianę zaplanowaną na koniec bieżącego cyklu, do której sklep może nadal działać normalnie. To konkretny przykład odróżnienia zlecenia pauzy od chwili jej skutku.

W portalu pracowni proponowana pauza może zatrzymać nowe projekty i automatyczne przypomnienia, pozostawiając odczyt archiwum. Napisz właśnie to, zamiast „Twoje konto będzie uśpione”. Użytkownik nie powinien zgadywać, czy archiwum też poszło spać i kto ma je rano obudzić.

Rozpisz wznowienie na tych samych zasobach. W naszym przykładzie trzeba zdecydować, czy zaległe przypomnienia zostaną wysłane, pominięte czy ponownie ustawione. Dla pracowni sensowna propozycja to pokazanie listy przeterminowanych przypomnień do przejrzenia przed uruchomieniem. Nie wysyłamy ich automatycznie w tym przykładzie. Klient, który dawno zaakceptował projekt inną drogą, nie powinien po miesiącu dostać uroczystego ponaglenia do zadania już zamkniętego. Ta zasada musi być potem widoczna przy powrocie do pracy.

Przy zamykaniu konta i przekazywaniu wspólnych projektów zapada inna decyzja. Nie używaj jednego przycisku „Zakończ” do pauzy, ograniczenia pakietu i usunięcia przestrzeni. Różnice powinny wynikać z nazw działań i opisanych skutków, a nie z kolejności trzech okien potwierdzenia.

Jeśli to firma kończy dostarczanie danej usługi, potrzebny jest proces wygaszania dla dotychczasowych klientów. Nie przedstawiaj wymuszonego końca jako dobrowolnego wyboru mniejszego pakietu. Właściciel portalu i klient podejmują tu różne decyzje, choć oba scenariusze mogą zmniejszyć zakres widoczny na ekranie.

Pokaż dwie daty, jeśli opisują dwa stany

Data przyjęcia dyspozycji nie musi być datą zmiany dostępu. W naszym przykładzie właściciel wybiera pakiet dziś, a nowy zakres zaczyna działać 1 grudnia. Do tego dnia panel powinien pokazywać obecny pakiet oraz zaplanowaną zmianę. Przemalowanie całego konta na „Mały” już po kliknięciu ukryłoby faktyczny stan.

Przy dyspozycji podaj moment wejścia zmiany zgodnie z regułą usługi. Gdy znaczenie ma godzina i strefa czasowa, uwzględnij je w potwierdzeniu. Nie dopowiadaj daty z samej etykiety cyklu, jeśli system przechowuje inny termin. Projekt powinien korzystać z tej samej potwierdzonej informacji, na podstawie której dostęp rzeczywiście się zmieni.

W dzienniku zmian produktu rozdzielamy zapowiedź i udostępnienie funkcji. Tutaj tę samą czytelność trzeba zachować przy decyzji klienta. Wiadomość „Zmiana zaplanowana” potwierdza inny wynik niż „Nowy pakiet jest aktywny”. W potwierdzeniu naszej dyspozycji pokaż także nazwy dwóch wybranych projektów i drogę powrotu do tego ustawienia. Sama data nie pozwoli zauważyć, że do edycji pozostawiono niewłaściwą realizację. Użytkownik powinien móc porównać zapisany wybór z tym, co przed chwilą zaznaczył.

Jeżeli użytkownik wróci przed terminem, pokaż mu nadal oczekującą dyspozycję. Jeśli może ją cofnąć, wskaż właściwe działanie i skutek cofnięcia. Jeśli wybierze kolejną zmianę, wyjaśnij, czy zastępuje ona poprzednią. Lista kilku jednocześnie wyglądających na aktywne poleceń nie jest historią, na której można oprzeć decyzję.

Przy braku potwierdzenia nie pokazuj od razu zachęty „Spróbuj zmienić ponownie”. Dyspozycja mogła zostać przyjęta mimo utraty odpowiedzi. Panel powinien najpierw pozwolić ustalić jej obecny stan, a dopiero potem dobrać dalszy krok. Po powrocie do ustawień człowiek ma zobaczyć rozpoznawalny stan: zmianę zaplanowaną, brak zmiany albo informację, że wyniku jeszcze nie potwierdzono. Każdy z tych komunikatów wymaga innego działania.

Projekt takiego panelu w Aeneia Design może objąć porównanie stanów, wybór zasobów i treść potwierdzeń. Do pracy nad ekranami potrzebne są najpierw rzeczywiste reguły usługi. Makieta nie ustanawia zasad zachowania danych ani terminu zmiany dostępu.

Po wdrożeniu próba powinna zacząć się od przestrzeni już używanej, z materiałami i udostępnieniami. Puste konto nie ujawni, który z siedmiu projektów zniknął z listy ani dlaczego klient stracił możliwość odpowiedzi. Przejdź przez zmianę przed terminem i po nim, także z dawnego linku.

Osoba testująca powinna móc własnymi słowami powiedzieć: kiedy zmieni się mój dostęp, co nadal otworzę i co muszę wybrać wcześniej. Dopiero potem niech zatwierdzi dyspozycję. Zrozumienie skutków jest lepszym warunkiem odbioru niż samo zauważenie nowej nazwy pakietu.