Nota od autora: Ten artykuł to moje notatki z panelu dyskusyjnego „AI is Redesigning Design Tools”, w którym wzięli udział Jenny Wen (Anthropic), Nat Friedman (Lovable), Manuel de la Peña (Vercel) i Amber z Get Your Guide. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od uczestników rozmowy – ludzi, którzy na co dzień budują narzędzia AI dla designerów i sami przechodzą przez tę transformację.

TL;DR

Technologia AI do zmiany designu już istnieje, jednak żaden tool nie zintegrował jeszcze pełnego workflow
Zespoły kurczą się z 8-osobowych „squad” do 2-3 generalistów – zasada 80% pozwala jednej osobie robić większość pracy w wielu dziedzinach
Designerzy muszą nauczyć się rozumieć modele AI tak samo dobrze jak zasady UX – w przeciwnym razie ktoś inny podejmie za nich decyzje produktowe
Content designerzy przechodzą „w górę stosu” – od pisania copy do architektury informacji i konceptów
Perfekcjonizm to obecnie największa przeszkoda – dlatego kluczem jest eksperymentowanie, szybkie wysyłanie i iteracja
Modele mają „osobowości” i trzeba nauczyć się z nimi pracować jak z zespołem, nie jak z narzędziem
Najbardziej wartościowa umiejętność: myślenie o tym, co AI będzie potrafić za 2-3 lata, nie tylko dziś

Wstęp: nowa era w projektowaniu produktów

Sztuczna inteligencja przestaje być jedynie nowinką technologiczną. Staje się fundamentalną siłą, która zmienia zasady gry w tworzeniu produktów cyfrowych. Jak zauważa Jenny z Anthropic, technologia do fundamentalnej zmiany naszej pracy już istnieje, jednak wciąż brakuje warstwy UX, która połączyłaby te możliwości w spójny proces twórczy.

W rezultacie projektanci i liderzy muszą odnaleźć się w nowej, przejściowej rzeczywistości. To moment, w którym nikt nie ma gotowych odpowiedzi – nawet ci, którzy budują najpopularniejsze narzędzia AI. Dlatego warto posłuchać, jak eksperci z czołowych firm technologicznych radzą sobie z tą niepewnością.

Technologia jest, UX jeszcze nie całkiem

Jenny Wen zaczyna od obserwacji, która może zaskoczyć: im bliżej technologii AI, tym mniej pewności co do przyszłości. Według niej technologia do fundamentalnej zmiany sposobu pracy już istnieje – modele stają się lepsze w designie, pojawiają się produkty używające promptów do tworzenia kolejnych wersji pracy.

Problem? Żadne narzędzie – ani nowe, ani incumbent – nie zintegrowało jeszcze pełnego workflow. Jenny uważa, że canvas-based visual editing tools nadal będą sposobem, w jaki edytujemy i tworzymy projekty. Technologia jest gotowa, jednak UX do fundamentalnej zmiany zadań jeszcze nie.

Zmierzch specjalistów? Jak AI zmienia struktury zespołów

Era dużych, sformalizowanych zespołów, budowanych na wzór „Spotify Squads”, może dobiegać końca. Nat Friedman wprowadza konkretną zasadę 80%: AI może wykonać większość rzeczy na poziomie 80% w większości dziedzin. Mądra osoba z AI może teraz zrobić 80% wszystkiego, co zmienia sposób myślenia o zespołach.

Nat precyzuje jednak, że ten model sprawdza się najlepiej w zespołach tworzących coś zupełnie nowego, podczas gdy optymalizacja istniejących produktów może wymagać innego podejścia.

Role stają się płynne, a zespoły asymetryczne. Do dwóch lat temu wszyscy powtarzali mantrę Spotify squad – EM, PM, designer, pięciu inżynierów. Osiem osób do podjęcia jednej decyzji. Teraz w Lovable jedna mądra osoba może przeprowadzić wszystko end-to-end. W praktyce jednak nie chcą tego – jedna osoba ma ślepe punkty. Dlatego mają bardzo małe grupy ludzi, którzy współpracują.

To powrót do czasów webmasterów, jak zauważa Nat. Na początku web developmentu webmaster to był czasem designer z crackownym Dreamweaverem, czasem developer znający deployment, czasem IT-owiec, który umiał podłączyć kabel sieciowy. Po prostu ludzie, którzy tworzyli rzeczy. Właśnie dlatego obserwujemy powrót generalistów.

