Ten artykuł zawiera notatki z prezentacji „Escaping the UX Feature Factory” prowadzonej przez Jared Spool podczas sesji Talk UX Strategy. Wszystkie przedstawione przemyślenia, obserwacje i strategie pochodzą od prowadzącego oraz uczestników dyskusji.

TL;DR

Problem fabryki funkcji – większość organizacji UX utknęła w trybie produkcyjnym, gdzie sukces mierzony jest wyłącznie dostarczeniem czegokolwiek, bez względu na jakość
Outcomes vs deliverables – kluczowa różnica między zmianą w świecie (outcomes) a prostym oddaniem produktu (deliverables)
Badania prawdziwych użytkowników – zamiast person, skupienie na konkretnych ludziach jak „Edna” i mapowanie ich doświadczeń
Success metrics jako „party moments” – tworzenie jasnych kryteriów sukcesu, które pozwalają celebrować rzeczywiste ulepszenia
Długoterminowa wizja UX – myślenie w kategoriach 4-5 lat zamiast pojedynczych sprintów
Zarządzanie interesariuszami – pokazywanie jak badania UX realizują cele biznesowe, a nie przekonywanie do „lepszego designu”
Redefinicja „feature” – nawet lepsza architektura informacji może być sprzedana jako wartościowa funkcja

Większość zespołów UX dziś pracuje jak Lucy i Ethel w słynnym odcinku „I Love Lucy” – siedzą przy taśmie produkcyjnej, desperacko próbując owinąć czekoladki w papierki, podczas gdy tempo taśmy stale przyspiesza. Nie kontrolują tego, co wpływa na taśmę ani tego, co z niej schodzi. To doskonała metafora współczesnego problemu „fabryki funkcji” w UX, jak zauważa Spool.

Jego czterostopniowe podejście zmienia logikę pracy z bezmyślnego dostarczania na strategiczne tworzenie produktów, które rzeczywiście poprawiają życie ludzi.

Problem fabryki funkcji w UX

Metafora Lucy i czekolady

Spool wykorzystuje obraz z klasycznego odcinka „I Love Lucy”, gdzie bohaterki pracują w fabryce czekolady. Ich zadanie wydaje się proste – owinąć czekoladki w papierki. Gdy jednak tempo taśmy przyspiesza, Lucy i Ethel wpadają w panikę, chowają czekoladki w kieszeniach i jedzą je, byle tylko upewnić się, że z taśmy schodzą tylko owiniete słodycze.

Według prowadzącego, dokładnie tak wygląda praca w większości organizacji UX dzisiaj. Zespoły nie kontrolują tego, co „wychodzi ze ściany” ani tego, co dzieje się po drugiej stronie. Wszystkie trzy parametry – termin realizacji, koszt i jakość – są ustalane przez kogoś innego.

Dlaczego dostarczenie nie równa się sukcesowi

Spool identyfikuje kluczowy problem współczesnego podejścia do produktów: dostarczenie stało się głównym kryterium sukcesu. W tej logice nie ma różnicy między dostarczeniem czegoś doskonałego a dostarczeniem czegoś kiepskiego – oba przypadki są traktowane identycznie.

„Kiedy wysoka jakość i niska jakość są odznaczane dokładnie tak samo, nie ma motywacji do inwestowania więcej, żeby uzyskać wysoką jakość” – wyjaśnia prowadzący. A niska jakość jest łatwiejsza i tańsza do dostarczenia.

Ta sytuacja prowadzi do masowej depresji wśród specjalistów UX. Na LinkedIn i Medium pełno jest wpisów ludzi, którzy czują, że ich kariera nie ma sensu, bo nikt nie dba już o jakość ich pracy.

Cztery kroki do wyjścia z pułapki

Krok 1: Identyfikacja outcomes zamiast deliverables

Spool wyjaśnia fundamentalną różnicę między tymi pojęciami:

Deliverables:

Wyniki – coś, co oddajesz
Nie ma znaczenia, czy jest dobre czy złe
Kończy się w momencie przekazania

Outcomes:

