TL;DR:

Projektowanie dla deweloperów wymaga zrozumienia ich specyficznych potrzeb i upraszczania złożonych danych, co MongoDB realizuje poprzez hierarchizację informacji i podejście skoncentrowane na przypadkach użycia
Firmy deweloperskie muszą balansować między potrzebami indywidualnych programistów a wymaganiami korporacyjnymi, zwłaszcza przy przejściu z modelu open-source do enterprise
Badania partycypacyjne ewoluowały od manualnych do cyfrowych, a teraz stają przed wyzwaniem integracji z AI
Psychologiczne korzyści z badań partycypacyjnych obejmują poczucie sprawczości, przynależności i kompetencji u uczestników
AI może wspierać badania partycypacyjne (planowanie, analiza, raportowanie), ale nie powinno zastępować ludzi w fazie zbierania danych
Przyszłość badań to mądre wykorzystanie AI przy jednoczesnym zachowaniu prawdziwych interakcji międzyludzkich

Kontynuuję dzielenie się najcenniejszymi spostrzeżeniami z wartościowych wydarzeń branżowych. Tym razem zagłębię się w materiały z UXDX, gdzie przedstawiono dwie prezentacje, które szczególnie zwróciły moją uwagę – są pełne praktycznych wskazówek, do których sam zamierzam wracać.

Dlaczego akurat UXDX? Jak wspomniał prowadzący, ich misją jest „pomaganie firmom budować środowisko, które nie może tworzyć złego oprogramowania”. Przejście od podejścia projektowego typu waterfall do autonomicznych zespołów produktowych jest trudne, ale niezbędne – i właśnie o tym opowiadają prelegenci.

Projektowanie dla deweloperów – doświadczenia z MongoDB

W pierwszej prezentacji Tan Chao (Lead Product Designer) oraz Yuqian Kao (Senior Product Designer) z MongoDB podzielili się swoimi doświadczeniami w projektowaniu dla specyficznej grupy użytkowników – deweloperów.

Kim są deweloperzy jako grupa docelowa?

Jak zauważyła Yuqian, gdy myślimy o projektowaniu produktów, często przychodzą nam do głowy aplikacje konsumenckie jak Spotify czy Robinhood. Tymczasem projektowanie dla deweloperów ma swoją specyfikę.

Deweloperzy jako grupa docelowa wyróżniają się następującymi cechami:

Posiadają wykształcenie informatyczne
Cieszą się, gdy mogą szybko i efektywnie wykonać zadanie
Lubią rozwiązywać złożone problemy
Martwią się błędami i dyżurami on-call
Oczekują możliwości tworzenia baz danych w kilka sekund bez konieczności zgłębiania dokumentacji

MongoDB jako firma bazodanowa NoSQL skupia się na uproszczeniu procesu tworzenia i zarządzania bazami danych. Ich projektanci dążą do stworzenia interfejsu, który pozwoli użytkownikom zarządzać bazami danych zaledwie kilkoma kliknięciami.

Upraszczanie big data dla deweloperów

MongoDB jako firma bazodanowa NoSQL przetwarza codziennie ogromne ilości danych. Ich interfejs użytkownika wyświetla stan i wydajność klastrów w sposób hierarchiczny, gdzie:

Najważniejsze informacje pojawiają się na górze
Mniej istotne metadane umieszczone są poniżej
Układ wyraźnie pokazuje krytyczne dane i potencjalne problemy

Co ciekawe, nie wszyscy projektanci w MongoDB mają wykształcenie inżynieryjne, ale wszyscy stosują te same metody badawcze:

Przeprowadzają wywiady z deweloperami
Współpracują z wewnętrznymi zespołami (PM, inżynierowie, marketing, wsparcie)
Wykorzystują dane klientów do identyfikacji priorytetowych metryk
Stosują podejście oparte na przypadkach użycia

Yuqian podkreśliła znaczenie testów A/B w procesie projektowania. Projekty zweryfikowane za pomocą testów A/B przyniosły znaczący pozytywny wpływ na klientów.

