Poniższy tekst to zestaw notatek z rozmowy Jay’a z Andreą, Staff Designer w Lattice, opublikowanej w podcaście Sneak Peek. Wszystkie metody, obserwacje i przemyślenia przedstawione w artykule pochodzą bezpośrednio od rozmówców i opisują ich doświadczenia w pracy nad design discovery i facilitation w środowisku enterprise.

TL;DR

Design sprints mogą trwać 1 godzinę zamiast 5 dni – Andrea z Lattice pokazuje, jak timeboxing i dobre przygotowanie pozwalają na szybkie alignment
Design brief w 1-2 godziny – tłumaczenie technicznego PRD na język designu z jasnym fokusem na user problem, nie na solution
Async team audit – zamiast długich spotkań, zespół dostaje przygotowany board z screenshotami i wypełnia go we własnym tempie
Eisenhower Matrix + MoSCoW – dwa frameworki priorytetyzacji, które dają designerom realny wpływ na roadmapę produktową
Inversion exercise – brainstorming „złych rozwiązań” pomaga wyjść z tunelu jednego pomysłu i otworzyć dyskusję
Research synthesis bez friction – zamiast zmuszać zespół do oglądania godzin wywiadów, Andrea robi „hard work” i przygotowuje stickies + krótkie video clips
Designer jako facilitator – prowadzenie warsztatów, zadawanie pytań i współtworzenie strategii produktowej z PM i engineering

Większość artykułów o design discovery pokazuje idealne procesy z podręczników. Wielodniowe design sprints, rozbudowane research plany, niekończące się warsztaty. Andrea, Staff Designer w Lattice, robi to inaczej – wszystko w godzinę.

Jej podejście łamie klasyczne schematy. Zamiast 5-dniowych sprintów Google stosuje godzinne sesje. Zamiast tygodni research – konkretne pytania i szybkie wnioski. Zamiast hierarchii – cross-functional collaboration na równych zasadach.

Design discovery – od PRD do design brief

Czym jest design discovery dla Andrei

Według Andrei, design discovery to przede wszystkim zrozumienie problem space. Praca z product managerem nad tym, w co dokładnie zespół chce się zagłębić. To moment, kiedy designer nie skacze od razu do Figmy i ekranów, jednak najpierw definiuje, jaki problem rozwiązuje.

W Lattice proces wygląda następująco: PM przychodzi z lżejszą wersją PRD. Dokumentacja jest bardziej techniczna, dlatego Andrea bierze ten dokument i tłumaczy go na język designu.

Design brief w 1-2 godziny

Andrea stworzyła szablon design brief – jednostronicowy dokument, który pomaga jej się zorientować w projekcie. Jak podkreśla, nie odpowiada na wszystkie pytania od razu, a raczej traktuje to jako sposób na ogarniecie tematu.

Dokument koncentruje się na użytkowniku i user problem. Andrea wypełnia go w godzinę lub dwie, cały czas konsultując się z PM przez Slack. PRD leży obok w drugim oknie, jednak brief nie jest jego kopią – to tłumaczenie technicznych wymagań na język designu.

Co zawiera ten brief? Purpose dokumentu (żeby wszyscy wiedzieli, że to nie PRD), project overview i uzasadnienie jego ważności, user problem (nie solution), assumptions, dependencies oraz risks. Dodatkowo Andrea uwzględnia istniejące patterns w produkcie, poprzednie próby rozwiązania problemu i high-level pomysły typu „How Might We solve this?”

Patrzenie wstecz – co próbowaliśmy wcześniej

Jeden z kluczowych elementów procesu Andrei to sprawdzanie, czy firma już wcześniej próbowała rozwiązać dany problem. W wielu przypadkach okazuje się, że próbowano kilka lat temu, dlatego Andrea wykopuje stare artefakty, analizuje co działało i dlaczego projekt porzucono.

Takie działanie pozwala uniknąć powielania błędów i czerpać z wiedzy instytucjonalnej firmy. Następnie przegląda istniejące wzorce w produkcie. Sprawdza, czy są miejsca, gdzie zespół rozwiązuje podobny problem. Robi screenshoty i układa je obok siebie – to pomaga myśleć systemowo.

Checklist: Twój design brief

Zanim przejdziesz do designowania, upewnij się, że masz odpowiedzi na te pytania:

Problem space:

