Notatki z rozmowy Dylana Fielda (CEO Figmy) z Carlosem na konferencji produktowej. Wszystkie przemyślenia i obserwacje pochodzą od rozmówców.

TL;DR:

Design przestał być opcjonalny – w świecie, gdzie AI sprawia, że software powstaje coraz szybciej, design i kunszt to jedyne sposoby na wyróżnienie produktu
Dwie trzecie użytkowników Figmy to nie-designerzy, co pokazuje zmianę w myśleniu o tym, kto powinien mieć dostęp do narzędzi designerskich
Field budował community Figmy przez cold emaile do swoich idoli i meetupy organizowane podczas każdego urlopu – feedback od najlepszych designerów był kluczowy
Historia Fig Jam pokazuje, jak w jeden dzień design sprint zmienił nudny produkt w coś wyjątkowego przez skupienie na „zabawie” jako differentiatorze
Najlepsi CEO prowadzą talent wars dla designerów tak samo jak dla AI researcherów – to firmy, które wygrają
Figma zmierza w kierunku przyszłości, gdzie punkty styku są wszędzie, nie tylko na figma.com – integracje z ChatGPT, MCP i partnerstwa to początek
Field nadal testuje produkty w noce i weekendy, jailbreakuje modele AI i dedykuje wtorki oraz czwartki na product days

Tuż po blockbusterowym IPO Figmy, zaprezentowaniu Figma Make i kolacji z prezydentem, Dylan Field pojawił się na konferencji produktowej. Rozmowa z Carlosem ujawniła coś ciekawego – gdy wszyscy mówią o AI, Field mówi o designie.

Nie chodzi tu o wybór między jednym a drugim. Chodzi natomiast o zrozumienie, że w momencie, gdy software robi się trywialnie łatwy do stworzenia, design staje się głównym polem bitwy. Ta filozofia ma swoje korzenie w pierwotnej wizji Figmy z 2012 roku: zlikwidować przepaść między wyobraźnią a rzeczywistością. Dziś, w erze AI, ta misja nabiera zupełnie nowego znaczenia.

Community jako fundament, nie dodatek

Field zaczynał bez community. Miał produkt i desperacką chęć, żeby wejść do świata designu. Wysyłał cold emaile do ludzi, których idolizował. Designers w Silicon Valley odpowiadają – to efekt kultury „pay it forward”, jak ją nazywa.

Te pierwsze spotkania były brutalne. Najlepsi designerzy siadali z nim i dosłownie rozrywali produkt na strzępy. Mówili mu wszystko, co musi naprawić. Field opisuje to jako błogosławieństwo i prezent.

Ta kultura feedbacku została wbudowana w DNA Figmy. Mimo że teraz Field nie zawsze jest w stanie odpowiadać na wszystkie wiadomości, bardzo się stara. Zespół patrzy na feedback z email, social media i forum.

Gdy Field podróżował z ówczesną dziewczyną, obecną żoną, organizował Figma meetupy w każdym miejscu, gdzie się znaleźli. Dosłownie w każdym – holiday w innym kraju? Meetup dla lokalnych użytkowników. Singapur, Bangkok, kraje Europy – nie miało znaczenia gdzie, zawsze spin’ował spotkanie dla społeczności.

Te spotkania pokazały coś kluczowego. Potrzeby użytkowników są radykalnie różne w zależności od regionu. W Azji Południowo-Wschodniej lokalizacja stringów pojawiła się od razu jako priorytet, natomiast w US dziesięć lat temu nikt o tym nie myślał.

Field podkreśla jedną rzecz ponad inne – trzeba rozmawiać z ludźmi jeden na jeden, nie w grupach. Na prezentacjach i demo pokazujesz features i przekonujesz, jednak w rozmowie jeden na jeden naprawdę zagłębiasz się w kontekst.

Dlaczego „wystarczająco dobre” już nie wystarcza

Field używa tego stwierdzenia świadomie. Brzmi jak prowokacja, ale opiera się na konkretnej tezie.

