Jak wprowadzać nowe funkcje bez szkody dla lojalnych użytkowników?

„Bądź zwinny; zwolnij wcześnie; wypuszczaj często”. Znamy wiertło. Ale czy strategicznie mądre jest częste wprowadzanie funkcji? Zwłaszcza gdy tworzony produkt osiągnie określony rozmiar, prawdopodobnie nie chcesz ryzykować integralności swojej aplikacji z każdym nowym wydaniem pomocniczym.

Najgorsze, co może się przydarzyć Twojemu produktowi, to to, że lojalni użytkownicy, klienci, którzy konsekwentnie korzystają z tej jednej małej funkcji przez lata, nagle nie będą mogli jej używać w tak samo wygodny sposób. Zmiana może wzmocnić użytkowników, ale doświadczenie stanie się mniej proste. Frustracja i niepokój pojawiają się w mediach społecznościowych szybko i nagle, a presja na obsługę klienta, aby reagowała sensownie i na czas, rośnie z każdą minutą. Oczywiście nie chcemy wprowadzać nowych funkcji tylko po to, by zdać sobie sprawę, że w rzeczywistości szkodzą one lojalnym użytkownikom.

Dalsza lektura na SmashingMag: Link

• Jak zaczęliśmy wypuszczać funkcje dwa razy szybciej
• Lista kontrolna uruchamiania strony internetowej – 15 niezbędnych kontroli przed uruchomieniem
• Skoncentrowane na użytkowniku podejście do projektowania stron internetowych na urządzenia mobilne
• Jak cokolwiek uruchomić

Możemy temu zapobiec, bardziej strategicznie wdrażając nowe wersje naszych produktów. W tym artykule przyjrzymy się strategii dla projektantów produktów i inżynierów front-end, aby dokładnie przetestować i wdrożyć funkcję przed udostępnieniem jej dla całej bazy użytkowników, oraz jak uniknąć problemów związanych z UX.

Zanim zagłębimy się w rzeczywistą strategię testowania, cofnijmy się i przeanalizujmy powszechne błędne wyobrażenia dotyczące projektowania, budowania i ostatecznego wdrażania nowej funkcji.

Błędne wyobrażenia o nowej funkcji

Za każdym razem, gdy projektowana jest nowa funkcja dla istniejącego produktu, główny nacisk kładzie się zwykle na to, jak dokładnie powinna zostać zintegrowana z istniejącym interfejsem. Aby osiągnąć spójność, my, projektanci, często przyglądamy się istniejącym wzorom i stosujemy ustalony język projektowania, aby nowa funkcja dobrze pasowała do interfejsu użytkownika. Jednak często pojawiają się problemy nie dlatego, że komponenty nie współpracują ze sobą wizualnie, ale dlatego, że okazują się mylące lub niejednoznaczne po połączeniu w nieoczekiwany sposób .

Być może kopia interfejsu jest niejednoznaczna w powiązanych, ale odległych obszarach witryny lub wynik dwóch funkcji aktywnie używanych w tym samym czasie ma sens z technicznego punktu widzenia, ale nie odpowiada oczekiwaniom użytkownika lub ma poważne konsekwencje dla wydajności i szkodzi UX .

W rzeczywistości w projektowaniu to właśnie te liczne kombinacje są tak trudne do dokładnego przewidzenia i przeglądu. Jednym ze sposobów podejścia do problemu już w procesie projektowania jest rozważenie wartości odstających — przypadków użycia, w których istnieje większe prawdopodobieństwo, że coś pójdzie nie tak. Jak wyglądałby profil użytkownika, gdyby nazwa użytkownika była bardzo długa? Czy przegląd e-maili bez odpowiedzi jest nadal oczywisty, gdy używanych jest kilkanaście etykiet skrzynki odbiorczej? Czy nowy filtr miałby sens dla użytkowników, którzy właśnie się zarejestrowali i mają tylko kilka e-maili w skrzynce odbiorczej?