Jaki user problem rozwiązujemy? (nie solution, problem)
Dlaczego to ważne dla użytkownika i biznesu?
Jakie założenia robimy? Co może pójść nie tak?

Context i historia:

Czy próbowaliśmy już rozwiązać ten problem wcześniej?
Gdzie w produkcie już rozwiązujemy podobne problemy?

Alignment:

Czy PM widzi to tak samo jak ja?
Czy ten brief jest shared z zespołem?

Design sprints – krótko i na temat

Godzina zamiast pięciu dni

Andrea prowadzi design sprints, które trwają maksymalnie godzinę. Nie wielodniowe maratony, nie tygodniowe bloki w kalendarzu – jedna intensywna godzina i zespół idzie dalej.

Jeśli zespół czuje, że nie skończył, Andrea planuje kolejną godzinę, jednak w innym dniu. Ta przerwa pozwala wszystkim nabrać dystansu.

Według Andrei, godzinne sesje są energetyzujące. Wszyscy wiedzą, że mają 60 minut, więc po prostu działają. Każdy wnosi coś do dyskusji, a przegadanie praktycznie nie istnieje.

Kiedy warto zorganizować design sprint

Andrea organizuje design sprint, kiedy chce:

Przyciągnąć inne dyscypliny do stołu (szczególnie engineerów)
Dostać pomysły z perspektywy technicznej
Sprawić, żeby zespół poczuł pain point użytkowników
Zrobić alignment na scope i czasie
Wyjść poza jeden pomysł i otworzyć przestrzeń do innych rozwiązań

Spotkania te mają podwójny cel: nie tylko generowanie pomysłów, ale przede wszystkim budowanie empatii. W przypadku projektu „data check” problem był jasny. Zespół nie potrzebował user research – to był oczywisty pain point w UI, jednak Andrea chciała, żeby engineers zrozumieli user problem i pomogli w solutioningu.

Odkrycie inconsistency – bonus z design sprintu

Podczas tego design sprintu wydarzyło się coś niespodziewanego. Zespół zaczął patrzeć na istniejące patterns w Lattice i okazało się, że data check istnieje w trzech różnych miejscach produktu – za każdym razem wygląda inaczej. Ten sam problem, trzy różne rozwiązania.

To wywołało większą dyskusję. Może zamiast robić kolejny sposób, powinni stworzyć unified data check pattern? Coś, co można by używać wszędzie w Lattice. Andrea zawsze wraca do systems thinking – kiedy widzi problem, pyta się: gdzie indziej w produkcie to robimy? Czy możemy to zrobić spójnie?

To pokazuje siłę design sprintów z cross-functional teamem. Engineers wiedzieli o tych innych miejscach, dlatego bez nich Andrea mogłaby nie odkryć tej inconsistency.

Cross-functional collaboration – dlaczego to działa

Kiedy engineers przychodzą na design sprint i rozumieją user problem, ich pomysły są o wiele lepsze. Jak zauważa Andrea: „Kiedy rozumieją problem użytkownika, dostajemy lepsze pomysły, niż gdy go nie rozumieją.”

Engineers widzą problem przez pryzmat technologii. Mówią „a co z tym?”, „możemy to zrobić inaczej”. To perspektywa, której designer sam by nie wymyślił. Dodatkowo, kiedy developer pomaga stworzyć rozwiązanie, jest bardziej zmotywowany do jego wdrożenia.

Co z zespołami, które nigdy nie używały FigJam? Andrea ma szczęście – jej zespół już wcześniej robił retrospektywy w FigJam, w rezultacie znali podstawy: nawigację, sticky notes, głosowanie, grupowanie. Według Andrei, FigJam jest dość intuicyjny, dlatego jeśli zespół wcześniej nie miał kontaktu z narzędziem, pokazuje basics – to nie rocket science.

Checklist: Jak przygotować i przeprowadzić jednogodzinny sprint

Poniższa checklista została stworzona na podstawie metod pracy Andrei i może posłużyć jako wzór do organizacji własnych, szybkich warsztatów.

Przygotowanie (przed sprintem):

Zdefiniuj cel – co dokładnie chcesz osiągnąć w ciągu tej godziny?
Przygotuj brief projektowy – stwórz jednostronicowe podsumowanie problemu, celów i założeń
Przygotuj tablicę w FigJam – dodaj agendę, brief, wizualizację obecnego procesu i puste ramki na ćwiczenia
Wyślij materiały do przeczytania – poproś uczestników o zapoznanie się z założeniami przed spotkaniem
Zaproś kluczowe osoby – upewnij się, że na spotkaniu będą przedstawiciele różnych ról (design, product, engineering)