Design jest na szczycie value stack dla software’u. To przekonanie towarzyszy Figmie od dekady, jednak teraz staje się oczywiste dla wszystkich.

Mark Andreessen napisał w 2011 „Software is eating the world”. Ta krzywa eksponencjalna od tamtego czasu tylko się nasiliła. Teraz, z AI, krzywa nie jest już eksponencjalna – poszła w pionie.

Software jest łatwiejszy do stworzenia niż kiedykolwiek. Co to oznacza dla wyróżnienia się na rynku? Jak wygrać?

Field odpowiada wprost: design, craft, punkt widzenia. Plus brand i marketing, które muszą ze sobą współgrać.

Product manager czy designer musi rozumieć kilka rzeczy jednocześnie:

Business constraints i cele
Sposób działania brandu i punkt widzenia firmy na swoją przestrzeń
Kulturę obecnego momentu
Konkretne flows, nad którymi pracuje

To wszystko musi połączyć się w system. Następnie trzeba to wyartykułować w sposób, który jest radosny i wspaniały dla użytkownika.

Jeśli tego brakuje, nie wygrasz. Design jest tym, jak wygrywa się lub przegrywa, dlatego każdy w procesie product development musi dbać o design.

Brand to nie logo, lecz każdy punkt styku

Field używa Airbnb jako przykład firmy, która naprawdę przemyślała experience design. Od brandu, który widzisz wszędzie, przez support tickets, po platformę produktową i doświadczenie hosta.

Łatwo myśleć o brandzie tylko jako o logo, jednak to nie o to chodzi. Brand to każdy punkt styku z firmą. Wszystko musi czuć się jak ten sam język, ten sam głos.

Field daje mocną metaforę. Gdyby pojawił się dzisiaj w złoto-fioletowej szacie ze zwisającymi frędzlami, ludzie pomyśleliby: „Co się dzieje z Dylanem?” – zakładając, że spotkali go wcześniej i wiedzą, jak się normalnie ubiera.

Pytanie brzmi: ile naszych produktów pojawia się jakby w koszulce i spodniach dresowych w jednym miejscu, a w smokingu gdzie indziej?

Konsystencja jest kluczowa. Trzeba zaplanować całą podróż – gdzie ludzie pierwszy raz wchodzą w interakcję z Tobą? Jakie są kluczowe momenty? To wymaga przemyślenia.

Figma Make i nowa rzeczywistość product managementu

Statystyka, która zaskakuje. Dwie trzecie użytkowników Figmy to nie-designerzy. To radykalnie zmienia sposób myślenia o tym, czym jest „design tool”.

Field widzi Figma Make jako sposób na zmianę dynamiki między PM a designerem. Tradycyjnie PM przychodzi do designera z prośbą o mockup flow, a następnie dostaje jakąś wersję tego, co miał w głowie.

Teraz PM może spędzić dwadzieścia minut w Figma Make i zrobić cztery eksploracje. Cztery różne pomysły przynosi do stołu, po czym razem z designerem decydują, który refinować.

Kluczowe słowo: wiarygodność. To, co PM stworzy w Make, nie będzie miało najwyższego kunsztu, jednak będzie wiarygodne. Ludzie nie odrzucą pomysłu, bo „nie wygląda dobrze” – ocenią go na własnych zasadach.

Field testuje modele AI nieustannie. Ma dziwne hobby – jailbreakuje je, próbując zmusić modele do mówienia dziwnych rzeczy. Wysyła feedback do labs, które odpowiadają: „Oh, dziękujemy. To dziwne.”

Ale Field uczy się z tego masę. Dostając modele w różne „headspaces”, odkrywa lekcje, które można zastosować do profesjonalnego promptowania.

Gdy modele się poprawiają, Make się poprawia. To stark różnica – poprawa modelu przekłada się bezpośrednio na poprawę produktu.

Cel końcowy? Figma Make i Figma Design jako dwie strony tej samej monety. Teraz można robić szczegółowe edycje w Design, kopiować do Make, wklejać z powrotem, refinować i wrzucać do prompt. Ale to nie jest jeszcze płynne.

