Twój projekt UX ma dziurę, o której nie wiesz. Nazywa się brak transkrypcji

Notatka to nie to samo, co pamięć rozmowy

‍

Notatki z warsztatów są z natury subiektywne i niepełne. Osoba notująca wybiera to, co w danym momencie wydaje się istotne, a resztę odsiewa – często nieświadomie. Problem w tym, że to, co „oczywiste" podczas samej rozmowy, trzy tygodnie później bywa zupełnie niejasne. Wraca się wtedy do notatki i nie wiadomo, dlaczego dana decyzja w ogóle zapadła.
‍

Transkrypcja audio lub wideo rozwiązuje ten problem inaczej niż notatka – pozwala wrócić nie tylko do konkluzji, ale też do kontekstu decyzji i argumentów, które za nią stały. To różnica między „zdecydowaliśmy X" a pełnym zapisem tego, jakie opcje rozważano, co odrzucono i dlaczego.
‍

W praktyce oznacza to jedną zasadę: z narzędzi do transkrypcji (Otter, Fireflies, Notion AI, Tldv) korzystamy od pierwszego warsztatu, nie od momentu, w którym coś zaczyna się komplikować. Rozmowy, która nie została zarejestrowana, nie można później odtworzyć.
‍

W projekcie Kello decyzja o tym, że interaktywny kalendarz stanie się centrum całej aplikacji, zapadła podczas warsztatu Customer Journey. To była jedna z kluczowych decyzji architektonicznych całego projektu – a bez zapisu rozmowy łatwo byłoby ją zgubić lub rozmyć w kolejnych iteracjach, gdy pojawiały się nowe pomysły i alternatywne koncepcje.

‍

‍
‍

AI nie czyta w myślach – trzeba mu podać wszystko na tacy

‍

Samo nagranie rozmowy nie wystarczy. Automatyczne notatki i podsumowania AI są tak dobre, jak wyraźnie oznaczone są w rozmowie ważne momenty. Narzędzie nie wie samo z siebie, że właśnie padła kluczowa decyzja projektowa – trzeba mu to powiedzieć wprost, w trakcie rozmowy.

‍

‍

W ZIMA wygląda to mniej więcej tak:

• Gdy coś jest decyzją, mówimy to jak decyzję: „To jest decyzja projektowa – robimy X zamiast Y".
  ‍

• Używamy zwrotów-markerów, które AI (i ludzie) świetnie wyłapują: „uzgodniliśmy, że…", „rezygnujemy z…", „priorytet na tym etapie to…".
  ‍
• Pod koniec warsztatu prosimy AI o podsumowanie – ale nie całej rozmowy, tylko samych decyzji i otwartych pytań. I zanim ktokolwiek wyjdzie ze spotkania, weryfikujemy to razem z klientem.
  ‍

Ten ostatni punkt jest najważniejszy. To moment, w którym ktoś mówi „no nie, chwila, ja rozumiałem to inaczej" – i lepiej, żeby taka uwaga powiła się teraz, a nie trzy tygodnie później w mailu zaczynającym się od słów „z przykrością informujemy".
‍

Dobry zapis decyzji to nie samo „postanowiliśmy X". To komplet: co postanowiono, dlaczego (czyli jakie alternatywy odrzucono i co o tym przesądziło), kto i kiedy. Sama konkluzja bez tego kontekstu jest bezużyteczna.

‍

‍
‍

Dokumentacja jako ściąga dla agenta, nie dla szuflady

‍

Dobrze udokumentowany projekt to taki, który agent AI może zaimplementować z minimalną liczbą pytań. To wymaga jednak, żeby wnioski z badań i warsztatów trafiały tam, gdzie agent faktycznie ich szuka – nie tylko do raportu, którego nikt na etapie wdrożenia już nie otworzy.

‍
‍

Kilka zasad, które stosujemy na co dzień:

• Wnioski z testów użytkowników trafiają jako komentarze bezpośrednio do konkretnych ekranów w Figmie – nie tylko do raportu badawczego, do którego nikt nie zajrzy na etapie wdrożenia.
  ‍

• Mapowanie Customer Journey może pełnić rolę opisu przepływów dla agenta – pod warunkiem że jest wystarczająco precyzyjne, ze stanami wejściowymi i warunkami przejść, a nie tylko ładną strzałką od punktu A do punktu B.
  ‍
• Dla kluczowych ekranów tworzymy osobną sekcję „implementation notes" – w Figmie albo w Notion – gdzie zapisujemy, co jest w danym ekranie nietypowe i co wymaga szczególnej uwagi dewelopera. To rodzaj karteczki z ostrzeżeniem: „uwaga, tu jest haczyk".

‍