Projektowanie wartości odstających: stos interfejsów użytkownika

Jak dokładnie możemy zaprojektować wartości odstające po ich zidentyfikowaniu? Dobrą strategią jest badanie różnych stanów interfejsu użytkownika. „Stos interfejsów użytkownika”, pomysł wprowadzony przez Scotta Hurffa, jest wszechstronny i skomplikowany, a kiedy projektujemy nasze interfejsy, zwykle nie wystarczy stworzyć perfekcyjną makietę w Photoshopie, Sketchu lub HTML i CSS — musimy wziąć pod uwagę różne przypadki i stany brzegowe: stan pusty, stan obciążenia, stan częściowy, stan błędu i stan idealny. Nie są to tak proste, jak mogłoby się wydawać.

Pusty stan nie musi być pusty — moglibyśmy używać pracowników usług, aby zapewnić lepsze wrażenia offline zwykłym odwiedzającym. Stan częściowy nie musi być uszkodzony — możemy poprawić wrażenia z uszkodzonymi obrazami i uszkodzonym JavaScriptem poprzez progresywne ulepszanie.

Idealny stan może znacznie różnić się od naszych makiet „doskonałego wyniku” — ze względu na niestandardowe preferencje użytkownika i wybór przeglądarki użytkownika; niektóre treści i czcionki internetowe mogą nie być wyświetlane na przykład z powodu konfiguracji przeglądarki.

Tak więc krajobraz jest, jak zawsze, złożony, zawiły i nieprzewidywalny i nie możemy pomijać ryzyka, że ​​coś pójdzie nie tak, ale to nie znaczy, że nie możemy go skutecznie zminimalizować. Badając odstające elementy i cały stos interfejsów użytkownika na wczesnym etapie, możemy zapobiec typowym problemom z UX na wczesnym etapie projektowania. Jednak od strony technicznej nie jest łatwiej.

Efekt motyla we wdrożeniu

Nawet drobne zmiany prowadzą zwykle do reakcji łańcuchowych, wprowadzając błędy w obszarach i sytuacjach, które wydają się być całkowicie niepowiązane. Głównym tego powodem jest sama liczba zmiennych, które wpływają na wrażenia użytkownika, ale są poza naszą kontrolą. Znamy się na przeglądarkach, ale to nie znaczy, że wiemy więcej o kontekście, w jakim użytkownik postanawia zobaczyć witrynę, którą tak niestrudzenie i dokładnie przygotowaliśmy.

Teraz, chociaż drobne zmiany, takie jak dopełnienie przycisku lub stopniowo zwiększany obszar tekstowy, mogą nie wydawać się wielkim problemem, zwykle nie doceniamy wpływu tych błyszczących małych zmian lub funkcji na dużą skalę. Za każdym razem, gdy podejmujemy decyzję dotyczącą projektu lub rozwoju, ta zmiana ma jakiś wpływ na złożony system, który budujemy, głównie dlatego, że komponenty, które budujemy, nigdy nie istnieją w izolacji.

W rzeczywistości nigdy nie budujemy przycisku ani nie piszemy po prostu nowej funkcji JavaScript — przyciski i funkcje należą do rodziny komponentów lub bibliotek i wszystkie działają w określonym ustawieniu i są nieuchronnie połączone z innymi części systemu według ich właściwości lub zakresu, nazwy lub niepisanych konwencji zespołu.

Te „ciche”, ledwo zauważalne połączenia są powodem, dla którego wprowadzanie funkcji jest trudne, a przewidywanie dalekosiężnych konsekwencji zmiany często okazuje się ćwiczeniem bystrego wzroku. Dlatego dobrym pomysłem jest unikanie niepotrzebnych zależności tak dalece, jak to możliwe, czy to w CSS, czy JavaScript — nie pomogą one w utrzymaniu lub debugowaniu, zwłaszcza jeśli polegasz na bibliotece, której nie w pełni rozumiesz .