Field wie, że ludzi nie obchodzą szczegóły techniczne – chcą, żeby to działało perfekcyjnie. I na to zasługują.

Jak Figma myśli o AI: użyteczność albo nic

Field jest bardzo wyraźny w swojej filozofii wobec AI. Powtarza to zespołowi do punktu, gdzie są już zmęczeni słuchaniem tego.

Była era w Silicon Valley – może nadal trwa – gdzie wszyscy mówili o posypywaniu produktów magicznym pyłem AI dla lepszej sprzedaży. Figma nie chciała być w tym świecie.

Zasada jest prosta: albo tworzysz użyteczność, albo nie wypuszczasz produktu.

Trzeba trzymać wysoki standard. Rzeczy się zmieniają – jak modele się poprawiają, ten standard może iść w górę. Wtedy trzeba ponownie ocenić sytuację. Czy zabijasz feature? Czy go wycofujesz? To są rozmowy, które Figma prowadzi.

Zakładając, że rzeczy są dobre i dodają wartość, zachęta musi być wyrównana dla wszystkich stron: dla Figmy, dla użytkownika i dla ludzi w procurement, którzy dbają o przewidywalne budżety.

Trzeba sprawić, żeby wszyscy byli zachęcani do używania AI więcej, jeśli to tworzy wartość. Jeśli nie można dojść do tego systemu zachęt, prawdopodobnie coś poszło nie tak.

Field wprowadził model kredytowy dla AI – ogłoszony, ale jeszcze nie wymuszany. Dlaczego? Dopracowanie szczegółów i upewnienie się, że systemy rozliczeniowe działają perfekcyjnie, to większe zadanie niż można by oczekiwać. Zespół rozliczeniowy jest świetny, jednak to po prostu zajmuje czas.

Strategie pracy z AI według Dylana Fielda

Choć Field nie podaje gotowych promptów, dzieli się kilkoma strategicznymi podejściami do pracy z AI, które wynikają z jego doświadczeń.

Prompt iteracyjny (obraz + tekst)

To proces, w którym generujesz coś w narzędziu AI, następnie kopiujesz wynik do edytora, ręcznie dopracowujesz detale, a na koniec wklejasz ten poprawiony obraz z powrotem do AI jako część nowego promptu. Field opisuje dokładnie ten flow między Figma Make a Figma Design.

Kiedy stosować: Gdy chcesz udoskonalić wygenerowany przez AI koncept, dodając mu ludzkiego szlifu i precyzji, a następnie kontynuować generowanie w oparciu o tę lepszą, bardziej dopracowaną wersję.

Prompt wymuszający proces i rozumowanie

Field wspomina o tym, jak ważne jest „get a model to follow a process with reasoning and thinking” – czyli konstruowanie promptów tak, aby zmusić model do podążania za określonym procesem myślowym, krok po kroku.

Kiedy stosować: Przy złożonych zadaniach, gdy chcesz uzyskać bardziej logiczny, ustrukturyzowany i mniej przypadkowy wynik. Pomaga to modelowi „zastanowić się”, zanim wygeneruje ostateczną odpowiedź.

Prompt-polecenie w gotowym kontekście

W kontekście integracji z ChatGPT, Field mówi o prostych komendach typu „make this a diagram” – krótkie, bezpośrednie polecenia działają, gdy AI ma już pełen kontekst Twojej pracy.

Kiedy stosować: W środowiskach, gdzie AI ma już pełen kontekst Twojej pracy (np. w trakcie rozmowy z chatbotem, który ma dostęp do Twoich dokumentów). Wtedy nie ma potrzeby opisywać wszystkiego od nowa, wystarczy wydać zwięzłe polecenie.

Prompt eksploracyjny (jailbreaking)

Field celowo testuje granice modeli, zmuszając je do „dziwnych rzeczy”. To nie jest technika do pracy produkcyjnej – stosuje się ją w celach edukacyjnych.