Zmiana w świecie po dostarczeniu czegoś
Idealne outcome natychmiast zmienia świat na lepsze
Wymaga aktywnego szukania i mierzenia zmiany

Problem polega na tym, że jeśli nie szukasz tej zmiany, nie zobaczysz jej. W rezultacie nie będziesz wiedział, jak świat się zmienił dzięki temu, co dostarczyłeś.

UX outcomes vs wyniki biznesowe

Literatura produktowa często mówi o outcomes, jednak zazwyczaj chodzi o wyniki biznesowe – zwiększenie przychodów, lepsze utrzymanie klientów, wzrost. To są dobre cele, ale skierowane do wewnątrz organizacji.

UX outcomes skupiają się na poprawianiu doświadczeń ludzi. Spool proponuje myślenie o doświadczeniu na skali od frustracji do zachwytu. Większość produktów dostarcza „roller coaster” doświadczeń – czasem zachwycających, czasem frustrujących.

Przykład z Edną i eksportem danych

Spool używa konkretnego przykładu z prawdziwym człowiekiem, nie personą. Edna pracuje w firmie klienta i co miesiąc eksportuje dane do swojego raportu. Obecnie kopiuje dane, wkleja je, tworzy wykresy, znajduje błędy i musi wracać do oryginalnych danych.

Pytanie brzmi: jeśli zrobimy świetną robotę z eksportem danych, czyje życie się polepszy i jak?

W przypadku Edny odpowiedź jest jasna: będzie mogła przygotować swój miesięczny raport w kilka minut zamiast godzin. To konkretny UX outcome. Co więcej, jak zauważa Spool, ostateczne rozwiązanie może nie być eksportem danych, ale lepszymi możliwościami tworzenia wykresów lub dashboardem, gdzie ludzie mogą po prostu wyświetlić liczby i zobaczyć je w czasie rzeczywistym.

Krok 2: Badania prawdziwych użytkowników

Spool mocno krytykuje persony: „Persony nie robiły nic poza tworzeniem problemów dla ludzi UX. Kiedyś myślałem, że to dobry sposób, ale dziś polecam ich unikanie.”

Zamiast tego proponuje skupienie na prawdziwych ludziach. Na planecie jest 9 miliardów ludzi, więc wybierzmy jednego. Edna to rzeczywista osoba, a jeśli rozwiążemy jej problem, rozwiążemy go również dla wielu innych.

Roller coaster diagrams

Spool proponuje mapowanie obecnych doświadczeń użytkowników za pomocą „diagramów roller coaster”. Pokazują one, które momenty są frustrujące, a które zachwycające. Następnie można zadać pytanie: co by było, gdyby całe doświadczenie było zachwycające?

To staje się „aspirational experience” – wizją tego, jak mogłoby wyglądać idealne doświadczenie użytkownika.

Krok 3: Metryki sukcesu jako „party moments”

Trzeci krok to stworzenie sposobu mierzenia sukcesu. Spool zauważa różnicę między zwykłymi metrykami a wysokiej jakości metrykami:

Zwykłe metryki pokazują zachowania w systemie i koncentrują się na analityce. Wysokiej jakości success metrics dają sposób na udowodnienie, że coś się zmieniło – na lepsze, gorsze, lub wcale.

Te „success metrics” powinny jasno wskazywać moment, w którym poprawiliśmy życie Edny. Spool nazywa kryteria definiujące taką metrykę „party moment” – teraz wiemy, jak zorganizować imprezę, żeby powiedzieć wszystkim, że odnieśliśmy sukces.

Krok 4: Długoterminowa wizja UX

Dodatkowy krok dotyczy myślenia w dłuższej perspektywie. Zamiast 30-minutowego wycinka życia Edny, można zadać pytanie: co by było, gdybyśmy mieli 5 lat na świetną robotę?

Typowe roadmapy sięgają 12-18 miesięcy. Spool proponuje pomyślenie o trzech takich roadmapach – 4,5 roku. Co będziemy mieli, gdy skończymy? Gdzie zmierzamy?

To pozwala na rozmowy o większych problemach, bez ograniczania się do tego, „co da się zrobić w 18 miesięcy”.

Praktyczne wyzwania wdrożenia