Manuel de la Peña potwierdza to samo zjawisko i dodaje: LLM-y podniosą podłogę, ale to człowiek ustala sufit. Jego zespoły w Vercel też radykalnie się skurczyły. Pojawia się też nowa rola: design engineer. Według Manuela to testament kompresji – siedzą między designerami a engineerami, mają inną incentive structure, dbają o inne rzeczy.

Czego AI nie potrafi – i co zostaje dla ludzi

Jenny jest bardzo konkretna: modele staną się bardziej autonomiczne. Agenty to wielka rzecz 2025 roku. Mimo to zawsze będzie ktoś, kto pisze prompt, a także ktoś, kto decyduje, czy to ma wyjść w świat.

Trzy rzeczy, których AI nie zabierze designerom:

Kontekst użytkownika – największy przełom w budowaniu AI produktu to zrozumienie celów użytkownika, tego co robią, co wiedzą, zanim dotkną produktu
Gust – każdy definiuje go inaczej i super trudno to zapakować w przepis, który można zastosować konsekwentnie
Ostatnie 20% pracy – AI robi 80%, jednak to ostatnie 20% to często kolejne 200% wysiłku i wymaga człowieka

Nat idzie dalej i mówi o czymś fascynującym: modele mają osobowości jak małe dzieci. Ten chce się zachowywać w ten sposób, tamten w inny. Jak stworzyć małe zabezpieczenia? Jak wydobyć więcej z mocnych stron i zminimalizować słabe punkty?

To zmienia perspektywę na prompt engineering. Nie jest to wyłącznie techniczna umiejętność – to rozumienie charakterów i ograniczeń modeli.

Nat wprowadza jeszcze jedną prowokacyjną myśl: nasze role mogą przejść w kierunku czegoś bliższego fashion industry. Jest utility garmentu, ale milion bardzo ludzkich faktorów dlaczego wybierasz coś zamiast czegoś innego. Fashion designer używa AI do market research, maszyn do produkcji, jednak to wciąż osoba robiąca coś dla innych ludzi. Działanie z AI przypomina kulturę remiksu w muzyce – można samplować i czerpać inspiracje, jednak stworzenie czegoś w 100% pochodnego jest nieciekawe i pozbawione wartości.

Designer musi rozumieć modele – albo straci kontrolę

Nat dzieli się doświadczeniem z budowania Lovable. W pierwszym roku musieli trzy razy usunąć wszystko i zacząć od nowa. Dlaczego? Jest symbiotyczna relacja między user experience, zachowaniami i osobowościami każdego modelu, tym jak ich używasz, jak je łączysz.

Jego rada dla design leaderów: jeśli myślisz tylko o designie, jest kompletny sufit tego, co możesz osiągnąć. Wysoka kompetencja techniczna jest ważniejsza niż kiedykolwiek.

Przykład z doświadczenia Nat pokazuje konsekwencje braku tej wiedzy. Jeśli tego nie robisz, ktoś inny podejmie te decyzje za ciebie. Będziesz projektować produkt, gdzie jedno wywołanie modelu zajmuje dwie minuty. Zapytasz: dlaczego dwie minuty? Inżynierowie odpowiedzą: bo tak to zaimplementowaliśmy. Efekt? Okropne user experience.

Jenny dodaje: w Anthropic wielu designerów jest technical. Często czuje, że w poprzednich firmach była po bardziej technicznej stronie, a tutaj czuje się po mniej technicznej – co jest dziwne.

Nat wzywa designerów do tego, żeby wziąć odpowiedzialność za słowo „kontekst”. Dziś to termin inżynieryjny – context modelu. Jednak największy kawałek kontekstu w AI produkcie to użytkownik. Nawet gdybyśmy zamrozili rozwój modeli dziś, byłoby tak dużo pracy UX do zrobienia tylko przez zoomowanie w kontekst użytkownika i to, jak używają modeli.

Jak Vercel się nauczył – wewnętrzne testowanie jako strategia

Manuel dzieli się story o transformacji Vercel. Firma przeszła z „serwujemy najszybsze strony na świecie” do budowania całej infrastruktury dla AI. Kluczem był V0 – ich własne narzędzie AI.

V0 był niewiarygodnie przełomowy dla myślenia o budowaniu infrastruktury. Niesamowite jest posiadanie AI produktu w tej samej firmie, który informuje jak infrastruktura powinna działać. To pokazuje, że brakuje wielu kawałków, które trzeba zbudować, żeby umożliwić innym AI tools sukces w Vercel.

