Sztuka upraszczania złożoności w projektowaniu produktów – wnioski z prezentacji Pedro w GitLab – #EN46

TL;DR:

• Experience rot (degradacja doświadczenia) to zjawisko, gdy produkt z czasem staje się bardziej złożony i mniej przyjazny poprzez ciągłe dodawanie funkcji
• Model KANO pomaga zrozumieć, co użytkownicy naprawdę cenią, dzieląc funkcje na podstawowe oczekiwania, elementy wydajnościowe i generatory ekscytacji
• Sophisticated simplicity (wyrafinowana prostota) to ideał projektowy będący przeciwieństwem naiwnej prostoty i wyrafinowanej złożoności
• Osiągnięcie wyrafinowanej prostoty wymaga głębokiego zrozumienia problemów użytkowników i skupienia się na ich podstawowych potrzebach
• W GitLab złożoność wynika z tego, że produkt zastępuje dziesiątki wyspecjalizowanych narzędzi i obsługuje wielu różnych użytkowników
• Należy pytać, czy dana funkcja musi być widoczna dla wszystkich, czy wspiera odkrywanie zaawansowanych możliwości, i co by się stało, gdyby ją usunąć
• Przejście z koncentracji na funkcjach do koncentracji na problemach użytkowników (UX roadmaps) to klucz do upraszczania złożoności

Problem złożoności w nowoczesnych produktach

Jak zauważył Pedro na początku swojej prezentacji, upraszczanie złożoności w GitLab to pytanie, które jest na ustach wszystkich praktycznie każdego dnia. Nie jest to problem unikalny dla GitLab – podobne wyzwania dotyczą wielu firm rozwijających zaawansowane produkty cyfrowe, jak np. Outsystems, platforma low-code, z którą Pedro niedawno rozmawiał.

Pedro, który pracuje w GitLab od prawie siedmiu lat jako projektant produktu i jest opiekunem systemu projektowego Pajamas, miał okazję uczestniczyć w warsztatach z Jaredem Spoolem i Daną Chisnell, ekspertami UX. Podczas tych warsztatów koncentrowano się na pytaniu: „Jak możemy zainspirować naszą organizację do wyjścia poza błyszczące funkcje, oferując produkty i usługi, które zapewniają wyjątkową satysfakcję?”

Experience rot – kiedy produkty stają się gorsze z czasem

Jedną z kluczowych koncepcji, którą Pedro przedstawił, jest „experience rot” (degradacja doświadczenia) wprowadzona przez Jareda Spoola. To zjawisko zachodzi, gdy produkty stopniowo dodają coraz więcej funkcji, próbując przewyższyć oczekiwania użytkowników i pokonać konkurencję. Problem polega na tym, że wiele z tych funkcji nie jest faktycznie niezbędnych dla użytkowników lub nie zostało uwzględnionych w pierwotnym projekcie.

„Więcej funkcji oznacza większą złożoność i gorsze doświadczenie. Jednym z efektów ubocznych degradacji doświadczenia jest to, że złożoność zwiększa koszty utrzymania i skalowania produktu.”

Jak wyjaśnił Pedro, cytując Jareda, degradacja doświadczenia nie tylko utrudnia projektowanie i rozwój, ale stawia całą organizację w sytuacji ryzyka.

Model KANO – zrozumienie wartości dla użytkowników

Aby lepiej zrozumieć degradację doświadczenia w praktyce, Pedro przedstawił model KANO, opracowany w Japonii w latach 80. przez profesora Noriakiego Kano. Model ten analizuje, jak różne firmy wydają pieniądze i jaki jest wynikający z tego poziom satysfakcji klientów.

Model KANO identyfikuje kilka kategorii inwestycji produktowych:

1. Performance payoffs (korzyści wydajnościowe) – „lepsze, ale bardziej złożone”. Im więcej inwestujesz, tym bardziej zadowoleni stają się klienci. Problemem jest to, że musisz stale inwestować, by uzyskać więcej satysfakcji, a produkt staje się coraz bardziej złożony.
2. Basic expectations (podstawowe oczekiwania) – to rzeczy, których klienci naturalnie się spodziewają i których nawet nie muszą wspominać. Przykładem w GitLab jest edytowanie pliku przez interfejs webowy bez konieczności klonowania repozytorium na lokalną maszynę.
3. Excitement generators (generatory ekscytacji) – aspekty produktu, które wykraczają poza podstawowe oczekiwania i zachwycają klientów. Może to być zrobione poprzez dużą inwestycję w „magiczną funkcję”, ale częściej mała inwestycja może przynieść nieoczekiwaną radość.

Pedro podkreślił, że w GitLab zwykle inwestuje się w „korzyści wydajnościowe” (performance payoffs), co może prowadzić do degradacji doświadczenia.

Dlaczego złożoność jest wyzwaniem dla GitLab?

Pedro szczegółowo wyjaśnił, dlaczego złożoność jest szczególnym wyzwaniem dla GitLab:

1. GitLab jako pojedyncza aplikacja – w przeciwieństwie do wcześniejszych faz DevOps, gdzie używano różnych narzędzi dla każdej części cyklu życia, GitLab oferuje wszystkie funkcje zintegrowane bezproblemowo.
2. Szeroki zakres funkcji – produkt ma osiem etapów i ponad 50 kategorii, zastępując dziesiątki wyspecjalizowanych narzędzi i konsolidując setki funkcji w jednym doświadczeniu.
3. Open Core i strategia Development Span – strategia open core umożliwia innowacje zarówno ze strony GitLab, jak i szerszej społeczności. Każdego kwartału setki ulepszeń są wnoszone przez klientów i użytkowników.
4. Obsługa wielu person – niektóre etapy GitLab obsługują 8, 11, a nawet 15 różnych person jednocześnie.
5. Strategia „Seed, then nurture” – GitLab wdraża małe MVP i funkcje, które są niekompletne, by pozwolić innym zobaczyć ich kierunek i wnieść wkład. To podejście wywiera presję na zespoły, by były bardzo celowe w „zasiewaniu” funkcji i miały czas i odwagę, by w razie potrzeby je usunąć.

Sophisticated simplicity – droga do wyrafinowanej prostoty

Jedną z najważniejszych koncepcji, które Pedro przedstawił, jest „sophisticated simplicity” (wyrafinowana prostota). Termin ten został ukuty przez Marcela Weyera po przestudiowaniu pracy Steve’a Jobsa i Roberta Heinleina.

Istnieją trzy poziomy:

1. Naive simplicity (naiwna prostota) – pierwsza próba rozwiązania problemu. Jest to proste rozwiązanie, ponieważ nie rozumiesz w pełni problemu.
2. Sophisticated complexity (wyrafinowana złożoność) – gdy zaczynasz rozumieć, jak skomplikowany jest problem, rozwiązanie staje się znacznie bardziej złożone.
3. Sophisticated simplicity (wyrafinowana prostota) – osiągana tylko wtedy, gdy poświęcasz się zrozumieniu podstawowych zasad problemu. Rozwiązanie jest teraz wyrafinowane, ale nie złożone. Jest proste, ale nie podstawowe.

Pedro podkreślił, że w projektowaniu w GitLab przeszli od naiwnej prostoty do wyrafinowanej złożoności i codziennie dążą do wyrafinowanej prostoty.

Praktyczne wskazówki do walki ze złożonością

Pedro przedstawił praktyczne wskazówki, jak walczyć ze złożonością:

1. Zrozumienie użytkowników jest kluczowe – Jobs-to-be-done (zadania do wykonania) i badania KANO mówią, co użytkownicy próbują osiągnąć i co cenią.
2. Szukaj możliwości przycinania doświadczenia – usuń nieużywane funkcje. Pedro zachęca zespoły do rozważenia, które funkcje w ich obszarze są najmniej używane.
3. Przejdź od funkcji do problemów – dzięki mapom drogowym UX i tematom przechodzimy od zobowiązania do funkcji do zobowiązania do problemów.
4. Zadaj sobie kluczowe pytania:
   • Czy ta treść lub funkcjonalność musi być widoczna cały czas i dla wszystkich?
   • Czy struktura wspiera odkrywanie i korzystanie z zaawansowanych możliwości?
   • Czy ta funkcja jest w ogóle potrzebna lub używana? Co by się stało, gdyby ją usunąć?

Dyskusja: walka ze złożonością w praktyce

Po prezentacji odbyła się interesująca dyskusja, podczas której uczestnicy dzielili się swoimi doświadczeniami i wyzwaniami:

• Zmagania z 'głośną mniejszością’ – jak radzić sobie z żądaniami pojedynczych użytkowników, które mogą zwiększyć złożoność produktu?
• Równoważenie potrzeb nowych i doświadczonych użytkowników – Pedro sugeruje, że należy zrozumieć typowy poziom wiedzy danej persony i projektować dla tego poziomu.
• Technologiczne ograniczenia prostoty – czasami architektura techniczna uniemożliwia proste rozwiązania UI, jak w przypadku zmiany ustawień YAML przez interfejs przeglądu MR.
• Napięcie między biznesem a UX – jak równoważyć potrzeby biznesowe (np. funkcje żądane przez dużych klientów) z potrzebą uproszczenia produktu?

Podsumowanie

Jak podkreślił Pedro, walka ze złożonością to ciągłe wyzwanie. Nie chodzi o to, by mieć wszystkie odpowiedzi, ale by świadomie podejmować decyzje o tym, co dodajemy do produktu i jak to wpływa na doświadczenie użytkownika.

„Innovation is saying no to a thousand things” – Steve Jobs

Osiągnięcie wyrafinowanej prostoty wymaga głębokiego zrozumienia problemów, skupienia się na podstawowych elementach i odwagi, by mówić „nie” wielu pomysłom, nawet jeśli są technicznie wykonalne.

Artykuł powstał na podstawie prezentacji Pedro, pracownika GitLab, wygłoszonej podczas UX Showcase 6 września 2023 roku.

Jest częścią mojej nowej serii, w której dzielę się najważniejszymi informacjami z interesujących prezentacji i podcastów, które zawierają treści warte zapamiętania i powrotu w przyszłości.