Dzięki projektowaniu opartemu na przypadkach użycia, MongoDB odnotowało znaczny wzrost adopcji funkcji. Deweloperzy nie tylko mogą efektywniej wykonywać zadania, ale także odkrywają funkcje, z których wcześniej nie zdawali sobie sprawy.

Przejście od obsługi indywidualnych deweloperów do korporacji

Tan Chao, który prowadzi zespół w MongoDB, opisał ewolucję firmy od projektu open-source do platformy korporacyjnej. Zgodnie z jego obserwacjami:

MongoDB zaczęło jako projekt open-source koncentrujący się na potrzebach deweloperów
Po transformacjach projektowych zdobyło uznanie milionów deweloperów
Wyzwania makroekonomiczne wpłynęły na startupy, podkreślając potrzebę skupienia się na klientach korporacyjnych
W firmach korporacyjnych występują różne role (CTO, architekci rozwiązań, deweloperzy) z odmiennymi potrzebami

Przykłady wyzwań projektowych w kontekście korporacyjnym:

Elastyczne zarządzanie bazami danych – obsługa różnej skali obciążeń (np. rynki o różnej wielkości)
Centralizacja zarządzania – wspieranie skalowania organizacji przy jednoczesnym zwiększaniu wydajności inżynierów
Usprawnienie migracji danych – procesy mogące zajmować dni, tygodnie lub nawet miesiące

MongoDB skupia się na tworzeniu scentralizowanych systemów zarządzania, które:

Pozwalają na kontrolę na poziomie organizacji
Minimalizują czas i koszty migracji danych
Oferują standaryzowane przepływy pracy

AI i przyszłość projektowania narzędzi deweloperskich

Yuqian poruszyła kwestię wpływu AI na projektowanie, przywołując aktualne zmiany w branży:

Meta zwolniła 5% pracowników, aby skupić się na AI
Liderzy Microsoftu sugerują, że era SaaS, jaką znamy, dobiega końca
Projektanci zadają sobie pytanie: czy AI przejmie nasze stanowiska?

Zespół MongoDB zauważył, że chociaż nowe technologie zawsze budziły niepokój, ostatecznie pomagały ludziom skupić się na udoskonalaniu procesów i znajdowaniu lepszych rozwiązań.

W MongoDB AI jest wykorzystywane do:

Nowoczesnego wyszukiwania wektorowego – obsługa złożonych typów danych i wydajne wyszukiwanie podobieństw
Funkcji analitycznych z przewidywaniem – zmniejszenie manualnej konfiguracji i zwiększenie wydajności baz danych
Automatyzacji migracji danych – przejście z tradycyjnych baz SQL do baz dokumentowych, które są bardziej elastyczne i łatwiejsze w pracy z aplikacjami AI

Projektanci zauważyli analogie między narzędziami AI dla deweloperów a narzędziami projektowymi opartymi na AI:

Narzędzia AI dla deweloperów	Narzędzia AI dla projektantów
Generowanie kodu	Generowanie plików projektowych
Migracja danych	Transformacja zasobów projektowych
Narzędzia deweloperskie z AI	Narzędzia projektowe z AI

Różnice między AI a ludzkim projektantem

Tan podkreślił kluczowe różnice między AI a ludzkim projektantem:

Obszar	AI	Człowiek-projektant
Inicjatywa	Nie daje pomysłów ani nie pomaga użytkownikom rozwiązać problemu	Musi wykazywać się inicjatywą i intuicją w identyfikacji problemów klientów
Cele	Nie potrafi wyznaczać nadrzędnych celów	Ustala konkretne cele zgodne z priorytetami biznesowymi
Empatia	Może analizować dane i sugerować rozwiązania, ale brakuje mu prawdziwej empatii	Wnosi empatię do procesu projektowania i nawiązuje głębsze relacje z klientami
Kierunek	Dostarcza wskazówki dotyczące wdrażania	Wyznacza wizję i kierunek projektowania

Kluczowe wnioski zespołu MongoDB dla projektantów:

Skupiać się na kluczowych problemach klientów
Usprawniać procesy, by przynosiły wymierne korzyści biznesowe
Dostarczać elastyczne rozwiązania
Balansować pomiędzy dogłębną wiedzą produktową, techniczną i strategiczną