Przebieg (podczas sprintu – 60 minut):

Wprowadzenie i kontekst (5-10 min) – krótko przedstaw problem i cel spotkania
Prezentacja problemu (10 min) – omów obecny stan, pokaż zrzuty ekranu, zidentyfikuj słabe punkty
Główne ćwiczenie (15-20 min) – przeprowadź sesję „How Might We”, Inwersji lub szybkiego szkicowania
Grupowanie i dyskusja (15 min) – wspólnie pogrupujcie wygenerowane pomysły i omówcie najważniejsze tematy
Podsumowanie (5 min) – podsumujcie kluczowe wnioski i ustalcie kolejne kroki

Po sprincie:

Zsyntetyzuj wyniki – zbierz notatki i najważniejsze ustalenia z tablicy w jednym miejscu
Udostępnij podsumowanie – wyślij krótką notatkę do wszystkich uczestników i interesariuszy

Warsztaty i ćwiczenia facilitacyjne

Inversion exercise – brainstorming złych rozwiązań

Andrea natknęła się na sytuację, w której zespół za szybko wskoczył w konkretne rozwiązanie. Wszyscy wiedzieli „jak” to zrobić, jednak problem był za wąski. Trudno było myśleć outside the box.

Projekt dotyczył error handling. Zespół myślał o tym, jak przejść do następnego kroku po błędzie, natomiast Andrea chciała się cofnąć – jak zapobiec błędowi w ogóle?

Żeby wyrwać zespół z tunelu rozwiązaniowego, Andrea użyła inversion exercise. To ćwiczenie, w którym brainstormuje się złe rozwiązania.

Jak to działa:

Brainstorm złych rozwiązań (5-10 min) – co by było naprawdę złe dla użytkownika? Jakie rozwiązanie na pewno nie zadziała?
Grupuj według themes – zbierz podobne złe pomysły razem, nazwij każdy cluster
Odwróć themes – jeśli zły pomysł to X, to dobry pomysł to odwrotność X
Referencja podczas solutioningu – wracajcie do listy złych pomysłów, kiedy ktoś proponuje coś podejrzanego

Andrea używa też obrazka z abstrakcją problemu (od Wesa O’Haire). To diagram pokazujący, jak przejść od „zaprojektuj lepszy otwieracz do puszek” przez „wydobądź zupę z puszki” aż do „uczyń puszkę bardziej atrakcyjną”. Zespół był na poziomie „make the can more appealing”, a Andrea chciała zejść wyżej – do fundamentalnego problemu.

To ćwiczenie trwało godzinę. Zespół miał zabawę, natomiast Andrea mówi, że to był jej pierwszy raz z tym exercisem, jednak już ma go „in my back pocket” na przyszłość.

How Might We framework

Andrea uwielbia How Might We i używa tego frameworku regularnie. Dla projektu związanego z taskami w Lattice zorganizowała jednogodzinny warsztat. Przed spotkaniem przygotowała overview projektu (poprosiła, żeby wszyscy przeczytali wcześniej), user goals i business goals, listę current problems oraz przykłady istniejących tasków w produkcie.

Na spotkanie zaprosiła nie tylko swój zespół, ale też designerów z innych teamów. Dlaczego? Bo taski są wszędzie w Lattice – w engagement, w reviews, w różnych obszarach, dlatego każdy designer zna pain pointy ze swojego obszaru.

Andrea i PM przygotowali trzy How Might We questions. Zespół miał 10 minut na dodawanie sticky notes do każdego pytania. Free for all – każdy dodaje, gdzie chce. Następnie ludzie rozdzielili się w pary, każda para wzięła jedną sekcję i zaczęła grupować stickies według themes.

Andrea użyła tu AI w FigJam – funkcji „sort stickies by topic” i „summarize”. Planuje porównać wyniki AI z tym, co zespół zrobił manualnie.

Diverge, converge – rytm pracy

Andrea często używa tego frameworka w swoich warsztatach. Start broad, diverge, converge. Zaczynasz szeroko, rozchodzisz się w różnych kierunkach (diverge), następnie zacieśniasz do konkretnych rozwiązań (converge).