Jak przekonać startupy skupione na szybkości

Dan z publiczności pyta o startupy AI, gdzie wszyscy boją się, że konkurencja „zje im lunch”. Chcą wypuszczać produkty szybko, nie będąc pewni, czy pracują nad właściwymi rzeczami.

Spool odpowiada strategicznie: „Jeśli wypuścimy coś i nie zadziała, nasza konkurencja nauczy się z tego szybciej niż my.”

Jego rozwiązanie opiera się na zrozumieniu product-market fit:

Definicja product-market fit: moment, gdy nie musisz inwestować w działania marketingowe, bo produkt sprzedaje się sam
Przykład: nowy zwiastun filmu, który sam rozchodzi się po mediach społecznościowych
Kluczowe pytanie: jak zbudować coś, co tak poprawia życie ludzi, że sami publikują to w mediach społecznościowych?
Przewaga badań: jeśli konkurencja skopiuje funkcje, nie zrozumie dlaczego działają

Dodatkowo Spool przywołuje powiedzenie: „Przeciwieństwem badań jest zgadywanie” – co oznacza, że jeśli zgadujemy, co ludzie chcą, powinniśmy mieć bardzo niską pewność co do tego, co będzie działać.

Rola badaczy w prowadzeniu discovery

Carmen pyta o możliwość przejęcia przez badaczy roli lidera w discovery, gdy menedżerowie produktu nie mają tej ekspertyzy.

Spool zgadza się z tym podejściem, jednak ostrzega przed traktowaniem discovery jako oddzielnej fazy: „Discovery to budowanie ekspertyzy na temat tego, kim są nasi użytkownicy, czego potrzebują i jakie mają doświadczenia.”

Prowadzący zauważa, że w wielu organizacjach po prostu doklejają kilka tygodni discovery do istniejącego procesu dostarczania… spędzasz kilka tygodni próbując przebić się przez discovery, a potem to wyłączasz i wracasz do nie zwracania uwagi na to, co robisz.

Zamiast tego discovery powinno być ciągłym procesem mierzonym tym, czy jesteśmy najmądrzejszymi ludźmi na świecie w kwestii naszych użytkowników.

Zarządzanie interesariuszami i przekonywanie do zmian

Sophia pyta o najtrudniejsze pytanie: jak przekonać ludzi, którzy nie byli na tej rozmowie?

Spool wyjaśnia strategię opartą na zrozumieniu ich celów: to mniej o przekonywaniu, a więcej o pokazywaniu, jak to, co robimy, zbliża ich do ich celów. Trzeba poznać cele interesariuszy.

Prowadzący zauważa, że firmy nie zamykają działów R&D, bo boją się, że pieniądze przestaną płynąć jutro. Znacznie taniej jest sprzedać coś obecnemu klientowi, który już nas kocha, niż znaleźć nowego klienta.

Sophia dodatkowo podkreśla problem enterprise’owych firm: „Zarabiają pieniądze. Ciągle zarabiają pieniądze na kiepskich doświadczeniach. Ludzie ciągle płacą” – ale jak odpowiada Spool, gdyby firmy były naprawdę zadowolone z produktu, zamknęłyby R&D.

Problem „sypkiej podstawy”

Sophia zwraca uwagę na istotny problem: „kiepska architektura informacji, okropne fundamenty, a potem dodajemy więcej dzwonków i gwizdków… staje się kompletnym bałaganem” – wszystko się sypie, gdy fundament jest słaby.

Redefinicja „feature”

Spool zauważa, że słowo „feature” nie ma standardowej definicji. Można je zdefiniować jako cokolwiek – lepsza architektura informacji, nawigacja, menu to też „features”.

Możemy sprzedać redesign jako feature. Możemy sprzedać lepszą nawigację jako feature – wyjaśnia prowadzący.

Interesariusze nie dbają o definicję feature. Dbają o to, jak zwiększyć wartość produktu. Gdzieś w głowie mają przekonanie, że więcej funkcji = więcej wartości, jednak można im pokazać, że to bardziej skomplikowane.

Kluczowe takeaways