Przyszłość badań partycypacyjnych z perspektywy AI i ludzkiej

W drugiej prezentacji Anna Kolvinges (specjalistka od myślenia systemowego i etnografii) oraz Katerina Nunj (specjalistka od psychologii i poznania społecznego) z Outsystems podzieliły się spostrzeżeniami na temat przyszłości badań partycypacyjnych w erze AI.

Ewolucja badań partycypacyjnych

Anna opisała transformację badań partycypacyjnych przez lata:

Faza 1: Badania manualne (społeczności wiejskie w Afryce)

Ręcznie pisane dzienniki dokumentujące codzienne doświadczenia
Zdjęcia robione przez uczestników badań (rytuały szamanów, czynności domowe, tradycyjne tańce)
Bogate i bezcenne spostrzeżenia, ale bardzo czasochłonny proces

Faza 2: Badania cyfrowe (środowisko technologiczne)

Cyfrowe dzienniki zamiast ręcznych
Zrzuty ekranu zamiast zdjęć
Narzędzia AI do automatycznych transkrypcji i opisów
Szybszy proces przy zachowaniu jakościowych spostrzeżeń

Faza 3: Era generatywnej AI (obecnie)

Całkowita transformacja sposobu prowadzenia badań
Wyzwanie: zachowanie ludzkiego pierwiastka przy korzystaniu z AI

Katerina wyjaśniła fundamenty badań partycypacyjnych:

Wywodzą się z aktywizmu, antropologii i badań społecznościowych
Zamiast badania ludzi, angażują ich w kształtowanie rozwiązań
Opierają się na modelu współtworzenia wiedzy, nie jej jednostronnego przekazywania
Jednako skuteczne w naukach społecznych jak i w technologii

Katerina wyjaśniła korzenie badań partycypacyjnych:

„Badania partycypacyjne wywodzą się z aktywizmu, antropologii i badań prowadzonych przez społeczność. Są to dziedziny, w których celem nie było tylko badanie ludzi, ale angażowanie ich w kształtowanie rozwiązań.”

Zamiast tradycyjnego modelu, gdzie badacz przychodzi, zbiera informacje i odchodzi, badania partycypacyjne stawiają ludzi w centrum:

Ludzie dokumentują własne doświadczenia
Zgłaszają własne obawy
Stają się aktywnymi uczestnikami badań

Psychologiczne podstawy badań partycypacyjnych

Katerina, jako psycholog, wyjaśniła psychologiczne mechanizmy stojące za skutecznością badań partycypacyjnych:

Podstawy teoretyczne:

Konstruktywizm społeczny – wiedza jest budowana poprzez współpracę, dialog i wspólne doświadczenia
Tożsamość społeczna – ludzie postrzegają siebie przez pryzmat grup, do których należą (np. deweloperzy czują większy związek z badaniem dotyczącym doświadczenia deweloperskiego)

Trzy wymiary motywacji według teorii autodeterminacji:

Autonomia – uczestnicy mają kontrolę nad swoją pracą i procesem
Przywiązanie – budują relacje z badaczami i innymi uczestnikami
Kompetencja – mają poczucie, że ich wkład ma znaczenie

Przykład z praktyki Outsystems:

Użytkownicy aktywnie współpracują i angażują się w inicjatywy badawcze
Czują własność rozwiązania, które współtworzą
Otrzymują odznaki za udział w badaniach, co buduje uznanie w społeczności
Proaktywnie uczestniczą w forach i zgłaszają pomysły usprawnień
Rozwijają poczucie, że ich opinia ma realny wpływ na narzędzia używane codziennie

Efekty wysokiej motywacji uczestników:

Lepsza wydajność
Większa kreatywność
Większa wytrwałość
Szczegółowe i kontekstowe informacje zwrotne

Wyzwania i przyszłość badań partycypacyjnych w erze AI

Główne wyzwanie badań partycypacyjnych:

Anna zidentyfikowała kluczowy problem – badania partycypacyjne są czasochłonne, co stanowi przeszkodę w szybko zmieniającym się środowisku biznesowym. Konsekwencje:

Trudność w przekonaniu interesariuszy do inwestowania w badania
Ryzyko depriorytetyzacji na rzecz szybszych metod
Tradycyjnie wymagają dużo czasu i zasobów