Na szczęście, aby lepiej zrozumieć wpływ zmiany, możemy skorzystać z zasobów, takich jak narzędzia programistyczne przeglądarki. Możemy zmierzyć zasięg selektora lub zasięg funkcji JavaScript, a czasami dobrym pomysłem może być powracanie do tego podczas tworzenia, aby zakres zmiany był możliwie lokalny i minimalny.

Jest to pomocne, ale to tylko część historii. Przyjmujemy założenia, świadomie i nieświadomie, w oparciu o własne doświadczenia z interfejsem i własne nawyki — często zapominając, że założenia mogą (i dlatego będą ) znacznie różnić się w zależności od użytkownika. Większość aplikacji ma tylko jeden interfejs, ale ten interfejs lub jego konfiguracje mogą mieć dziesiątki stanów — z widokami zmieniającymi się w zależności od ustawień i preferencji użytkownika.

Pomyśl o pulpitach nawigacyjnych z kartami, które można dostosować (oprogramowanie analityczne), klientach poczty z widokami „kompaktowym”, „wygodnym” i „szczegółowym” (Gmail), interfejsie rezerwacji, który zmienia się dla zalogowanych klientów i gości, wrażenia z czytania dla osób korzystających z narzędzia do blokowania reklam lub agresywnego filtra antywirusowego. Efekt motyla ma wpływ nie tylko na bazę kodu; wszystkie te czynniki zewnętrzne również mają znaczenie, a testowanie ich — w przeciwieństwie do testów jednostkowych lub ogólnie QA — jest bardzo trudne, ponieważ często nawet nie wiemy, przeciwko czemu testować.

Walidacja funkcji i lokalne maksimum

Możemy użyć diagnostyki i metryk, aby określić, jakie zmiany należy wprowadzić, ale śledząc tylko dane, możesz skończyć w stagnacji na tym, co zwykle nazywamy „lokalnym maksimum”, stanie interfejsu z wystarczająco dobrym projektem, ale tak całkowicie brakuje innowacji, ponieważ zawsze podąża za przewidywalnymi, logicznymi iteracjami. Pracując nad projektem i eksplorując dane, zwykle grupujemy funkcje w następujących czterech segmentach:

• Zepsute funkcje. . Funkcje, które wydają się być zepsute lub nieefektywne — oczywiście musimy je naprawić;
• Nieużywane funkcje. . Funkcje, które działają zgodnie z przeznaczeniem, ale są rzadko używane — często oznacza, że ​​należy je usunąć lub rozpaczliwie potrzebują innowacji;
• Nieoczekiwane funkcje użytkowania. . Funkcje, które są używane w sposób skrajnie odmienny od tego, co pierwotnie wyobrażali sobie ich twórcy — dobry kandydat do powolnego, ciągłego udoskonalania;
• Funkcje konia roboczego. . Funkcje, które są często używane i wydają się działać zgodnie z planem — w takim przypadku zadajemy sobie pytanie, czy istnieje sposób na dalsze ulepszenie ich UX poprzez równoległe badanie zarówno powolnego procesu iteracyjnego, jak i zupełnie innych innowacyjnych koncepcji.

Pierwsze dwa segmenty mają kluczowe znaczenie dla utrzymania funkcjonalności i użyteczności interfejsu, podczas gdy dwa ostatnie mają kluczowe znaczenie dla utrzymania zaangażowania i zadowolenia użytkowników. W idealnym przypadku chcemy osiągnąć oba cele jednocześnie, ale przewagę mają ograniczenia czasowe, budżetowe i zespołowe.

Jednak po wybraniu nowej iteracji lub nowego pomysłu może być kuszące, aby od razu rozpocząć projektowanie lub tworzenie nowej funkcji. Ale zanim jeszcze pomyślisz o tym, jak dana funkcja będzie pasować do istniejącego interfejsu, dobrą strategią jest najpierw zweryfikować pomysł — za pomocą szybkiego prototypu i badań użytkowników. Typowym sposobem na osiągnięcie tego jest użycie szybkiego procesu iteracyjnego, takiego jak sprint projektowy Google Ventures. Wykonując iterację w ciągu kilku dni, możesz określić, jak nowa funkcja powinna zostać zaimplementowana i/lub czy jest przydatna w sposób, w jaki początkowo sobie wyobrażałeś.