Mieć wewnętrznego klienta, który sam używa wszystkiego i daje bardzo krytyczny feedback – to zmieniło grę. Odkryli czego brakowało: sandboxes do izolowanego wykonywania kodu, queues, całego stosu primitives dla agentów.

Projektowanie dla infrastruktury jest bardzo trudne. Musisz naprawdę uchwycić masę technicznych konceptów, których normalnie nie masz w swoim zakresie. Ponadto musisz się stale uczyć nowej rzeczy, której nie znałeś w zeszłym tygodniu.

Kluczowe kompetencje lidera i zespołu w erze AI

Praca w środowisku AI wymaga od liderów i członków zespołów nowych umiejętności. Paneliści wskazali trzy kluczowe obszary, na których należy się skupić:

Biegłość techniczna

Projektanci muszą rozumieć, jak działają modele. Nat barwnie opisuje, że modele mają własne „osobowości”, niczym małe dzieci – jedne są lepsze w jednym, inne w drugim. Bez technicznej wiedzy nie da się z nimi efektywnie współpracować. Manuel dodaje, że ciekawość jest ważniejsza niż kiedykolwiek – nie wiesz, czego nie wiesz, więc musisz zacząć kwestionować.

Myślenie „AGI-pilled”

Jenny z Anthropic wprowadza pojęcie projektowania z wyprzedzeniem – z myślą o tym, co technologia będzie potrafiła za dwa lub trzy lata, a nie tylko dziś. To umiejętność ekstrapolowania i wierzenia w to, co technologia będzie potrafić w przyszłości. Jeśli myślisz tylko o tym, co jest teraz, kończysz z projektowaniem czegoś, co do czasu ukończenia model już to potrafi. Takie podejście pozwala unikać tworzenia rozwiązań, które w momencie wdrożenia będą już przestarzałe.

Psychologiczne bezpieczeństwo

Zespoły muszą mieć przestrzeń do zabawy, eksperymentowania i popełniania błędów. Nat opowiada o badaniu Google, które wykazało, że definiującym powodem sukcesu zespołów jest psychologiczne bezpieczeństwo. Musi być okej, żeby ponieść porażkę. Porażka musi być właściwie przyjęta. Według Nata tylko w takim środowisku mogą w pełni wykorzystać potencjał nowej technologii.

Jenny zauważa też, że mimo generalizacji ról, nadal jest miejsce dla deep specialists. Ktoś niesamowity w prototypowaniu czy visual design ma ogromną wartość, bo modele nie są w tym jeszcze dobre. Ponadto ktoś z takim poziomem gustu jest po prostu bezcenny.

Nat dodaje ważny punkt o prompt engineeringu: u nich w Lovable wszyscy w firmie wiedzą jak promptować, down to support engineers. Ci sami ludzie robią full loop od frontline support do poprawiania produktu. To demokratyzacja umiejętności.

Research: więcej jakości, mniej ilości

Nat dzieli się zaskakującym spostrzeżeniem o tym, jak badali użytkowników przy budowaniu Lovable. Myślał, że mogą rozwiązywać problemy UX częściowo przez postęp modeli i łączenie tego razem.

W rzeczywistości proces był dużo bardziej jakościowy niż ilościowy. Najwięcej sygnału dostaliśmy z siedzenia z użytkownikami i obserwowania ich zamiast z ewaluacji i mierzenia danych. Dosłownie old school: czy nam się to podoba? Tak. Daliśmy komuś. Czy im się podoba? Tak.

To było bardzo fuzzy „this just feels right”. Ten sposób działania okazał się najbardziej wartościowy we wczesnych fazach produktu.

Gdy wszystko idzie źle – porażka z agentami

Nat dzieli się konkretnym failure story, które kosztowało ich miesiące. Wczesnym zeszłym roku słuchali za dużo foundation model providers mówiących, że agenty i agentic workflows będą przyszłością.

Spędzili miesiące budując wokół tego. Myśleliśmy: jeśli możemy być pierwsi w tym lub najbardziej przygotowani, będziemy mieć produkt, który przeskoczy wszystkich.

Czego nie wzięli pod uwagę? Firmy modelowe i inżynierowie mierzą wydajność, nie opóźnienia. Możesz mieć model świetny w rozumowaniu, jednak zajmuje 10 minut. Dla ich produktu to po prostu nie działa – chcesz rozwijać pomysły czując, że co-tworzysz z AI.