To nie jest jednorazowe działanie. Andrea mówi, że zespół robi to wielokrotnie – to rytm, który powtarzają w różnych fazach projektu. Najpierw diverge na problem space, potem converge na konkretny problem, następnie diverge na pomysły i converge na rozwiązanie.

Sketching sessions – rysowanie dla nie-designerów

Czy ludzie, którzy nie są designerami, mają opory przed rysowaniem? Andrea pokazała przykład sketching session dla projektu „employee pay”. Chodziło o wizualizację pracowników na comp band przez data viz. Jeden z engineerów był bardzo zainteresowany data viz, w rezultacie jego pomysły były niezwykle wartościowe.

Sam Andrea też nie jest artystką. Przyznaje: „I’m a horrible drawer”, jednak to nie ma znaczenia. Tempo jest ważniejsze. Jeśli masz trzy minuty – działasz, dlatego nikt nie spowalnia, żeby zrobić ładny rysunek.

UX audit – osobisty vs zespołowy

Personal audit – wchodzenie w nowy obszar

Kiedy Andrea dołączyła do nowego zespołu, miała bardzo małą wiedzę o obszarze produktu zwanym „Comp Cycles”. Musiała się szybko zapoznać z projektem, w związku z czym zrobiła screenshot każdego ekranu z tego obszaru. Pogrupowała je według różnych sekcji, a po drodze dodawała sticky notes z notatkami – gdzie była zdezorientowana, co nie miało sensu.

Przykłady konkretnych notatek, które robiła Andrea:

Przy pustym state w setupie comp cycle: „I don’t have any employees. What happens here? What are we doing in those states? Are we even considering that? Should we be?”

Przy dziwnym stanie UI: „My Internet was working in this state, but I saw this and it felt scary. I don’t know what happened. I don’t know what I did. I don’t know how I got here.”

Przy navigacji z „Rules and Ratings”: „I remember not knowing what I was going to get when I get to the rules and rating stuff. What’s going to be on this page? What am I going to do here?” Jej propozycja: zmienić na „Setup” lub „Eligibility”, bo to lepiej komunikuje, że ustawiasz kto jest eligible do comp cycle.

Te konkretne, szczere notatki to wartościowy materiał. Andrea nie udaje eksperta, natomiast pokazuje, gdzie jest zdezorientowana. To pomaga zespołowi zobaczyć produkt świeżym okiem.

Następnie wzięła te notatki i poszła z nimi do PM. Sprawdziły razem, czy są jakieś sygnały, czy PM myśli o tym podobnie. To był personal audit – sposób na zrozumienie dużego obszaru produktowego i szybkie zapoznanie się z projektem. Miał jednak jeszcze jeden benefit: pomógł zrozumieć, przez co przechodzi użytkownik podczas setupu comp cycle.

Team audit – engagement przez async work

Andrea i jej design partner, Carrie, pracowały nad różnymi częściami comp cycles (pre-launch i post-launch). Po swoich osobistych auditach doszły do wniosku: powinniśmy zrobić team audit. Zobaczmy, co zespół myśli o pain pointach i gdzie według nich są problemy.

Jak zorganizowały async team audit:

Przygotowanie:

Zrobiły screenshoty wszystkich kluczowych ekranów
Pogrupowały je według sekcji/user flow
Przygotowały board w FigJam z miejscem na sticky notes
Napisały jasny Slack message: dlaczego to robimy, co chcemy osiągnąć, jak zespół może pomóc
Zablokowały czas w kalendarzach zespołu (ale to był czas do samodzielnej pracy, nie meeting)

Andrea dba o to, żeby ten Slack message był strawny i angażujący. Jak mówi: „semi long with emojis and all the things to make it fun to read”. Nie chodzi tylko o przekazanie informacji, jednak o to, żeby ludzie chcieli w tym uczestniczyć.

Podczas async work:

Każdy dodawał sticky notes z pain pointami we własnym tempie
Zespół używał +1 do głosowania na pain pointy, z którymi się zgadzał

Po async work (synchroniczny meeting):

Szybkie przejście przez wszystkie pain pointy
Głosowanie na najbardziej critical issues
Wyciągnięcie themes z każdej sekcji

To kluczowe: ludzie mieli zablokowany slot, jednak pracowali asynchronicznie. Nie musieli siedzieć wszyscy na jednym call przez godzinę.