Rola AI w badaniach partycypacyjnych:

AI nie zastępuje badań partycypacyjnych, lecz jest narzędziem umożliwiającym ich przetrwanie
Pozwala na skalowanie i utrzymanie praktyk badawczych w szybkim środowisku
Musi być stosowane ostrożnie, aby nie dehumanizować procesu

Model optymalnego wykorzystania AI na różnych etapach badań:

Etap badania	Rola AI	Rola człowieka
Planowanie	Znajdowanie trendów i pytań badawczych	Kształtowanie badania, zapewnienie uczciwości i trafności
Prowadzenie	Robienie notatek, automatyczne tłumaczenie	Skupienie na prawdziwych rozmowach i budowaniu relacji
Analiza	Sortowanie i znajdowanie wzorców w danych	Interpretacja kontekstu, empatyczne zrozumienie niuansów
Raportowanie	Tworzenie wykresów i podsumowań	Kontrola narracji i wnioskowania

Porównanie prawdziwych uczestników vs AI:

Aspekt	Prawdziwi uczestnicy	AI-generowani uczestnicy
Motywacja	Czują się zmotywowani i zaangażowani	Brak realnych emocji
Własność	Poczucie wpływu na produkt używany codziennie	Brak poczucia własności
Informacje zwrotne	Szczegółowe i kontekstowe dane	Brak prawdziwego kontekstu
Marketing	Pozytywne rozmowy z innymi (word-of-mouth)	Brak efektu marketingowego
Korzyści psychologiczne	Wzmocnienie poczucia wspólnoty	Brak korzyści społecznych

Wartość angażowania całego zespołu w badania

W trakcie sesji Q&A poruszono temat angażowania całego zespołu deweloperskiego w badania. Praktyczne podejście Outsystems:

Korzyści z udziału zespołu w badaniach:

Różne perspektywy – każdy członek zespołu wychwytuje inne aspekty wywiadu
Deweloperzy, projektanci i badacze zauważają różne elementy zgodnie ze swoją specjalizacją
Głębsze zrozumienie potrzeb użytkowników przez cały zespół
Lepsza integracja spostrzeżeń badawczych w procesie rozwoju produktu

Sprawdzone praktyki:

Angażowanie product managerów, deweloperów i architektów w wywiady
Uczestnictwo badacza we wszystkich wywiadach przed analizą danych
Nauka podczas wywiadów, nie tylko na etapie analizy
Wykorzystanie kontekstu z wywiadów do lepszej interpretacji danych

Ta praktyka pomaga przezwyciężyć ograniczenia AI, które mogłoby analizować dane bez pełnego kontekstu i niuansów, które są widoczne tylko podczas bezpośrednich interakcji.

Podsumowanie: człowiek w centrum technologii

Obie prezentacje, choć skupiały się na różnych aspektach projektowania i badań, podkreślały znaczenie ludzkiego elementu w świecie, który coraz bardziej zwraca się ku AI i automatyzacji.

Kluczowe wnioski:

MongoDB pokazuje, jak projektować złożone narzędzia techniczne z myślą o ludzkich potrzebach deweloperów
Outsystems demonstruje, jak zachować wartość ludzkich interakcji w badaniach przy wykorzystaniu AI do zwiększenia efektywności
AI jest narzędziem wspierającym, nie zastępującym ludzką kreatywność i empatię
Elastyczność jest kluczowa w czasach szybkich zmian technologicznych

Jak podsumował Tan z MongoDB: „Nie możemy przewidzieć wszystkiego, nie możemy zaplanować wszystkiego. Nawet jeśli jesteśmy dobrze przygotowani i mamy wszystkie umiejętności, nie jesteśmy wróżbitami. Dlatego bądźcie elastyczni tak bardzo, jak to możliwe.”

Artykuł powstał na podstawie AI Research and Designing for Developers . Wszystkie cytaty pochodzą bezpośrednio od prelegentów i zostały przytoczone w celach edukacyjnych.

Tag: Enterprise Design

Projektowanie dla deweloperów i badania partycypacyjne z perspektywy AI #EN30