Kiedy stosować: Aby zbudować głębszą intuicję i zrozumieć, jak model „myśli”. Dostając modele w różne „headspaces”, odkrywasz lekcje, które potem można zastosować do profesjonalnego promptowania. To nauka przez eksperymentowanie z granicami.

Punkty styku są wszędzie, nie tylko na figma.com

Field ma wyraźną intuicję co do przyszłości. AI zmieniło sposób, w jaki trzeba myśleć o punktach styku jako software business.

Punkt styku to nie jest już tylko Twoje własne doświadczenie na yourcompany.com, lecz wszędzie, gdzie ludzie mogą wchodzić w interakcję z produktem.

Dla Figmy oznacza to kilka rzeczy. Najpierw MCP – use case jest oczywisty. Jesteś w Figma Design, chcesz coś zbudować, masz Dev Mode. Jeśli plik jest dobrze ustrukturowany, klikasz, pullujesz z MCP i budujesz front-end znacznie szybciej.

Potem connectors w Make – Notion data, Atlassian, Jira, Linear. Gdy można pullować dane z różnych miejsc, proces kreacji staje się obiektywnie bardziej pomocny.

Integracja z ChatGPT to kolejny krok. Field mówi o tym jako o bardzo szczęśliwej ścieżce. Jesteś w ChatGPT, masz zbudowany kontekst, konwertujesz go w artifact. Mówisz „zrób z tego diagram” i pojawia się Fig Jam. Możesz iterować, promptować Fig Jam, otwierać w Figma na platformie, zapisywać, udostępniać.

Może nigdy nie zobaczysz danych, a może będziesz robić rozszerzone edytowanie. Może jesteś użytkownikiem Figmy, a może nie – nie ma to znaczenia.

Field powtarza to kilka razy w rozmowie: ludzie muszą zmienić sposób myślenia. Punkty styku, na których pojawia się produkt, mogą być wszędzie.

Figma jest teraz bardzo otwarta na partnerstwa, robiąc ich tyle, ile może – o ile setup i user experience są dobre.

Od „nudnego” do „wspaniałego” w jeden dzień

Historia powstania Fig Jam pokazuje coś ważnego o tym, jak Figma podchodzi do produktu.

Field argumentował latami, że potrzebują powierzchni do whiteboarding, brainstorming i diagramowania. Widział te use case’y w Figma Design, jednak wszyscy odpowiadali: „To miłe, Dylan. Mamy ogromny backlog próśb klientów i rzeczy do naprawienia.”

Przyszło COVID. Ludzie zaczęli zmieniać zachowanie w Figmie. Któregoś dnia Slack padł – ludzie zaczęli pisać w text boxach w Figmie, odpowiadając sobie nawzajem przez text boxy. Field pomyślał: „Co się dzieje? To nie jest to, na co zaprojektowaliśmy Figma Design.”

Ludzie zaczęli się po prostu spotykać. Wszyscy w sheltering in place, nie mogąc być razem. Rysowali wspólne miasta w Figma Design – nie tylko w swoich firmach, ale między firmami. Team hangouts w Figma Design przez multiplayer.

Moment się zmienił. Prośby o wsparcie spikowały, więc Field powiedział: „Zróbmy nową powierzchnię.”

Build był szybki – pięć, sześć miesięcy. Miesiąc przed launchem zespół spojrzał na produkt – brakowało mu duszy. Był dość nudny i niezdifferentiated.

Field zwołał meeting, ale nie zwykły – wciągnął zespół i board razem. Board był wtedy mniejszy, więc łatwiej było to skoordynować, jednak traktowano to jako podstawowe strategiczne pytanie dla firmy.

Field przedstawił różne pomysły, jak mogą się różnicować. Jeden z nich był „zabawa” – Field był szczery, że to był jego punkt widzenia, ale nie wszyscy byli na tej samej stronie.

Rozmawiali przez wszystkie opcje. Na końcu wszyscy wyszli z przekonaniem: „Okej, zabawa jest naszym differentiatore.”

