§ Case study · BeeSpeaker · 2025—2026
Aplikacja do nauki języków z 5M+ pobrań. Dwie równoległe role w ciągu roku — prowadzenie projektowania produktu w całej aplikacji oraz odpowiedzialność za lejek webowy od zera.
§ 01 Kontekst
Co zastałam.
Produkt miał realną skalę, ale badania, rygor projektowy i lejek webowy nie były jeszcze ugruntowane. Moim zadaniem było wnieść dyscyplinę enterprise, nie spowalniając zespołu — tempo startupu, głębia enterprise.
§ 02 Za co odpowiadałam
Trzy obszary, za które odpowiadałam.
Projektowanie produktu end-to-end — oparte na hipotezach. Odpowiadałam za proces projektowy od discovery po wdrożenie, oparty na hipotezach i mierzony analityką. Decyzje formułowane jako pytania do przetestowania, a nie domysły do obrony.
Product Owner. Odpowiedzialność za funkcje. Pełniłam rolę Product Ownera inicjatywy lejka webowego — wizja, backlog, dostarczanie cross-funkcyjne. Regularnie prowadziłam strumienie pracy nad funkcjami jako właścicielka projektu w małych, skupionych zespołach.
Odpowiedzialność za roadmapę badań. Odpowiadałam za roadmapę badań — co badać, kiedy i jak. Większość badań prowadziłam sama, a delegowałam tam, gdzie zespół mógł działać szybciej samodzielnie.
§ 03 — Historia 01 · Lejek webowy
Budowa nowego kanału pozyskania — jako Product Owner.
Zbudować pierwszy webowy lejek pozyskania BeeSpeaker — z użyciem Web2wave — i poprowadzić zarówno zespół wewnętrzny, jak i zewnętrznego partnera software'owego.
Zwiększyć pozyskanie i remarketing dzięki analizie konkurencji, projektowaniu opartemu na hipotezach i testom A/B na kilku rynkach.
Analiza konkurencji i trendów. Pełny proces projektowy na wszystkich ekranach, z przekazaniem do developmentu. Bieżąca iteracja na podstawie wyników testów. Lokalizacja na rynki wspólnie z zespołem.
Koordynacja pracy między developmentem, marketingiem, contentem i ceremoniami agile. Ustalanie strategii, co budować i zmieniać w następnej kolejności. Odpowiedzialność za analitykę i raportowanie.
Lejek uruchomiony na rynku polskim i japońskim — dziś część stacku pozyskania BeeSpeaker. Mocny rytm pracy między zespołem wewnętrznym a partnerem zewnętrznym. Gotowy framework pod kolejne uruchomienia rynkowe.
§ 04 — Historia 02 · AI Tutor
AI Tutor — od pustego czatu do prowadzonej praktyki.
Funkcja Free Talk sprawiała wrażenie pustego czatu. Wysoka bariera wejścia, brak jasnego punktu startu, brak możliwości filtrowania lub tworzenia własnych scenariuszy.
Przeprojektować punkt wejścia tak, aby użytkownicy zawsze wiedzieli, co dalej, szybko znajdowali właściwy scenariusz i mieli pewność, by zacząć.
Proces, krok po kroku.
-
01 · Badania
Zaprojektowałam i przeprowadziłam pogłębione badanie „Product Ground Truth" — skupione na tym, jak użytkownicy naprawdę doświadczają BeeSpeaker, z AI Tutorem jako głównym obiektywem.
- Zdefiniowałam scenariusz i kryteria rekrutacji: aktywni użytkownicy Pro z 120+ dniami w produkcie
- Przeprowadziłam 16 sesji IDI w 5 grupach wiekowych i na 3 poziomach językowych
- Analizowałam każdy wywiad w FigJam, ze wsparciem AI wydobywającego wzorce z nagrań
- Zsyntetyzowałam wnioski w raport i przedstawiłam całemu zespołowi
-
02 · Kanwa hipotez
Dla każdego ekranu budowałam kanwę hipotez — cele biznesowe, cele użytkownika, metryki analityczne, wartość dla biznesu, wartość dla użytkownika.
Metryki były osadzone w Amplitude — mierzalne, śledzone i powiązane z testami A/B. Kanwa stała się podstawą każdej rozmowy z PM-em i przesunęła zespół z „co powinniśmy zbudować" na „co testujemy".
-
03 · Dokumentacja na poziomie ekranu
Dla każdego kluczowego ekranu tworzyłam ustrukturyzowany brief: główny problem do rozwiązania, koncepcję rozwiązania, cel widoku, user flow z kluczową akcją i testowalną hipotezę.
Dzięki temu zespół był zgrany na każdym ekranie — co rozwiązujemy, co testujemy i jak wygląda sukces, zanim powstał jakikolwiek piksel.
-
04 · Low-fi z mapowaniem ryzyk
Przepracowałam warianty low-fi z zespołem, mapując ryzyka bezpośrednio na wireframe'ach — każdy wariant powiązany z jawną hipotezą do przetestowania:
- Przeciążenie poznawcze przez zbyt wiele opcji na jednym ekranie
- Niejasna hierarchia między rozmową a scenariuszami
- Brak punktów wejścia dla mniej pewnych użytkowników (poziomy A1–A2)
- Biblioteka scenariuszy konkurująca z głównymi akcjami
-
05 · Dopracowanie i finalne UI
Dopracowałam kierunek na żywej sesji projektowej z zespołem — przekuwając najlepsze low-fi w bardziej dopracowane medium-fi, które zespół mógł wspólnie kwestionować. Używałam AI jako partnera w pracy nad wariantami tekstów i eksploracją UI, a potem dopasowałam wszystko do zasad prostego języka i planów testów A/B.
Finalne dostarczenie obejmowało:
- Finalny layout osadzony w kontekście pełnego flow aplikacji
- Zdarzenia analityczne zdefiniowane dla każdej interakcji
- Dokumentację wdrożeniową w Figmie i Jirze dla zespołu developerskiego
- Jasny punkt wejścia: dwa główne sposoby rozpoczęcia praktyki (otwarta rozmowa lub własny scenariusz), z biblioteką scenariuszy jako filtrowalną warstwą wsparcia poniżej
§ 05 Refleksja
Cztery rzeczy, które zabieram z BeeSpeaker:
- Budowanie strategii badań i odpowiedzialność za roadmapę od zera.
- Prowadzenie zespołów cross-funkcyjnych, gdy tempo nie zwalnia.
- Podejmowanie decyzji produktowych pod presją bez utraty rygoru.
- I przekonanie, że AI potrafi zgadywać, czego chcą użytkownicy — a prawdziwe rozmowy pokazują, co naprawdę robią.
Następny case
Nationale-Nederlanden
Europejska grupa ubezpieczeniowo-inwestycyjna · 1M+ użytkowników · 2022—2025
Zobacz case study →