TL;DR:

Prawdziwy delight to przekraczanie oczekiwań, nie tylko animacje i konfetti
Zespoły inżynierskie powinny być częścią procesu projektowego, nie etapem przekazania
Jakość w oprogramowaniu można sprzedawać jak produkty fizyczne – używaj analogii
Inwestuj w momenty mundane, które mają wysoką częstotliwość użycia
Framework „eigen questions” pomaga rozwiązywać złożone problemy projektowe
Proces iteracyjny z codziennymi wersjami może prowadzić do nieoczekiwanych rozwiązań
Delight powinien antycypować potrzeby użytkowników, nie tylko je celebrować

Ten artykuł zawiera notatki z rozmowy Jenny Wen, original designer FigJam, przeprowadzonej w podcaście Dive Club. Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą bezpośrednio od rozmówców i są oparte na ich doświadczeniach przy tworzeniu jednego z najpopularniejszych narzędzi do współpracy.

Premiera FigJam – wybór między funkcjonalnością a unikalną wartością

Jenny Wen wspomina moment Config 2021, kiedy FigJam debiutował publicznie. Zespół stanął wtedy przed dylematem: gonić parytet funkcjonalny czy stworzyć coś unikalnego.

Według Wen, nie miało sensu próbować dorównać konkurencji od razu. Zamiast tego zespół skoncentrował się na podstawowych elementach – kształty, sticky notes, tekst. Jednak do tego dodali funkcje, które tworzyły unikalną tożsamość: cursor chat i emotes.

„Zamiast wypełniania istniejących checkboxów, stworzyliśmy własne checkboxy” – wyjaśnia Wen. Nikt inny nie miał cursor chat w narzędziach do whiteboardingu.

Po premierze zespół otrzymał konkretne opinie o brakujących podstawowych funkcjach. Użytkownicy chcieli możliwości zmiany rozmiaru sticky notes (co początkowo nie było dostępne) czy lepszych podstawowych mechanik. Mimo to zespół już wcześniej przygotował listę kolejnych funkcji jak timer i voting – narzędzia do spotkań, które czyniły współpracę bardziej efektywną.

Ta strategia pozwoliła uniknąć pułapki landing pages z listami porównawczymi. W rezultacie FigJam od startu miał swój własny measuring stick.

Walka o tożsamość marki – odrzucenie paska narzędzi przed wydaniem

Wen ujawnia ważne wyzwanie projektowe: napięcie między marką Figma a unikalną tożsamością FigJam.

Początkowo zespół zaprojektował pasek narzędzi prawie identyczny jak Figma – ta sama architektura informacji, jednak z fioletowym podświetlonym aktywnym narzędziem zamiast niebieskiego. Myśleli wtedy, że „powinno się czuć jak część Figma”.

Kilka miesięcy przed wydaniem zespół zdecydował się odrzucić cały pasek narzędzi. Chcieli bowiem stworzyć coś, co na pierwszy rzut oka krzyczało „to jest FigJam, nie jakiś inny whiteboard tool, nie Figma”.

Dziś mają wyzwanie z przeciwnej strony: jak pokazać, że FigJam to potężne narzędzie (zaawansowane diagramy, widgets, plugins), zachowując jednocześnie prostą i przystępną markę? Powierzchnia wygląda zabawnie, ale jednym kliknięciem można wygenerować złożoną tabelę przez AI.

Proces projektowy: inżynieria jako część kreacji

Wen opisuje nietypowe podejście do współpracy z inżynierami. W większości zespołów zmiany w kodzie po przekazaniu to „wyrzucona praca”. Natomiast w FigJam inżynieria traktowana jest jako część procesu projektowego.

Designerzy komunikują: „to kierunek, w którym jesteśmy najbardziej pewni, ale nie jesteśmy w 100% pewni”. Dlatego inżynierowie budują pierwszą wersję z oczekiwaniem, że może się zmienić.

Studium przypadku cursor chat pokazuje siłę tego podejścia. Jenny, Emily (PM), Carl i Ryan (inżynierowie) iterowali codziennie. Każdego dnia powstawała nowa wersja, następowało testowanie w prawdziwych spotkaniach, szybka rozmowa czteroosobowego zespołu, a także natychmiastowe prototypowanie kolejnej iteracji.