Szczerze spaliliśmy miesiące idąc w złą ścieżkę przed produktem, przed launchem – przyznaje Nat.

Negatywny reinforcing loop, który Nat widzi najczęściej: ludzie próbują coś z AI, widzą jego flaws i mówią „oh, this thing sucks, I’m out”. Zamiast tego powinni zbudować coś end-to-end, a także potraktować to jako ćwiczenie zabawy.

Content design przechodzi „w górę stosu”

Jenny opisuje konkretną zmianę w Anthropic. Zespół content design stara się nie angażować w codzienne UX writing i copy. Zamiast tego stworzyli Claude Project z wytycznymi dotyczącymi voice i tone, który pomaga pisać teksty.

Przechodzą w górę stosu, żeby pomóc nam z konceptualnym materiałem – jak reprezentować koncepcję wiedzy dla użytkowników? Gdzie to pasuje do koncepcji pamięci i kontekstu? Czy to różne rzeczowniki i jak użytkownik to rozumie w architekturze informacji?

Jest to dowód na to, jak automatyzacja podstawowych zadań uwalnia potencjał do pracy nad bardziej złożonymi wyzwaniami.

Nat ma jednak zastrzeżenie: LLM-y nie są niesamowite w pisaniu. Zawsze można poznać, prawda? W Lovable używają ich bardziej do walidacji – czy ten tone jest poprawny? Czy używamy tego samego żargonu wszędzie konsekwentnie? Jednak nie jako magiczny content design team z wizją i spójnością.

Zaczynaj od AI, nie kończ na AI

Manuel wprowadza praktyczne podejście, które stosują w Vercel. Robimy dużo rzeczy które zaczynają się od AI, ale nie kończą na AI. Myślę, że to absolutnie świetne, bo możesz eksplorować dużo dalej, dużo szybciej i podejmować decyzje gdzie chcesz iść.

Często ten ostatni odcinek, ta translacja – potrzebuję móc manipulować każdy aspekt tego – po prostu popycha cię do zbudowania tego samemu.

To oswobadzające podejście. AI jako punkt startowy eksploracji, nie punkt końcowy. Daje szybkość w testowaniu kierunków, jednak ostateczna kontrola i precyzja nadal należy do człowieka.

Kontekst, zaufanie i etyka: fundamenty projektowania z AI

W dyskusji o AI często dominuje technologia, jednak prawdziwe przełomy leżą gdzie indziej. Dlatego Nat wystosował apel do projektantów, by przejęli na własność słowo „kontekst”. W inżynierii oznacza ono dane wejściowe dla modelu, jednak dla produktu kluczowy jest kontekst użytkownika: jego cele i sytuacja. Zrozumienie tego ludzkiego wymiaru jest największą wartością.

Nat dzieli się doświadczeniem z Element – produktu do super bezpiecznej komunikacji używanego przez Bundeswehr, francuski rząd i dziennikarzy w reżimach, gdzie to sprawa życia i śmierci.

Czasem rozwiązaniem było user experience – musimy coś tak wyjaśnić i dać ludziom te narzędzia. Czasem było to narzędzie do moderacji. Czasem polityka – byliśmy doradcami rządów, pomagając kształtować prawo, żeby nie tylko nasz produkt był etyczny, ale cały system prawny.

Trzy poziomy rozwiązywania problemów etycznych w AI:

User experience – wyjaśnić coś w odpowiedni sposób i dać ludziom odpowiednie narzędzia
Tooling – pozwolić ludziom moderować rzeczy lub dać im sposoby na działanie
Polityka – być doradcami rządów, pomagać kształtować prawo dla całego systemu

Jenny opisuje, jak to wygląda w Anthropic: misją nie jest zarabianie pieniędzy, ale zwiększanie przepływu bezpiecznych tokenów AI w świecie. Opóźnimy launch, jeśli nie przechodzi naszych kryteriów bezpieczeństwa. Dzieje się to cały czas przy modelach – wstrzymujemy się tygodniami zamiast po prostu coś wysłać.

CEO Anthropic spędza mnóstwo czasu z world leaders nad kształtowaniem polityki AI. To część strategii firmy. Z kolei Jenny dodaje do tego wymiar zaufania, opowiadając, jak jej firma celowo opóźnia premiery, by zapewnić bezpieczeństwo, co jest fundamentem relacji z użytkownikiem.

Jak nie tworzyć cyfrowych śmieci – i dlaczego to nie bańka