Jak prezentować findings

Z team auditu Andrea i Carrie wyciągnęły themes. Z każdej sekcji stworzyły summary na górze boarda. Ważne: nie każdy musi czytać wszystkie sticky notes. Andrea robi „hard work” za innych – tworzy digest, themes, podsumowania i usuwa friction.

Zespół dostał też dostęp do user journey stworzony przez UXR team. To był dodatkowy artifact pokazujący całą ścieżkę użytkownika przez compensation cycle, w związku z czym user journey zawierał linki do customer clips – można było kliknąć i zobaczyć fragmenty wywiadów.

Według Andrei, kiedy podzieliła się tym auditem z engineers, naprawdę pomogli im to poczuć pain użytkownika. To zmotywowało ich do poprawy. Wszyscy nagle chcieli naprawiać wszystkie rzeczy. Problem? Teraz trzeba było wrócić do priorytetyzacji.

Priorytetyzacja – od auditu do roadmapy

Eisenhower Matrix – impact vs confidence

Po team audit Andrea, Carrie, PM i EM musieli zdecydować: co robimy najpierw? Użyli Eisenhower Matrix, jednak z customowymi osiami.

Jak skonstruowali matrix:

Oś pozioma: Confidence – jak bardzo jesteśmy pewni, że potrafimy to rozwiązać? Lewa = niska pewność (research needed), prawa = wysoka pewność
Oś pionowa: Impact – jak duży efekt to będzie miało? Góra = wysoki impact, dół = niski

Wzięli wszystkie sticky notes z pain pointów, duplikowali je i przenosili na matrix. Zespół pracował razem – Andrea przesuwała sticky, zespół mówił „wyżej”, „niżej”, „w lewo”, „w prawo”. Hot and cold game.

Jeśli ktoś nie zgadzał się z umiejscowieniem sticky, rozmawiali. To generowało wartościowe dyskusje. Na przykład: designer myśli „high confidence”, a engineer mówi „low confidence”.

Engineer z low confidence – czerwona flaga

To jest kluczowy insight z Eisenhower Matrix. Andrea zauważa: „A lot of times it’s the engineer that has low confidence might know more about the space and has more questions.”

Czyli kiedy engineer mówi „low confidence”, to NIE znaczy, że się myli, jednak znaczy, że wie więcej o tym obszarze technicznym i ma pytania bez odpowiedzi. To sygnał ostrzegawczy oznaczający, że zespół potrzebuje więcej discovery, więcej research, więcej wyjaśnień.

Odwrotnie też działa. Jeśli designer ma high confidence, a engineer low – trzeba się zatrzymać i porozmawiać. Co wie engineer, czego nie wie designer? Jakie są technical challenges, których designer nie widzi?

Te discrepancies to wartościowy materiał – miejsca, gdzie alignment się rozpada, dlatego to jest moment, żeby się zatrzymać i pogadać.

Rzeczy w prawym górnym rogu (high confidence, high impact) to były quick wins, w rezultacie zespół mógł się nimi zająć od razu. Rzeczy po lewej stronie (low confidence) wymagały więcej discovery, prawdopodobnie research i wywiadów. Dolny prawy róg to paper cuts – małe rzeczy do naprawienia między większymi projektami.

MoSCoW method – must, should, could, won’t

Po Eisenhower Matrix przyszedł czas na MoSCoW prioritization. Must do, should do, could do, won’t do.

Andrea wzięła całą matrix i przeniosła ją do kolejnego ćwiczenia. Zespół zaczął od rzeczy z prawego górnego rogu (high confidence, high impact) i przenosił je do odpowiednich kolumn MoSCoW.

Znowu – każde umieszczenie w „must do” vs „should do” prowokowało dyskusję. Dlaczego to must? Jakie są ryzyka? Co nie bierzemy pod uwagę? Kolumna „must do” to była lista priorytetów, na których zespół się zalignował – to, co chcieli zrobić najpierw.

Designer w strategicznych decyzjach produktowych

Andrea podkreśla, że w Lattice designer wybiera, jak bardzo chce być zaangażowany. Jeśli ktoś woli tylko „pchać pixele” – ok, PMs też mogą prowadzić te ćwiczenia. Jak mówi: „If maybe there’s a designer that’s not as comfortable like being this involved and facilitating these exercises, that’s totally okay.”