Proces był chaotyczny i pełen eksperymentów. Wen wspomina, że na jednym z etapów testowano pomysł, w którym wpisanie słowa „poop” powodowało pojawienie się na tablicy odpowiedniej emotikony. Chociaż funkcja ostatecznie wygląda inaczej, ten przykład pokazuje kulturę swobodnego prototypowania.

Wen wspomina: „Każdego dnia było prawie jak nowa wersja do testowania. Dotarliśmy do punktu końcowego, którego nie spodziewaliśmy się na starcie.”

Framework „eigen questions” oraz spektrum eksploracji projektowych

Wen wykorzystuje koncepcję „eigen questions” z artykułu CEO Coda, Shashira. To pytania, które po rozwiązaniu odblokują odpowiedzi na wszystkie inne pytania.

Proces „eigen questions” w praktyce:

Krok 1: Wyrzucenie wszystkich myśli na papier

Wypisz duże pytania strategiczne (np. „jaki związek między produktami?”)
Dodaj małe pytania operacyjne (np. „jak manipulować tekst?”)
Bądź wyczerpujący – lepiej za dużo niż za mało

Krok 2: Identyfikacja eigen questions

Które pytania otworzą wszystkie pozostałe?
Które decyzje będą miały najwięcej efektów domina?
Które obszary są najbardziej niepewne i blokujące?

Krok 3: Działanie mimo niepewności

Stwórz makiety 1-2 opcji zamiast paraliżu analizy
Wybierz „strawman” – opcję, w którą wierzysz najbardziej
Zacznij testować i iterować, nawet jeśli nie jest idealna

Wen wprowadza dodatkowy element: podejście spektrum do eksploracji projektowych. Zawsze myśli o eksploracjach projektowych w ramach spektrum – dwa ekstremalne bieguny, podczas gdy odpowiedź prawie nigdy nie jest na przeciwnych biegunach.

Przykład: „jak zabawny i ekspresyjny powinien być FigJam?” Jeden biegun to ultra-utylitarny, drugi to przesadnie ekspresyjny. Odpowiedź jest zawsze gdzieś w środku, ale forsowanie skrajności pokazuje, co mogłoby być możliwe.

„Zawsze mam 'strawman’ – jedną opcję, w którą wierzę najbardziej, nawet jeśli nie będzie finalna” – tłumaczy Wen.

Komunikowanie jakości oprogramowania przez analogie do świata fizycznego

Wen zauważa, że łatwo rozmawiamy o jakości produktów fizycznych (sweter z kaszmiru vs poliestr), jednak w oprogramowaniu brakuje nam tego języka.

Jej rada: nie mów tylko „potrzebujemy wyższej jakości”. Zamiast tego połącz jakość z celami biznesowymi firmy.

Przykład bankowości ilustruje tę zasadę: kiedyś wybieraliśmy bank na podstawie obsługi w oddziale. Obecnie jakość aplikacji definiuje, któremu bankowi zaufamy nasze pieniądze. Dla banku to nie będzie mikrointerakcja, ale zaufanie w transferze pieniędzy. Z kolei dla designerskiego narzędzia to płynność interfejsu i dopracowanie detali.

Wen podkreśla: „Jakość wygląda inaczej w zależności od klienta, produktu i tego, co jest dla nich wartościowe”.

Delight beyond confetti – nowe podejście do zachwytu

Według Wen, delight to momenty przekraczania oczekiwań, nie tylko sparkle i animacje.

Prawdziwy zachwyt ilustruje porównaniem do obsługi w doskonałej restauracji: upuszczasz widelec, a zanim zdążysz się po niego schylić, kelner już podaje ci nowy. Chodzi o to, by produkt w podobny sposób antycypował potrzeby, dając użytkownikowi poczucie bycia pod dobrą opieką.

Tradycyjne podejście zakłada dodawanie delight w momentach celebracji (konfetti po ukończeniu zadania). Problem polega na tym, że to już oczekiwane – każdy tak robi.

Wen proponuje skupienie na momentach mundane o wysokiej częstotliwości. Przykład Andy’ego Allena z Not Boring apps – możliwość „flick” temperatury w aplikacji pogodowej podczas jazdy metrem.