Dzięki sprintom projektowym wcześnie poddajemy pomysł badaniu użyteczności. W metodologii Google Ventures testowałbyś projekt z pięcioma użytkownikami dziennie; następnie iterowałbyś i przechodził kolejną rundę testowania nowego projektu. Powodem, dla którego zaangażowani są wszyscy ci sami użytkownicy, jest to, że jeśli tego dnia przetestujesz inny projekt z każdym użytkownikiem, nie będziesz mieć prawidłowych danych, aby wiedzieć, które elementy powinny się zmienić. Potrzebujesz kilku użytkowników, aby zweryfikować jedną iterację projektu.

W naszych sprintach stosujemy nieco inny model. Kiedy zaczynamy pracę nad nową funkcją, po zbudowaniu wczesnego prototypu, zbieramy projektantów, programistów i zespół UX w tym samym pomieszczeniu, zapraszamy prawdziwych użytkowników do testowania, a następnie wykonujemy iteracje w napiętym harmonogramie. Pierwszego dnia pierwsi testerzy (od dwóch do trzech osób) mogą umówić się na 30-minutową rozmowę o godzinie 9:00, druga grupa o 11:00, następna o 14:00, a ostatnia jeden około 16:00. Pomiędzy wywiadami z użytkownikami mamy „otwarte okna czasowe”, kiedy faktycznie iterujemy projekt i prototyp, aż w pewnym momencie mamy coś realnego.

Powodem tego jest to, że na początku chcemy szybko zbadać zupełnie inne, czasem nawet przeciwne kierunki; gdy zbierzemy opinie na temat różnych interfejsów, możemy zbliżyć się do interfejsu, który wydaje się być „absolutnym maksimum” . W ten sposób możemy szybciej uzyskać bardzo zróżnicowane opinie na temat bardzo zróżnicowanych iteracji projektowych. Informacje zwrotne opierają się głównie na trzech czynnikach: mapach cieplnych, które rejestrują kliknięcia użytkownika, czasie potrzebnym użytkownikom na wykonanie zadania i tym, jak zachwycające jest dla nich doświadczenie. W dalszej części tygodnia konsekwentnie współpracujemy z większą liczbą użytkowników, podobnie jak Google, stale weryfikując nowy projekt na bieżąco.

Jak dotąd jest dobrze, ale czasami pozornie innowacyjna nowa funkcja koliduje z istniejącą funkcją, a posiadanie ich obu w tym samym interfejsie zaśmieca projekt. W tym przypadku sprawdzamy, czy jedną z opcji można uznać za rozszerzenie drugiej. Jeśli tak, to zaczynamy od powtórzenia jego funkcjonalności i wyglądu. Wtedy musimy wybrać radykalne przeprojektowanie lub stopniową zmianę. Ta ostatnia jest mniej ryzykowna i zachowa znajomy wzorzec interakcji dla użytkowników, podczas gdy ta pierwsza jest wymagana, jeśli krytyczne zmiany są niemożliwe do osiągnięcia w inny sposób lub jeśli korzyści ze zmian przyrostowych byłyby zbyt płytkie.

W obu przypadkach ważne jest, aby skupić się na całym doświadczeniu użytkownika produktu, a nie na wartości pojedynczej funkcji tego produktu. A kiedy już wybierzesz tę funkcję i zaprojektujesz i zbudujesz pierwszy prototyp, nadszedł czas na testy.

Osiem poziomów testowania