Zespół był sceptyczny, ale poszli z tym. Zrobili design sprint – jeden dzień. Z tego dnia wyszło może dwadzieścia do dwudziestu pięciu pomysłów, a zbudowali cztery albo pięć z nich.

Co wyszło z tego jednodniowego design sprintu:

Stamping reactions
Cursor chat
Music player
Timery, które są zabawne i interesujące w swoim działaniu

Jedyne objective na ten dzień dla design teamu było: „Wymyślcie, jak sprawić, żeby Fig Jam był zabawny.”

Field przypisuje sukces dwóm rzeczom. Po pierwsze, kreatywność zespołu jest niesamowita – mają wspaniałych ludzi. Po drugie, jasny cel i ograniczony czas. Wszyscy w jednym Zoomie, w jednym Figma Design file’u razem. Te mechanizmy pomogły to osiągnąć.

Produkt przeszedł od „ah, w porządku” do „całkiem wspaniały”.

Field dodaje jeden szczegół. Jego ulubiony feature: jak machasz kursorem w Fig Jam, robi on kształt zwiotczałej dłoni. Możesz dać piątkę innym ludziom.

Maker Week i innowacja oddolna

Figma nie dodaje produktów bez powodu. Każdy produkt, który wprowadzili na platformę, to jakiś use case, który już widzieli.

Figma Slides to dobry case study. Figma zawsze robiła własne prezentacje w Figmie – od początku, zanim to miało sens. Dog fooding non-stop.

W którymś momencie spojrzeli na liczby. Pięć procent plików tworzonych w Figma Design to slides. To jest dosłownie tak duże, że zasługuje na własną powierzchnię produktową.

Ale nie zrobili tego top-down. Maker Week – tydzień, w którym cała firma robi jedno: „Spraw, żeby Figma była lepsza w jakiś sposób.” Nazywają to Maker Week zamiast hack week, bo to cała firma.

Jeden z zespołów stworzył Figma Slides w Maker Week. Nie było to gotowe do wysyłki, jednak to, co widać dzisiaj, to podzbiór tego, co pokazali wtedy – ich myślenie było tak ekspansywne.

Energia wokół tego była ogromna. Field był sceptyczny – „musimy skupić się gdzie indziej” – ale to po prostu się stało. Bardzo szybko mieli launched Slides.

Ciekawostka: nazwa kodowa projektu to był „slides Figma slides slides”. Field powiedział: „nie nazwiemy tego flies”. Mika, PM projektu, upewniła się, że to było w keynote i utrwaliła to jako mem – pokazuje kulturę zespołu.

Podobnie Dev Mode. Developerzy na platformie nie byli tak szczęśliwi jak designerzy – był widoczny spread w NPS między tymi grupami.

Figma miała hipotezę, dlaczego tak jest i co z tym zrobić. Hipoteza była błędna, więc zrobili głębokie badanie: czego developerzy naprawdę potrzebują?

Badanie pokazało coś niespodziewanego:

Developerzy nie lubią nieskończonego płótna (rdzennego prymitywu Figma Design)
Nie zawsze wiedzą, co budować, a czasami budują złe rzeczy
Potrzebują dostępu do swoich narzędzi, kontekstu i informacji wewnątrz tego środowiska

Field podkreśla lekcję: możesz mieć założenia o odbiorcy, ale nie zawsze są dobre. Zawsze trzeba sprawdzać.

Ostatnio wprowadzili też Figma Buzz (produktywizacja assetów), Figma Draw (edycja wektorowa) oraz Figma Sites (dotarcie do wysłanej aplikacji lub strony).

Różne produkty wymagają różnych miar sukcesu

Field zwraca uwagę na coś ważnego – nie można oceniać wszystkich produktów tymi samymi miarami.

Fig Jam ma inną krzywą wzrostu niż Figma Design. Use case jest inny – nie brainstormujesz z zespołem codziennie. Figma Design? Jeśli jesteś designerem albo PM robiącym zadania designerskie, możesz być tam cały dzień. Fig Jam? To rzadkość.