Victor pyta, ile czasu zajmuje wdrożenie tego procesu. Spool odpowiada jasno: „To ciągły proces. Nie ma końca.”

Sekret leży w myśleniu jak Wayne Gretzky – „Musisz być tam, gdzie będzie krążek.” Jeśli zespoły dostarczają szybko, a badania trwają 6 miesięcy, trzeba pracować nad projektami, które zespoły będą robić za 6 miesięcy.

Spool kończy mocnym przesłaniem: „Kiedy masz outcomes, badania, metryki i długoterminową wizję, tworzysz sens. Przestaje to być praca produkcyjna, gdzie tylko wysyłasz najmniej okropne rzeczy. Rzeczywiście poprawiasz świat.”

Checklista: Jak wyjść z pułapki fabryki funkcji

✅ Krok 1: Zdefiniuj UX outcomes

[ ] Przejdź od deliverables do outcomes
[ ] Zidentyfikuj konkretną osobę (nie personę), której życie chcesz poprawić
[ ] Odpowiedz na pytanie: „Jeśli zrobimy świetną robotę, czyje życie się polepszy i jak?”
[ ] Zdefiniuj „aspirational experience” – jak wyglądałoby idealne doświadczenie

✅ Krok 2: Przeprowadź badania prawdziwych użytkowników

[ ] Znajdź i poznaj prawdziwych ludzi (nie persony)
[ ] Stwórz „roller coaster diagram” obecnych doświadczeń
[ ] Zmapuj momenty frustracji i zachwytu
[ ] Zrozum szerszy kontekst – co dzieje się poza produktem

✅ Krok 3: Ustal success metrics

[ ] Zdefiniuj jasne kryteria sukcesu
[ ] Stwórz „party moment” – moment celebrowania poprawy
[ ] Upewnij się, że metryka pokazuje prawdziwą zmianę, nie tylko zachowanie
[ ] Przygotuj sposób na udowodnienie, że życie użytkownika się poprawiło

✅ Krok 4: Zbuduj długoterminową wizję

[ ] Pomyśl w kategoriach 4-5 lat (3 roadmapy)
[ ] Zadaj pytanie: „Co będziemy mieli, gdy skończymy?”
[ ] Skoncentruj się na większych problemach do rozwiązania
[ ] Stwórz wizję tak interesującą, że ludzie chcą być jej częścią

✅ Dodatkowo: Zarządzanie interesariuszami

[ ] Poznaj cele biznesowe swoich interesariuszy
[ ] Pokaż, jak badania UX realizują te cele
[ ] Redefiniuj „feature” – nawet lepsza architektura informacji to feature
[ ] Skup się na wartości, nie na przekonywaniu do „lepszego designu”
[ ] Pamiętaj: taniej jest sprzedać obecnemu klientowi niż znaleźć nowego

Kluczowy insight

Problem nie jest rozwiązaniem

Standardowo myślimy: Dostajemy wymaganie na konkretną funkcję (np. „eksport danych”), więc budujemy dokładnie tę funkcję.

W praktyce okazuje się, że: Gdy skupiamy się na outcomes zamiast deliverables, często odkrywamy że powinniśmy budować zupełnie coś innego. W przykładzie z Edną, która potrzebowała eksportu danych do raportów, prawdziwym rozwiązaniem mogłby być dashboard z danymi w czasie rzeczywistym, a nie eksport.

Dlaczego to jest istotne: Większość zespołów marnuje czas budując „poprawne” rozwiązania niewłaściwych problemów, zamiast znaleźć właściwe rozwiązanie prawdziwego problemu.

Test na jutro: Następnym razem gdy dostaniesz wymaganie na konkretną funkcję, zamiast od razu planować implementację, spróbuj porozmawiać z jednym prawdziwym użytkownikiem i sprawdź, jaki problem rzeczywiście próbuje rozwiązać.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: https://leaders.centercentre.com/posts/the-talk-ux-strategy-archive-escaping-the-ux-feature-factory

Tag: Feature Factory

Jak wyjść z pułapki fabryki funkcji UX? 4 kroki do tworzenia produktów, które naprawdę mają znaczenie #EN186