Jak więc skutecznie zapobiegać przedostawaniu się błędów i awarii do rzeczywistego środowiska na żywo? Ile sprawdzeń, recenzji i testów przeprowadzamy przed wdrożeniem funkcji? A w jakiej kolejności przeprowadzamy te testy? Innymi słowy, jak wyglądałaby ostateczna strategia wdrażania funkcji?

Jedną z lepszych strategii wdrażania funkcji zaproponował Andrew Sumin, szef rozwoju w Mail.ru, głównym dostawcy poczty e-mail w Rosji. Strategia nie miałaby zastosowania do każdego projektu, ale jest to rozsądne i kompleksowe podejście dla firm obsługujących średnie i duże produkty tysiącom klientów.

Przyjrzyjmy się szczegółowo strategii i omówmy osiem kroków wdrażania funkcji, obejmujących proces rozwoju produktu Mail.ru:

1. test z programistami,
2. test z prawdziwymi użytkownikami w kontrolowanym środowisku,
3. test z użytkownikami z całej firmy,
4. test z beta testerami,
5. przetestuj z użytkownikami, którzy ręcznie się zgadzają,
6. split-test i sprawdzanie retencji,
7. uwalniać powoli i stopniowo,
8. zmierzyć następstwa.

W przypadku Mail.ru najważniejsza cecha, która ma pozostać nienaruszona, bez względu na to, co tworzy wiadomość (oczywiście). To najczęściej używany element interfejsu, a pozwolenie na jego niedostępność lub nieprawidłowe działanie nawet przez kilka sekund byłoby absolutnie wykluczone. A co, gdybyśmy chcieli rozszerzyć funkcjonalność obszaru tekstowego, na przykład dodając kilka inteligentnych funkcji autouzupełniania, licznik lub podgląd boczny?

1. Testuj z programistami

Im więcej czasu mija w rozwoju, tym droższe staje się rozwiązanie problemu. Ponownie zastanów się, jak powiązane są wszystkie decyzje w rozwoju produktu; im bardziej wyrafinowany jest produkt, tym więcej decyzji trzeba cofnąć, co kosztuje czas i zasoby. Tak więc identyfikowanie i rozwiązywanie problemów na wczesnym etapie zarówno z perspektywy biznesowej, jak i perspektywy projektowania i rozwoju.

Nie można jednak debugować pomysłu, więc wstępne testy powinny odbywać się podczas produkcji, na pierwszych prototypach. Zatem pierwszymi testerami na Mail.ru są programiści, którzy faktycznie piszą kod. Firma zachęca swoich pracowników do korzystania z produktu do komunikacji wewnętrznej (a nawet prywatnej); więc deweloperzy mogą być uważani za zagorzałych użytkowników produktu.

Pierwszy krok jest dość oczywisty: zaprojektuj i zbuduj funkcję, a następnie przetestuj ją lokalnie, przejrzyj i wdroż na serwerze pomostowym. W tym miejscu pojawia się testowanie jakości, z kompleksowymi narzędziami i programami do uruchamiania zadań, które próbują awarię funkcji i interfejsu, potencjalnie zautomatyzowane za pomocą narzędzi do testowania małp, takich jak Gremlins.js.

Wyniki są monitorowane, a następnie przesyłane z powrotem do pętli sprzężenia zwrotnego dla następnej iteracji funkcji. W pewnym momencie programiści poczują się całkiem pewnie z kompilacją: wydaje się, że zmiana działa zgodnie z oczekiwaniami, a wymagania zostały spełnione. Wtedy zaczyna się testowanie z prawdziwymi użytkownikami.

2. Testuj z prawdziwymi użytkownikami w kontrolowanym środowisku

Kiedy pierwszy działający prototyp jest gotowy, funkcja jest testowana z rzeczywistymi użytkownikami podczas wywiadów. Klienci są zapraszani do wykonywania zadań, a gdy to robią, zespół UX monitoruje ślepe uliczki i pojawiające się problemy i rozwiązuje je na miejscu.