„Prawdziwy delight to antycypowanie potrzeb użytkownika i rozwiązywanie ich w nieoczekiwany sposób” – wyjaśnia Wen.

Kluczowe pytania dla projektowania delight:

W jakich momentach użytkownik jest zdenerwowany lub niepewny?
Jak możemy służyć lepiej niż oczekują?
Gdzie możemy być jak dobry kelner, który podaje widelec zanim go poprosisz?
Czy to rozwiązuje prawdziwy problem w nieoczekiwany sposób?
Czy ktoś napisałby o tym tweet „oh my gosh”?

Najbardziej zachwycające momenty zawsze zaczynają się od designera myślącego „what if?” – pokazują coś poza zakresem, ale rozwiązującego potrzeby użytkownika lepiej niż oczekiwano.

Mierzenie delight – testimoniale zamiast standardowych metryk

Wen przyznaje, że tradycyjne testy A/B nie działają przy mierzeniu skuteczności zachwycających funkcji.

„Zachwycające momenty to te, o których słyszymy najwięcej na Twitterze, od znajomych znajomych” – zauważa. Reakcja na prawdziwy delight charakteryzuje się silnymi, ekspresyjnymi emocjami typu „oh my gosh”.

Wen proponuje ćwiczenie „tweet brainstorm” – zamiast tradycyjnego Amazon press release, zespół pisze mock tweety reakcji użytkowników. 280 znaków zmusza do destylacji emocjonalnej esencji funkcji i pomaga zidentyfikować, czy coś stanie się viralne.

Prowadzenie efektywnych brainstormów

Wen dzieli praktyczne rady z prowadzenia sesji w FigJam:

Rozpoczęcie od icebreaker: Nawet głupie pytanie („ulubiony rodzaj ziemniaków”) rozluźnia atmosferę. Jeden z zespołu prowadził ćwiczenie MasterChef – rysowanie dań z określonym składnikiem, następnie ogłaszanie potrawy w stylu Gordona Ramsaya.

Zmiana aktywności: Domyślne sticky notes mogą prowadzić do powtarzających się pomysłów. Jacob z zespołu wprowadził rysowanie na iPadzie – inne medium oznacza inne myślenie. Wen zauważa, że „czasami te same pomysły pojawiają się w kółko” – dlatego ważne jest zmienianie aktywności.

Mieszanie online/offline: Części sesji należy prowadzić poza FigJam, potem wracać. Różne ograniczenia generują świeże perspektywy.

Checklist: Efektywny brainstorm w praktyce:

Przygotuj icebreaker przed sesją (nawet głupie pytanie)
Zaplanuj mix aktywności – nie tylko sticky notes
Zmieniaj aktywności co 15-20 minut
Testuj różne media (iPad, papier, whiteboard)
Uchwać nie tylko pomysły, ale energię i reakcje

Wizja przyszłości – demokratyzacja visual thinking

Wen przedstawia wyraźną wizję: „co jeśli każdy mógłby komunikować się wizualnie jak designer, nie będąc designerem?”

Obserwuje barierę: „jestem PM, robię w słowach, nie jestem visual person”. To zastraszające dla wielu osób. Nawet z narzędziami jak FigJam, które są łatwiejsze do opanowania, ludzie czują podział.

Jej wizja zakłada świat, gdzie nie potrzebujesz pewności siebie designera, żeby tworzyć wizualnie przekonujące treści. Wizualna komunikacja ma bowiem moc – najlepsze strategie firmowe, które zapamiętuje, to te z mocnym wizualnym komponentem.

Poszukiwane cechy w kandydatach – wskazówki dla designerów

Wen dzieli się tym, na co zwraca uwagę przy zatrudnianiu:

Doskonałe rzemiosło w rezultatach: Finalne produkty, które wydają, są naprawdę dobrze zbudowane i dopracowane. To pokazuje poziom rzemiosła, ale także umiejętność pracy z inżynierią i doprowadzania do wysokiej jakości efektów.

Poczucie eksperymentowania i nowości: Ludzie, którzy mają energię do „what if blue sky explorations”. Nie boją się wykraczać poza brief.