Na pytanie o digital junk Nat odpowiada analogią do wczesnych dni YouTube. 99% contentu uploadowanego w pierwszych latach nie było dobre – niska rozdzielczość, dwa wyświetlenia. Jednak zdemokratyzowaliśmy możliwość robienia czegoś. Z czasem pojawiły się niesamowite efekty drugiego i trzeciego rzędu – nowa kultura i subkultury.

Myślę, że nazywanie tego „cyfrowym śmieciem” jest po prostu dość niecharytatywne. Musimy zobaczyć, dokąd nas to zaprowadzi i być optymistami – dodaje Nat.

Nat proponuje myśleć o tym jak muzyczna branża myśli o samplingowaniu. Jeśli tworzysz coś 100% derivative, A) to jest po prostu 100% derivative, i B) nikt tego nie chce. Ludzie pytają: czy to po prostu zła wersja rzeczy którą lubiłem? Powinniśmy przyjąć perspektywę remixingu i samplingowania, jednak też uznać, że jeśli wyciągniesz tylko generyczne AI training data, będą to generyczne AI training data.

Manuel dodaje kluczowy punkt: niezależnie od tego, co generujemy, zawsze jest człowiek w pętli. AI nie wypuszcza rzeczy samo. Jesteś twórcą tego contentu. Plus za kulisami dzieje się prompt enhancement i wiele innych rzeczy, które sprawiają, że output jest lepszy, nawet gdy użytkownik o tym nie wie.

To nie jest bańka – to wyścig narzędzi

Nat ma bardzo konkretny argument przeciwko panice o „AI bubble”. Nie myślę, że jesteśmy w bańce. Dwie różne rzeczy. Jesteśmy w wyścigu narzędzi – dużo kapitału idzie na to, żeby spróbować wyścigowo wygrać z wieloma ludźmi. To różni się od bańki.

Kiedy patrzysz na foundation model providers – powiedzmy OpenAI i Anthropic – sposób w jaki to działa jest następujący: powiedzmy że jest frontier model i kosztuje kilkaset milionów do wytrenowania. Każdy pojedynczy frontier model do tej pory był rentowny.

Wydajesz te pieniądze na trening, wypuszczasz to, pobierasz opłaty za dostęp – to rentowne. Następny model jest bardziej ambitny, więc droższy, i tak dalej. To bardziej jak semiconductor manufacturing gdzie próbujesz inwestować w następną generację ciągle.

Otwarte pytanie: czy jest limit do obecnych technik i czy będzie nadmierna inwestycja w następne modele z nadmiernymi obietnicami? Jednak to jest różne od bycia w bańce – faktycznie wszyscy zbudowali zrównoważony biznes wokół tego co próbowali zrobić do tej pory.

Sparkles znikną – AI stanie się normalne

Manuel dzieli się interesującą refleksją z czasów pracy nad Copilotem. Mieliśmy tę ideę: nie chcemy dodawać sparkles wszędzie. Przeprasza, że się to stało, jednak idea była taka, że za kilka lat nie będziesz musiał oznaczać niczego jako „to jest AI, kliknij tutaj”.

Będzie to po prostu kolejna technologia działająca za kulisami. Nie musisz myśleć o tym zbyt głęboko, będzie po prostu łatwo dostępne dla ciebie.

Manuel myśli, że więcej niż „pęknięcie bańki”, akt używania modelu do robienia czegoś stanie się tak normalny, że nie będziemy musieli stemplować wszystkiego sparkles wszędzie. To przestanie być funkcjonalność – stanie się po prostu sposobem działania.

Trzy rady: eksperymentuj, ufaj, wysyłaj

Wszyscy trzej paneliści zgadzają się co do kluczowych rad dla designerów.

Manuel: Stwórz przestrzeń do eksperymentów

Pomóż ludziom próbować, eksperymentować, patrzeć poza to, co robią na co dzień. Jest tyle narzędzi. Wszystkie dają coś innego, wszystkie w swój sposób dają różne rezultaty. Po prostu eksperymentuj, znajdź to, co działa dla ciebie, spróbuj dopasować to do swojego workflow. A potem zakwestionuj to ponownie i spróbuj więcej rzeczy. Bo zawsze będzie się to poprawiać.

Jenny: Bądź elastyczny i kwestionuj granice ról

Nie musimy mówić: jestem product designerem, robię te rzeczy XYZ. Jednak spróbuj się rozciągnąć i zapytać: co normalnie robi inżynier? Czy mogę to teraz zrobić? Właściwie prawdopodobnie tak. To może być naprawdę zabawne. Prawie jak gdy po raz pierwszy weszliśmy do tej branży.