Jednak testowana jest nie tylko nowa funkcja; celem testu użyteczności jest upewnienie się, że nowa funkcja nie wpływa na krytyczne elementy interfejsu, dlatego użytkownicy wykonują rutynowe zadania, takie jak tworzenie wiadomości i otwieranie, odpowiadanie i przeglądanie wiadomości e-mail w swojej skrzynce odbiorczej. Jeśli zarówno nowa, jak i stara funkcja są dobrze zrozumiane, proces może iść dalej.

3. Testuj z użytkownikami w całej firmie

Oczywiście informacje zwrotne z testu użyteczności skłaniają programistów do wprowadzenia zmian, które następnie są przesyłane z powrotem do testerów użyteczności, przechodząc tam iz powrotem, aż wynik wydaje się mieć wartość dla większej liczby odbiorców. Następnym krokiem jest zatem wyeksponowanie funkcji w firmie: do całej firmy wysyłany jest e-mail zachęcający wszystkich współpracowników do sprawdzenia funkcji i przesyłania raportów, błędów i sugestii w narzędziu do śledzenia.

W przypadku testowania nie ma szczególnie dużej różnicy między użytkownikami w „odległych” działach w firmie a użytkownikami w środowisku naturalnym. Nawet użytkownicy wewnętrzni nie wiedzą, jakich zmian się spodziewać, ani nie wiedzą dokładnie, jak działa dana funkcja lub jak ma działać lub wyglądać. Jedyną główną różnicą jest to, że współpracownicy mogą zostać poproszeni o szybkie przesłanie opinii lub pozostawienie komentarza. Wtedy wprowadzane są formy głosowania. Testerzy mogą nie tylko bawić się tą funkcją, ale także dodawać komentarz i głosować za lub przeciw. Głosowanie należy porównać ze strategią produktu i wymaganiami biznesowymi, ale jeśli użytkownicy wyraźnie uznają, że funkcja jest bezużyteczna lub pomocna, jest to prosty i skuteczny sposób na zebranie opinii i sprawdzenie, czy produkt działa zgodnie z oczekiwaniami.

4. Testuj z beta testerami

Jeśli funkcja przeszła kontrolę techniczną, kontrolę użyteczności i przegląd w firmie, kolejnym logicznym krokiem jest przedstawienie jej niektórym segmentom odbiorców. Jednak zamiast udostępniać ją losowemu segmentowi użytkowników, zespół przesyła funkcję do sprawdzenia wśród beta testerów — użytkowników, którzy zdecydowali się na udział w testach i przesyłają opinie na temat funkcji eksperymentalnych. Mogą głosować przeciwko lub za funkcją, a także zgłaszać błędy i zatwierdzać fragmenty kodu.

Ale jak wybrać odpowiednich beta-testerów? Cóż, jeśli chcesz zachęcić testerów do łamania interfejsu, możesz skupić się na zaawansowanych lojalnych użytkownikach z umiejętnościami technicznymi — użytkownikach, którzy w razie potrzeby byliby w stanie podać szczegóły techniczne dotyczące błędu, oraz użytkownikach, którzy znają istniejący interfejs na tyle dobrze, że w stanie przewidzieć problemy, które mogą mieć inni użytkownicy.

Potrzebujesz jednak kryteriów, aby określić, czy użytkownik jest wystarczająco zaawansowany, aby zostać beta testerem. W przypadku klienta pocztowego może to być ktoś, kto używa przeglądarki Chrome lub Firefox (tzn. wie, jak zmienić domyślną przeglądarkę), utworzył więcej niż trzy foldery w swojej skrzynce odbiorczej i zainstalował również aplikację mobilną.

5. Przetestuj z użytkownikami, którzy zgłosili się ręcznie

Do tego momentu testy obejmowały możliwą do opanowania liczbę użytkowników, konfiguracji i raportów z testów. Jednak różnorodność użytkowników, systemów i konfiguracji na wolności, w tym systemu operacyjnego, przeglądarki, wtyczek, ustawień sieciowych, oprogramowania antywirusowego i innych aplikacji instalowanych lokalnie, może być nieco bardziej zniechęcająca w skali.