Przykład: „supposed to make normal onboarding flow, ale decyduję spróbować, co jeśli zamiast pisania imienia, musisz zrobić sobie zdjęcie”. Ambitni poza początkowym briefem, nie boją się wnosić nowości i wyobraźni.

Praktyczne prompty projektowe z rozmowy

Analizując rozmowę z Jenny Wen, można wyodrębnić szereg pytań i ćwiczeń, które działają jak polecenia stymulujące kreatywność:

Wskazówki do definiowania strategii i zakresu projektu:

Polecenie MVP: „Jaka jest minimalna liczba narzędzi, których potrzebujemy, aby [nasz produkt] stał się działającą [podstawowa funkcja]?”

Kiedy stosować: Na początku, aby zdefiniować MVP i oddzielić funkcje kluczowe od dodatków.

Wskazówka „Eigenquestion”: „Jakie jest to jedno pytanie, które — jeśli znajdziemy na nie odpowiedź — sprawi, że odpowiedzi na wszystkie inne pytania staną się proste?”

Kiedy stosować: Gdy zespół jest przytłoczony liczbą problemów do rozwiązania.

Wskazówka wizjonerska: „A co, gdyby [grupa użytkowników] mógł [wykonywać złożoną czynność] tak łatwo jak [ekspert], bez potrzeby bycia [ekspertem]?”

Kiedy stosować: Do definiowania długoterminowej wizji produktu.

Wskazówki do generowania i eksploracji pomysłów:

Technika spektrum: „Zaprojektuj [funkcję X], eksplorując dwa skrajne końce spektrum: od [ekstremum A] do [ekstremum B]. Gdzie na tej skali znajduje się optymalne rozwiązanie?”

Kiedy stosować: Gdy szukasz balansu w projekcie.

Ćwiczenie z wpisem na Twitterze: „Napisz krótki wpis z perspektywy zachwyconego użytkownika, który właśnie odkrył [naszą nową funkcję].”

Kiedy stosować: Na etapie planowania funkcji, aby skupić się na jej emocjonalnym rdzeniu.

Praktyczne wnioski dla designerów

W procesie projektowym: Traktuj inżynierię jako część iteracji, nie przekazanie. Używaj „eigen questions” do nawigacji przez złożone problemy. Mimo to miej opinię „strawman” zamiast paraliżu analizy. Myśl o eksploracjach projektowych jako spektrum z ekstremami.

W komunikacji wartości: Używaj analogii do produktów fizycznych. Łącz jakość z celami biznesowymi, nie mów tylko „needs to be polished”. Dlatego dostosuj argumenty do branży i użytkowników.

W projektowaniu delight: Skupiaj się na momentach mundane, wysokiej częstotliwości. Antycypuj potrzeby zamiast tylko celebrować. W rezultacie mierz przez testimoniale i organiczne reakcje, nie tylko metryki lejka. Zawsze zacznij od „what if?”

Kluczowy wgląd

Paradoks nudnego zachwytu

Standardowo myślimy, że: „Efekt wow” należy dodawać w momentach sukcesu i celebracji, jak ukończenie zadania czy osiągnięcie celu.

W praktyce okazuje się, że: Największy wpływ i zwrot z inwestycji w pozytywne doświadczenie uzyskuje się, subtelnie ulepszając najbardziej prozaiczne, często używane i nudne części produktu.

Dlaczego to jest istotne: Ponieważ użytkownicy spędzają 99% czasu na powtarzalnych, codziennych czynnościach, a nie na momentach celebracji. Niespodziewana poprawa jakości w tych miejscach buduje głębsze zaufanie i lojalność niż jakiekolwiek konfetti.

Test na jutro: Następnym razem gdy będziesz projektować nową funkcję, zamiast od razu planować animację sukcesu na końcu, zidentyfikuj najbardziej prozaiczny krok w jej trakcie i spróbuj dodać tam jeden drobny, inteligentny detal, który antycypuje potrzebę użytkownika.

Ten wpis jest częścią kolekcji notatek z ciekawych podcastów, webinarów i innych treści wartościowych do późniejszego wykorzystania. Oryginalne źródło: Dive Club Podcast – Episode 39 z Jenny Wen

Tag: Delight

Projektowanie delight beyond confetti – lekcje od original designer FigJam #EN239