Trzeba myśleć o każdym produkcie trochę inaczej i rozumieć mechanikę tego, jak są używane – dopiero wtedy można ocenić, jak dobrze działają.

Ale trzeba też wchodzić w szczegóły. Dla Fig Jam, jeśli jesteś PM albo researcherem próbującym zaprosić dużo ludzi do swojej przestrzeni, potrzebujesz sposobu na to bez zmuszania ich do tego samego procesu onboardingu. Jednocześnie trzeba spełnić potrzeby enterprise – żeby mogli to zablokować, jeśli chcą.

Trzeba rozumieć niestandardowe wymagania tego, co budujesz. Każdy produkt jest inny – jak Figma obejmuje więcej person i więcej przypadków użycia w cyklu życia designu, muszą być krystalicznie jasni zarówno po stronie produktu, engineeringu, jak i designu.

Field wspomina też o czymś strategicznym. Teraz robią cell splits – biorą jeden produkt i wyciągają przypadki użycia do nowych powierzchni. To jedna rzecz.

Ale Field wie, że w pewnym momencie będą robić cell merge – niektóre powierzchnie, które mają, będą musiały połączyć się jako workflows, gdy ekosystem się zmienia. To będzie coś, przez co będą musieli przejść.

Jak CEO chroni czas na bycie w produkcie

Field jest szczery: „Nie jestem Twoim źródłem zarządzania czasem.” Jeśli ktoś ma dobre wskazówki, chętnie posłucha.

Ale uważa, że to konieczne. Próbuje robić wtorki i czwartki jako dedykowane dni produktowe – czasami to rozlewa się na inne dni. Czasami są cykle z dużą ilością podróży, wtedy jest bardziej ad hoc.

Spędzanie czasu z zespołem, zagłębianie się w rzeczy – to się dzieje w te dni. Faktyczne budowanie i testowanie – to często noce i weekendy.

Jeśli nie używasz produktu – i to nie tylko w sposób naturalny dla ciebie, ale w sposób, w jaki inni go używają – nie budujesz intuicji potrzebnej do dawania dobrego feedbacku zespołowi.

Field pokazuje przykład z niedawnego off-site dla design managerów – dosłownie półtorej godziny przed rozmową z Carlosem. Był pod wrażeniem ich pracy nad zwiększaniem własnej efektywności.

Jeden design manager pokazał workflow: może uruchomić zdalnego agenta na serwerze. Ten agent alertuje go, gdy zadania trwają długo albo jest jakiś problem w grafie zależności. Rzeczy, które normalnie musiałby przeszukiwać przez systemy, są teraz zautomatyzowane – ma agentów, którzy alertują go cały czas.

Field widzi masę możliwości teraz, jednak nie są one równomiernie rozłożone. Wszyscy uczą się tych przepływów pracy.

Jest podekscytowany tym, jak product managerowie będą mogli dzielić się większą ilością pomysłów jako część procesu designu. Bo teraz PM może spędzić dwadzieścia minut w Figma Make, zrobić cztery eksploracje, przynieść je do stołu i razem z designerem zdecydować: który refinujemy, jak daleko możemy to posunąć.

Wojny talentów i kto wygra

Field mówi coś mocnego – widzi rozkład w rynku dosłownie wszędzie.

Są ludzie, którzy dopiero próbują zrozumieć: jak zbudować zespół designerski? Co to jest system designu? Jakie są najlepsze praktyki?

Na drugim końcu? Executives i CEOs, którzy prowadzą wojny talentów o design tak samo jak o badania AI.

Ci founderzy i CEOs, którzy tak bardzo wartościują design, że robią designerów kluczowymi liderami obok produktu. Upewniają się, że ludzie będący orędownikami wielkiego kunsztu są tymi, którzy kształtują roadmap i przyszłość produktu.

Field jest bardzo optymistyczny co do nich – wie, kim są. Naprawdę myśli, że wygrają, a ich konkurencja jest w tyle.