W przypadku Mail.ru następnym krokiem jest wdrożenie tej funkcji w interfejsie na żywo, za flagą i wysłanie wiadomości e-mail do tego większego segmentu aktywnych użytkowników, prezentując nową funkcję i zapraszając ich do jej aktywacji na swoim własne w interfejsie, zwykle z błyszczącym przyciskiem „Aktualizuj”. Aby zmierzyć wartość funkcji dla rzeczywistych użytkowników, zespół ponownie używa systemu głosowania, z kilkoma podpowiedziami tu i tam, zasadniczo pytając użytkowników, czy uważają tę funkcję za pomocną lub użyteczną. Zauważ, że różnica między tym poziomem a poprzednim polega na tym, że ręczna akceptacja dotyczy znacznie większej liczby odbiorców — wielu z nich nie ma w ogóle wiedzy technicznej, w przeciwieństwie do beta-testerów.

Tak więc czas i koordynacja mają znaczenie . Prawdopodobnie nie wybrałbyś losowego dnia na wysłanie e-maila do aktywnych użytkowników, ponieważ chcesz, aby zespół obsługi klienta i programiści byli dostępni, gdy zacznie napływać strumień raportów o błędach. Dlatego e-mail jest wysyłany na początek tygodnia, kiedy wszyscy (lub większość) programistów są dostępni, a zespół wsparcia jest gotowy do działania, po odprawie i aktywnym połączeniu z programistami przez Skype lub Slack. W mniejszej firmie programiści mogliby siedzieć przez kilka godzin przy stanowiskach pomocy technicznej, aby szybciej dotrzeć do sedna problemu, rozmawiając bezpośrednio z klientami.

6. Test dzielony i sprawdzanie retencji

W dotychczasowych krokach, z wyjątkiem testów użyteczności, wszyscy testerzy korzystali z nowej funkcji dobrowolnie. Jeśli jednak włączysz tę funkcję domyślnie, nagle użytkownicy będą musieli z niej korzystać, a jest to zupełnie inny rodzaj grupy, której w ogóle nie testowaliśmy.

Aby mieć pewność, że nie złamiesz nawyków pasywnych użytkowników, możesz przeprowadzić test dzielony z trzema małymi segmentami użytkowników i zmierzyć retencję . W końcu chcesz się upewnić, że nowa wersja działa przynajmniej tak samo dobrze jak poprzednia. Zidentyfikuj najważniejszą aktywność w interfejsie i zmierz nie tylko czas, jaki użytkownicy spędzają na niej przed i po wdrożeniu, ale także ile czasu mija do ich powrotu. W przypadku Mail.ru retencja obejmuje sprawdzanie przez użytkowników poczty e-mail i tworzenie wiadomości. Im częściej użytkownik wraca, tym wyższa retencja, która jest wskaźnikiem lepszego UX.

Każdy segment otrzymuje nieco inny widok , co pozwala nam później przetestować, jak wyświetlić nową funkcję wszystkim użytkownikom. Do pierwszego segmentu dodajemy nową funkcję i zapewniamy samouczek, jak z niej korzystać. W drugim segmencie po prostu dodajemy nową funkcję. W przypadku trzeciego segmentu możemy pozostawić tę funkcję bez zmian. Dla wszystkich tych segmentów możemy wprowadzić zmianę w tym samym czasie, wybrać rozsądny przedział czasowy na przeprowadzenie testu, zmierzyć retencję, a następnie porównać wyniki. Im wyższa retencja segmentu, tym większe prawdopodobieństwo, że projekt będzie później promowany wśród wszystkich użytkowników.

7. Uwalniaj powoli i stopniowo