Jednak Andrea uwielbia discovery. Według niej, dzięki temu spędza bardzo mało czasu na pushing pixels. Dlaczego? Bo wszyscy są zalignowani na problem i rozumieją, co rozwiązują.

Kiedy przychodzi czas na właściwe designowanie, engineers już dokładnie wiedzą, o co chodzi. Zostawiają komentarze, natomiast Andrea cały czas udostępnia swoją pracę. Komunikacja jest mocna, bo wszyscy wiedzą, co rozwiązują i jak tam dojść.

To też oznacza, że design ma silny głos w roadmapie. Andrea nie tylko wykonuje zadania z backlogu, jednak współtworzy ten backlog razem z PM i EM.

Research synthesis i user flows

Kiedy robić research, a kiedy skipować

Andrea ma jasne kryteria, kiedy robi research, a kiedy go pomija. W przypadku projektu „data check”: „This was like a clear problem that we really didn’t need to do user research for. This was just a glaring problem in the UI that we needed to fix and knew what to fix.”

Jednak dla innych projektów robią 15+ wywiadów. Różnica? W data check problem był oczywisty – każdy w zespole go widział i każdy wiedział, jak to naprawić.

W innych projektach problem nie jest jasny albo zespół nie wie, jak go rozwiązać. Wtedy research. Dużo research. Jak mówi Andrea: „We’re still doing them just because we’re learning so much that could inform the future state of this project.”

Marvin AI – analiza wywiadów

Andrea i jej PM przeprowadzili 10-15 wywiadów dla jednego z projektów. To dużo materiału, w związku z tym jak go przetworzyć?

Używają narzędzia Marvin. Według Andrei, AI w Marvin jest doskonałe i pomaga analizować wywiady. Andrea przechodzi przez nie i dostosowuje po AI, jednak AI robi ciężką pracę – wyciąga themes. Następnie Andrea bierze findings i user quotes i przenosi je do FigJam. Czasem grupuje według themes (findings, pain points, needs).

Research bez zmuszania do oglądania godzin video

Marvin ma wartościową funkcję: możesz zszywać cytaty z różnych wywiadów w jeden krótki film. Bierzesz małe fragmenty z każdego wywiadu i robisz 5-minutowe video zamiast 10 godzin materiału.

Zespół dostaje open invite na wywiady – może dołączyć, jeśli chce. Po wywiadach Andrea robi wrap-up video i dzieli się nim w Slack. Znowu – Andrea robi hard work i usuwa friction. Zamiast mówić „obejrzyj 2 godziny wywiadów”, mówi „here are the findings”.

User flows jako discussion tool

Andrea często tworzy user flow już na początku projektu. Bazuje na swoim rozumieniu procesu, jednak to nie jest final flow – to starting point do dyskusji.

Pokazuje go PM i stakeholderom, następnie wraca do internal customers (ekspertów w firmie, których wywiadowali). Przechodzi przez flow z nimi i sprawdza, czy dobrze rozumie. Ten flow pomaga też w tworzeniu user research plan. Jakie pytania zadać? Gdzie są gaps w zrozumieniu? Co ludzie mogą robić inaczej?

Niektórzy wolą dokumenty, inni wolą wizualizacje, dlatego user flow to sposób na supportowanie obu.

Competitive analysis i pattern research

Kiedy Andrea pracowała nad filter pattern w Lattice, nie robiła typowego competitive analysis, jednak raczej pattern research.

Lattice ma mnóstwo filtrów. Każdy chip to pole, przez które user może searchować (employee directory). Jak ułatwić znalezienie właściwego filtra? Andrea przeszła przez produkty, których używają w firmie: Raycast, Slack, Dropbox, macOS, Notion.

Wzięła screenshoty i dodała sticky notes: co działa dobrze, co nie działa. To był design working session z innymi designerami z różnych teamów (nie tylko jej zespół). Dlaczego z innymi designerami? Bo to był design pattern, dlatego wszyscy mogą współtworzyć design system.

Z tego research Andrea wyciągnęła themes: „help me find what I’m looking for”, „help me narrow down my results”, „help me find my results quickly”.

Konkretny problem do rozwiązania

Andrea daje wartościowy przykład problemu, który odkryli podczas tego research: ktoś searchuje „London” w employee directory. Czy to:

First name (ktoś ma na imię London)?
Office location (londyńskie biuro)?
Time zone (London timezone)?