Mówi to wprost do product leaderów i CEOs: musicie być orędownikami głosu designu, niezależnie od tego, skąd ten głos pochodzi. Inaczej jesteście w trudnej sytuacji.

Jeśli to nie jest organizacja, w której jesteś teraz – jeśli są ograniczenia działające przeciwko tobie – musisz to naprawić albo może znaleźć inną organizację.

Przyszłość interfejsów: era post-promptowa

Field używa mocnej metafory – jesteśmy w erze MS-DOS AI, gdzie prompt jest wszystkim.

Model to jakiś statek kosmiczny. Masz sposób, żeby z nim wchodzić w interakcję – Twój prompt to może kompas. Ale ten kompas ma nieznaną, bardzo dużą liczbę wymiarów.

Jak używać kompasu z n wymiarami? Najlepsze narzędzie teraz: język.

Ale jeśli patrzysz na konkretny przypadek użycia i znasz zakres tego, co ludzie próbują zrobić – jeśli naprawdę studiujesz, jak promptują i obserwujesz ich zachowanie – jest to bardzo różnorodne.

Pytanie brzmi: jak sprawić, żeby można było eksponować konkretny przypadek użycia przez interfejs, gdzie jest bardziej intuicyjny sposób sterowania tym statkiem kosmicznym?

Field uważa, że to niezbadane terytorium – nie widział nikogo, kto robi tam postępy. Wie jednak, że to nadchodzi i jest podekscytowany, żeby eksplorować to w Figmie.

Ale też musimy spotykać ludzi tam, gdzie są. Więc nie jest pewny, kiedy to przyjdzie – dla Figmy, dla innych.

Jest bardzo podekscytowany innowacjami interfejsów, które wystąpią na warstwie promptowania i warstwie agentów. Nawet nie wie, czy agenci będą „warstwą” – może będą po prostu obok.

Ogólnie: wszystkie powierzchnie, które będą musiały być zaprojektowane i przemyślane jako część ogólnego systemu dla produktu. Jak ludzie będą poruszać się po tych wyzwaniach i jak Figma może im pomóc.

Checklist: Czy design ma szansę wygrać w Twojej organizacji?

Użyj tego jako szybkiego audytu swojej sytuacji:

Fundament:

Designerzy mają miejsce przy stole przy decyzjach o roadmap
Product managerowie regularnie używają narzędzi designerskich (nie tylko „proszą o mockupy”)
Zespół ma ustalone pętle feedbacku z użytkownikami
System designu istnieje i jest aktywnie utrzymywany

Kultura:

CEO/Leadership publicznie mówi o designie jako przewadze strategicznej
Design reviews są traktowane jako ważne jak business reviews
Zespół ma czas na eksplorację i iterację (nie tylko „ship fast”)
Zabawa, radość i kunszt są częścią rozmowy, nie „nice to have”

Proces:

PM mogą prototypować pomysły samodzielnie przed zaangażowaniem designera
Zespół obserwuje jak ludzie „hackują” produkt i traktuje to jako insights
Macie dedykowany czas na innowacje (jak Maker Week)
Research z użytkownikami kwestionuje założenia, nie tylko je potwierdza

Red flags (jeśli to widzisz, masz problem):

Design jest wąskim gardłem, nie partnerem
Decyzje o design są nadpisywane przez „po prostu wysyłaj”
Designer jest jeden na 10+ inżynierów
Nikt poza designerami nie mówi o user experience

Jeśli zaznaczyłeś mniej niż połowę z Fundament + Kultura, Field powiedziałby: „Musisz to naprawić albo może znaleźć inną organizację.”

Co to oznacza dla Ciebie

Jeśli jesteś product managerem: Naucz się podstaw narzędzi designerskich – nie musisz być designerem, jednak musisz móc samodzielnie eksplorować przestrzeń opcji. Dwadzieścia minut w narzędziu typu Figma Make może zmienić całą rozmowę z Twoim designerem.