Nat: Wysyłaj, obserwuj, iteruj – albo usuń i zrób coś nowego

Największy wstyd, który widzę, szczególnie gdy rozmawiam z designerami o AI, to że perfekcjonizm ich powstrzymuje. Są zabawy dla siebie, żeby się uczyć – super. Jednak naprawdę zachęcam ludzi do budowania czegoś end-to-end. Nie tylko zbuduj, ale daj to innym ludziom i obserwuj, jak używają. Potem iteruj. Następnie usuń, jeśli jest do kitu, ale zbuduj coś innego. Właśnie wysyłając end-to-end nauczysz się więcej o innych domenach.

Quick check: Czy jesteś gotowy na projektowanie z AI?

Podstawy techniczne:

Rozumiem jak działają context window i training data w modelach
Wiem jak chainować różne modele do osiągnięcia rezultatu
Znam ograniczenia prędkościowe i opóźnienia w AI (i wiem, jak wpływają na UX)

Nastawienie:

Myślę o tym, co model będzie potrafić za 2-3 lata, nie tylko dziś
Regularnie testuję nowe AI tools – nawet jeśli nie używam ich w pracy
Traktuję pracę z AI jak zabawę, nie jak obowiązek
Jestem gotów usunąć wszystko i zacząć od nowa, jeśli to konieczne

Proces:

Wysyłam niedoskonałe rzeczy i iteruję na podstawie informacji zwrotnej
Obserwuję użytkowników zamiast polegać tylko na metrykach
Pytam inżynierów „dlaczego” zamiast przyjmować techniczne ograniczenia
Znam „osobowość” modeli, z którymi pracuję (mocne i słabe strony)
Zaczynam od AI do eksploracji, jednak nie boję się skończyć ręcznie

Współpraca:

Rozumiem podstawy tego, co robią PM-i i inżynierowie
Nie boję się wejść w domenę innych ról, gdy jest to potrzebne
Tworzę psychologicznie bezpieczne środowisko dla eksperymentów

Kluczowy insight

Paradoks wartościowej opinii w erze danych

Standardowo myślimy: Budując AI produkt, potrzebujemy sofistykowanych ewaluacji, benchmarks i metryk technicznych żeby ocenić czy idziemy w dobrym kierunku. Im więcej danych, tym lepiej. Każda decyzja musi być poparta danymi.

W praktyce okazuje się, że: Nat z Lovable odkrył coś zaskakującego w pierwszym roku budowania produktu. Najwięcej sygnału dostaliśmy z siedzenia z użytkownikami i obserwowania ich zamiast z ewaluacji i mierzenia danych. Dosłownie old school: czy nam się to podoba? Tak. Daliśmy komuś. Czy im się podoba? Tak. To było bardzo fuzzy „this just feels right” – i właśnie to okazało się najbardziej wartościowe. W początkowej fazie rozwoju to jakościowe „odczucie” jest ważniejsze niż jakakolwiek metryka.

Dlaczego to jest istotne: W świecie obsesyjnie skupionym na danych i metrykach, łatwo zapomnieć że AI produkt jest nadal produktem dla ludzi. Fuzzy „this feels right” może dać więcej kierunkowych spostrzeżeń niż najlepsze ewaluacje – szczególnie we wczesnej fazie, gdy próbujesz znaleźć product-market fit. Skupienie się wyłącznie na metrykach może prowadzić do optymalizacji złych rzeczy i utraty z oczu realnego doświadczenia użytkownika.

Test na jutro: Następnym razem gdy testujesz AI feature, zamiast zaczynać od setupowania dashboardów i metryk, po prostu usiądź obok 3 użytkowników i obserwuj jak próbują tego użyć przez 30 minut każdy. Na koniec zapytaj tylko: „Jakie to było uczucie?”. Sprawdź czy ten jeden dzień da ci więcej actionable insights niż tydzień patrzenia na wykresy.

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ć. Jest to transkrypt panelu „AI is Redesigning Design Tools” z udziałem Jenny Wen (Anthropic), Nat Friedman (Lovable), Manuel de la Peña (Vercel) i Amber z Get Your Guide.

Tag: Przyszlosc Pracy

AI nie zabiera pracy designerom – zmienia reguły gry #EN330

Od lidera ludzi do lidera AI – kluczowe lekcje od Julie Zhuo #EN286