Jak to zwizualizować, żeby user od razu wiedział? To jest typ rzeczy, które musisz consider, kiedy designujesz search. Andrea nazywa to „contextual information related to each result” – musisz pokazać context, żeby wynik miał sens.

Następnie stworzyła diagram – jak myślą o search w kontekście filtrów: domains, categories, fields, field groups. Abstrahowała problem i przeniosła go do Figma.

Handoff i dokumentacja

Specs w Figma + Dev Mode

Andrea dodaje supporting Looms do swoich designów. Przechodzi przez specs w krótkim video, w rezultacie engineers mogą wrócić do niego, jeśli potrzebują.

Jednak według Andrei, odkąd Figma wprowadziła nowe features w Dev Mode, potrzebuje robić mniej Loomów. Ona i engineers dostosowują proces handoffu razem, dlatego Figma robi więcej pracy za nich. Loomy, które robi, są krótkie – tylko dla tej sekcji, tylko jeśli jest extra detail.

Out-of-scope ideas – archiwizacja na przyszłość

W trakcie designowania często pojawiają się pomysły, które są poza scope. Co z nimi robić? Andrea nie usuwa ich, jednak przenosi na bok. Trochę nad nimi pracuje, jednak wie, że nie zrobi tego teraz. Jeśli w przyszłości zespół wróci do tematu, będzie miał „just enough there” do restartu.

Checklist: Handoff gotowy?

Przed handoffem upewnij się, że masz:

All states (default, hover, error, empty, loading)
Specs w Dev Mode
Edge cases pokazane wizualnie
Out-of-scope ideas na boku (ale nie usunięte)
Krótki Loom tylko tam, gdzie Dev Mode nie wystarcza

AI jako wsparcie w facilitation

Andrea używa AI wybiórczo – tylko tam, gdzie naprawdę przyspiesza proces, nie zastępując ludzkiego osądu.

FigJam AI do analizy sticky notes

Podczas How Might We workshop Andrea użyła trzech funkcji AI w FigJam:

1. Sort stickies by topic (Sortuj karteczki według tematu)

Po tym jak zespół dodał dziesiątki sticky notes, AI automatycznie grupuje je według tematów. To oszczędza czas na manualnym przeciąganiu i grupowaniu.

Kiedy stosować: Bezpośrednio po sesji burzy mózgów (np. „How Might We”), gdy na tablicy znajduje się duża liczba nieuporządkowanych pomysłów. Funkcja ta automatycznie grupuje podobne karteczki w klastry, co stanowi doskonały punkt wyjścia do dalszej analizy.

2. Create themes (Stwórz motywy)

Gdy karteczki są już wstępnie pogrupowane, AI analizuje zawartość klastrów i proponuje dla nich nadrzędne motywy lub nazwy.

Kiedy stosować: Po wstępnym grupowaniu karteczek. Przyspiesza to proces syntezy i pomaga szybko zidentyfikować główne obszary dyskusji.

3. Summarize (Podsumuj)

AI tworzy podsumowanie zgrupowanych sticky notes, wyciągając główne themes.

Kiedy stosować: Na koniec procesu syntezy, aby stworzyć zwięzłe podsumowanie całej sesji lub konkretnego klastra tematycznego. To idealne narzędzie do generowania kluczowych wniosków, które można potem łatwo udostępnić reszcie zespołu.

Andrea podkreśla, że planuje porównać wyniki AI z tym, co zespół zrobił manualnie. AI nie zastępuje ludzkiej analizy – to narzędzie do walidacji i przyspieszenia procesu.

Ogólne zasady używania FigJam AI:

Po brainstormingu, kiedy masz 50+ sticky notes do przejrzenia
Gdy potrzebujesz szybko wyłapać patterns przed synchronicznym meetingiem
Jako walidacja tego, co zespół zrobił manualnie (czy coś przeoczyliśmy?)
NIE używaj jako jedynego źródła analizy – zawsze dodaj ludzki osąd

Marvin AI do research synthesis

Do analizy 10-15 wywiadów Andrea używa Marvin. AI automatycznie wyciąga themes z wywiadów, następnie Andrea przechodzi przez nie i dostosowuje. Jak mówi: „AI in there is fantastic. It helps analyze your interviews. I’m going through and like tweaking after AI does what it does.”