Jeśli jesteś CEO/founderem: Zapytaj siebie: czy prowadzę wojnę talentów o design tak samo jak o engineering? Jeśli nie, Twoja konkurencja prawdopodobnie Cię wyprzedza. Design nie jest już differentiatorem – to wymóg.

Jeśli budujesz funkcje AI: Przyjmij filozofię Fielda – albo tworzysz użyteczność, albo nie wysyłasz. Nie posypuj magicznym pyłem AI. Trzymaj wysoki standard, a jak modele się poprawiają, ten standard idzie w górę. Ponownie oceniaj funkcje, które nie dodają wartości.

Jeśli budujesz community: Cold emaile działają, meetupy działają. Ludzie odpowiadają, jeśli jesteś autentyczny. Nie czekaj, aż będziesz „wystarczająco duży” – Field robił to od początku, organizując spotkania dosłownie w każdym miejscu, gdzie podróżował.

Jeśli myślisz o brandzie: Brand to nie logo, lecz każdy punkt styku. Sprawdź, czy Twój produkt nie pojawia się w koszulce i spodniach dresowych w jednym miejscu, a w smokingu gdzie indziej. Konsystencja jest wszystkim.

Jeśli myślisz o AI: Nie myśl o AI jako o zastępstwie dla designu. Myśl o AI jako o rzeczy, która sprawia, że design jest jeszcze ważniejszy – bo gdy wszyscy mają dostęp do generowania, kunszt jest tym, co różni dobry produkt od przeciętnego.

Jeśli patrzysz na swój produkt: Obserwuj, jak ludzie go „hackują”. Używają go w sposób, którego nie planowałeś? To nie bug – to roadmap zapisana w zachowaniu użytkownika.

Ostatnia rzecz: Field mówi coś, co brzmi surowo, ale jest uczciwe. Jeśli jesteś w organizacji, gdzie design nie ma głosu, gdzie kunszt nie jest ceniony, gdzie „wystarczająco dobre” jest akceptowane – musisz to naprawić albo wyjść.

Bo firmy, które to rozumieją, już wygrywają, a przepaść będzie się tylko powiększać.

Kluczowy insight

Nadużycie to prośba o funkcję

Standardowo myślimy: Gdy użytkownicy używają naszego produktu w sposób, którego nie przewidzieliśmy, to problem z UX. Trzeba to naprawić, edukować użytkowników, dodać onboarding, zablokować nieprawidłowe użycie.

W praktyce okazuje się, że: Gdy Slack padł, ludzie zaczęli pisać w text boxach w Figmie i odpowiadać sobie nawzajem. Rysowali wspólne miasta, robili team hangouts. Carlos tworzył zaproszenia kalendarzowe w Figmie przed Fig Jam. Field nie widział tego jako nadużycia ani porażki – widział to jako sygnały. Prośby o wsparcie spikowały i pokazały mu, że potrzebują Fig Jam. Pięć procent plików to były slides, co pokazało, że Figma Slides zasługuje na własną powierzchnię.

Dlaczego to jest istotne: Użytkownicy pokazują Ci przyszłość produktu przez to, jak go łamią. Eksperymentują z granicami nie dlatego, że są uparci, lecz dlatego że mają rzeczywistą potrzebę, której Twój produkt jeszcze nie spełnia. To jest roadmap zapisana w zachowaniu, nie w odpowiedziach na ankiety czy prośbach o funkcje.

Test na jutro: Następnym razem gdy zobaczysz w analytics, że ludzie robią coś „dziwnego” z Twoim produktem, zamiast to blokować lub ignorować, spróbuj przez tydzień zbierać wszystkie przypadki użycia niezgodnego z przeznaczeniem. Zrób listę, a następnie zapytaj trzech takich użytkowników, dlaczego tak robią. Sprawdź, czy ten „bug” to nie jest Twój najbliższy produkt w oczekiwaniu na odkrycie.

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 w nagraniu Product Podcast z konferencji.

Tag: Carlos Product Podcast

Dylan Field o tym, dlaczego „good enough” już nie wystarcza #EN318