Jeśli jakaś funkcja dotarła do tego momentu, prawdopodobnie już działa dobrze dla dużej części odbiorców. Wtedy możesz stopniowo udostępniać go wszystkim użytkownikom — z monitem o głosowanie w celu zebrania opinii. Jeśli opinie są w większości pozytywne, możesz dalej wprowadzać tę funkcję i ostatecznie stanie się ona integralną częścią interfejsu. W przeciwnym razie oceniłbyś opinię i wrócił do laboratorium na następną iterację.

Wdrożenie tej funkcji nie wystarczy: należy ją przekazać użytkownikom. Popularnym sposobem na to jest e-mail i media społecznościowe. Mimo to krótki samouczek wyjaśniający wartość tej funkcji w rzeczywistych scenariuszach może być również pomocny. Nie zapomnij też zintegrować pola sugestii, aby natychmiast zebrać opinie.

8. Zmierz następstwa

Po wdrożeniu funkcji możemy monitorować jej działanie i wypróbowywać różne metody, aby zwrócić na nią uwagę, aby użytkownicy mogli wykonywać swoje zadania wydajniej. Możesz śledzić najczęstsze zadania lub najczęściej odwiedzane strony, a następnie wyświetlić niewielką notatkę w treści, zalecającą użytkownikowi nieco mądrzejszy i szybszy sposób osiągnięcia celu, a następnie zmierzyć, czy użytkownik woli tę nową funkcję, czy zwykłą metodę.

Nie zapomnij przekazać opinii całemu zespołowi, nie tylko programistom czy projektantom, aby byli zmotywowani i zaangażowani oraz aby zobaczyć, jak ludzie korzystają z funkcji, która początkowo była tylko szorstkim pomysłem. Nie ma nic bardziej motywującego niż obserwowanie szczęśliwych, zachwyconych ludzi korzystających z aplikacji dokładnie tak, jak sobie wyobrażałeś lub na zupełnie inne sposoby. Wspomoże również rozwój kolejnych cech zespołu.

Proces recenzji wygląda na złożony i dokładny, ale czasami tylko czas i szeroka sieć testów użytkowników pozwolą odkryć problem. Na przykład, jeśli zmiana wpływa na wygląd wiadomości przychodzących, żaden test jednostkowy nie może ujawnić trudności, jakie mogą napotkać użytkownicy oprogramowania wspomagającego. W interfejsie pocztowym, co urządzenie ułatwień dostępu ma odczytywać jako pierwsze: datę, nadawcę, temat czy samą wiadomość? Sposób, w jaki zmienisz kolejność kolumn w przeglądzie, może zmienić sposób, w jaki użytkownicy zdecydują się uzyskać dostęp do informacji; więc umożliwienie im wyłączenia nowej funkcji również byłoby krytyczne.

Wniosek

Jak więc wygląda strategia wdrażania? Możesz zacząć od zbadania wykresu zależności, aby zrozumieć, jak daleko idąca może być Twoja zmiana. Następnie możesz przetestować tę funkcję z programistami i prawdziwymi użytkownikami w kontrolowanym środowisku. Następnie możesz poprosić współpracowników o przejrzenie funkcji przed wysłaniem jej do wybranej grupy testerów wersji beta. Na koniec możesz udostępnić tę funkcję jako opcję dla użytkowników. A przed włączeniem tej funkcji dla wszystkich można przeprowadzić test podziału, aby znaleźć najlepszy sposób wprowadzenia tej funkcji, a następnie zmierzyć współczynniki przechowywania dla krytycznych zadań.

Oczywiście wdrożenie nie jest procesem liniowym . W trakcie całego procesu może być konieczne cofnięcie się o dwa kroki, aby przejść o jeden krok do przodu — aż w końcu będziesz mieć kandydata do wydania. Opisany powyżej przepływ pracy może wydawać się dość powolny i niezbyt zwinny, ale drastycznie minimalizujesz ryzyko, że użytkownicy nagle staną przed nieoczekiwanym problemem i w rezultacie uzyskają gorsze wrażenia. W niektórych sytuacjach może to być bardzo tego warte.