AI robi ciężką robotę (przeczesywanie godzin materiału), natomiast Andrea dodaje kontekst i osąd (czy te themes mają sens? czy coś jest missed?).

Kiedy używać Marvin AI:

Po przeprowadzeniu 5+ wywiadów, gdy zaczynasz tonąć w materiale
Do wstępnej analizy przed manual synthesis
Jako sposób na szybkie wyłapanie powtarzających się themes
Do stworzenia skróconych video clips z kluczowymi cytatami
NIE traktuj output AI jako final – to starting point, nie koniec procesu

Podsumowanie

Andrea pokazuje, że design discovery nie musi być wielotygodniowym procesem. Godzinne design sprints, async team audits i frameworki priorytetyzacji dają designerom realny głos w strategii produktowej.

Kluczowe wnioski:

Timeboxing działa – ludzie są bardziej focused, kiedy mają limit czasu (1h sweet spot)
Przygotowanie to 80% sukcesu – design brief, pre-read, gotowe screenshoty w FigJam
Async work oszczędza czas – nie każde ćwiczenie wymaga synchronicznego meetingu
Designer jako facilitator – prowadzenie warsztatów, zadawanie pytań, alignment
Usuwanie friction dla innych – research synthesis, krótkie video, digesty zamiast surowych danych
Cross-functional collaboration – engineers, którzy rozumieją user problem, dają lepsze pomysły
Systemowe myślenie – gdzie indziej w produkcie rozwiązujemy ten sam problem?
Diverge, converge jako rytm – start broad, rozejdź się, potem zawęź do rozwiązania
Engineer z low confidence = sygnał do więcej discovery – nie ignoruj tego
Jasne kryteria kiedy robić research – glaring UI problem vs unclear problem space
AI jako akcelerator, nie replacement – używaj do przyspieszenia, jednak zawsze dodaj ludzki osąd

W Lattice designerzy nie są „pixel pushers”, jednak są strategic partners. Andrea nie czeka, aż PM powie jej, co zaprojektować – współtworzy strategię od początku. I co ważne – każdy designer może wybrać swój poziom zaangażowania. Nie musisz być jak Andrea, jednak jeśli chcesz – framework jest tu gotowy.

Kluczowy insight

Spowolnienie, by przyspieszyć projekt

Standardowo myślimy: Discovery i warsztaty to kosztowny czasowo wstęp, który opóźnia „prawdziwą” pracę, czyli projektowanie i kodowanie.

W praktyce okazuje się, że: Godzina spędzona na wspólnym budowaniu zrozumienia problemu z inżynierami i PM-em oszczędza dziesiątki godzin na późniejszych poprawkach, pętlach informacji zwrotnej i spotkaniach wyjaśniających. Andrea spędza bardzo mało czasu na pushing pixels właśnie dlatego, że robi tyle discovery upfront. Kiedy wszyscy są zalignowani na problem i rozwiązanie, pixele układają się prawie same, w rezultacie engineers zostawiają mniej komentarzy, bo już wszystko rozumieją.

Dlaczego to jest istotne: Większość zespołów traktuje discovery jako „nice to have” w presji czasu. Andrea pokazuje, że to jest inwestycja, która zwraca się wielokrotnie w fazie execution. Wspólne „spowolnienie” na starcie jest inwestycją w radykalne przyspieszenie całego procesu, a także przesuwa rolę designera z wykonawcy poleceń na facylitatora, który buduje zgodę i wspólną odpowiedzialność za produkt.

Test na jutro: Następnym razem gdy otrzymasz założenia do nowego zadania, zamiast od razu otwierać Figmę i projektować, zaproponuj zespołowi (zwłaszcza inżynierom) jeden 60-minutowy warsztat. Jego celem ma być wyłącznie omówienie problemu użytkownika i wspólne zmapowanie ryzyk, a nie szukanie rozwiązań. Sprawdź, o ile mniej pytań i niejasności pojawi się na etapie projektowania i wdrożenia.

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ć. Materiał pochodzi z wywiadu „Top Designer shows how to use Figma for Design Sprints” z podcastu Sneak Peek, prowadzonego przez Jay’a. Gościem była Andrea, Staff Designer w Lattice, która pokazała swoje podejście do design discovery i facilitation w środowisku enterprise.

Tag: Design Discovery

Jak robić design discovery w godzinę zamiast w tydzień – metody Staff Designer z Lattice #EN314