// case study · platforma lekta ai · projektowanie wspierane ai
Revision Tool
Jak wieloetapowy proces wydania modelu ML stał się jednym przyciskiem — projektowany z AI w pętli.
- rola
- Senior Product Designer · jedyny projektant
- zakres
- 0→1 — nowy moduł, wcześniej ręczna praca devów
- platforma
- Lekta — boty głosowe i tekstowe dla bankowości i telco
- zespół
- fullstack devowie · CTO
- proces
- wspierany AI (GPT · v0)
// problem
Zespoły wdrażające boty nie mogły samodzielnie testować i publikować wersji modeli — każda zmiana wymagała wsparcia developera, co tworzyło opóźnienia, rozjazdy wersji i wąskie gardła.
// podejście
Zrozumieć backend na tyle, by go ukryć: godziny rozmów technicznych, pełna mapa stanów, potem UI pokazujący jedną akcję zamiast dwunastu stanów. AI pracowało jako domain expert, system thinker i red team.
// wynik
Wydania przeszły od developerów do ludzi z produktu — do rytuału raz na sprint. Uczciwy UI w ograniczeniach ML, spójny z platformą.
fig. 01
kontekst
Revision Tool to jeden z modułów Lekty — platformy enterprise do budowania i zarządzania botami głosowymi i tekstowymi w bankowości i telco. Zmiany z wszystkich modułów spływają do Revision Tool jako wersja robocza — widoczna dla usera dopiero po zakończeniu treningu. Zanim ten moduł powstał, każde wydanie wymagało ręcznej interwencji developera.
// przepływ danych — jak zmiany docierają do narzędzia
Dialog Designer
logika i przepływy dialogów
Conversations
ulepszenia modelu ML i przegląd rozmów
Bot Reactions
edycja odpowiedzi bota (NLG)
Revision Tool
wszystkie zmiany trafiają tu jako wersja robocza — o jeden przycisk od produkcji
fig. 02
problem
Backend miał 12+ stanów.
User musiał widzieć jedną akcję.
// ograniczenia
- czas treningu nieprzewidywalny — rośnie ze złożonością modelu
- brak postępu backendu w czasie rzeczywistym
- środowiska zakodowane na stałe per klient w v1
- zgodność z design systemem platformy
- nietechniczni userzy musieli to obsłużyć bez dokumentacji
fig. 03
proces
// ślad rozumowania — każdy krok wynika z poprzedniego
Zrozumienie systemu
Wiele godzin rozmów technicznych z fullstack developerami — co wyzwala freeze, jak trening łączy się z wersjami modelu, jak środowiska mapują się na klientów.
// powierzchnia backendu, którą musiałem ogarnąć
freezequeuetrainvalidateversionassigndeployrollbackerrorretrylockdiff…12+ stanów · wyniesionych z godzin rozmów z devami
◈ jak pomogło AI◈ zwiń
◈ AI jako Domain Expert — użyłem AI, żeby zweryfikować, czy poprawnie przełożyłem logikę backendu na myślenie projektowe. Ryzyko to nadmierne zaufanie do outputów: każdą hipotezę i tak trzeba było sprawdzić z tym, co faktycznie mówili devowie.
Mapowanie zależności
Pełny diagram stanów: co wyzwala freeze, co dzieje się podczas treningu, co blokuje przypisanie, co user widzi, gdy trening się nie powiedzie.
// maszyna stanów
Freeze changes↓ tworzy
Draft revisiontraining starts automatically↓ wynik treningu
● success — id copyable● error — check logs↓ przypisz do aplikacji
Appcurrent: rev_20240312_143AChangerevision id…Save↓ wdrożone do
ProductionStagingDevelopment◈ jak pomogło AI◈ zwiń
◈ AI jako System Thinker — mapowanie 12+ stanów i ich przejść pokazało, które stany są istotne dla usera (dokładnie jeden: 'gotowe'), a które to szczegół implementacyjny backendu.
Eliminacja złożoności
Wczesne szkice UI w v0 ze wszystkimi krokami backendu na wierzchu — wskaźniki postępu, etykiety stanów, wieloetapowe flow. Wniosek natychmiast jasny: pokazywanie stanów backendu tworzyło przeciążenie poznawcze.
// co użytkownik mógł zobaczyć → co zobaczył
state: freezing
training 3 / 12
queue position 4
model v2.1.7
validating nodes
env mapping
→
Freeze changes12 stanów → 1 akcja · cała złożoność backendu ukryta
◈ jak pomogło AI◈ zwiń
◈ AI — Wyjaśnij jak 10-latkowi — stress-testowałem każdą etykietę, przycisk i komunikat. Jeśli zdanie wymagało wiedzy o backendzie, nie wchodziło.
Stress-testy przed handoffem
Wyłapywanie edge case'ów, zanim znajdą je developerzy: co jeśli trening padnie? Czy nieudana wersja może trafić na produkcję? Jak wygląda długi trening bez danych o postępie?
// pytania z pozycji adwersarza, zanim zdążyło zapytać QA
? co jeśli trening się wywali?
→ stan błędu — żadnego fałszywego progress baru
? czy nieudana rewizja może trafić na produkcję?
→ zablokowana przed produkcją
? długi trening bez danych o postępie?
→ uczciwy komunikat stanu końcowego
◈ jak pomogło AI◈ zwiń
◈ AI jako Krytyk / Red Team — adwersaryjne pytania przeciwko własnemu projektowi. Taniej niż znaleźć te same dziury w QA — albo na demo u klienta.
// ai w pętli — cztery role, jedna zasada: przyspiesza myślenie, nie zastępuje go
◈ domain expert
weryfikował moje przełożenie logiki backendu na decyzje projektowe
◈ system thinker
mapował stany, przejścia i zależności w jeden diagram
◈ explain like i'm 10
stress-testował każdą etykietę i komunikat pod nietechnicznych userów
◈ critic / red team
atakował projekt edge case'ami przed handoffem
// kluczowy wniosek
Im lepiej rozumiałem backend, tym mniej go pokazywałem.
// przed
// po
// ta sama logika. inny koszt poznawczy.
fig. 04
wynik
Własność bez zależności od devów
Każdy klient miał wyznaczoną osobę odpowiedzialną za wydania — częściej na starcie projektu, do raz na sprint w dojrzałych. Wszystko bez udziału developera.
// wydania przeszły z zadania developerskiego w rytuał produktowy
Uczciwy UI w ograniczeniach ML
Czas treningu był nieprzewidywalny — pasek postępu by kłamał. Zamiast tego: bez fałszywego wskaźnika, prosty komunikat końcowy, a nowa wersja pojawiająca się na liście jako potwierdzenie.
// userzy przestali pytać 'czy gotowe?' — lista odpowiadała za nich
Spójny system, unikalny moduł
Jedyny moduł z customowymi komponentami napędzanymi własnym modelem danych. Typografia, kolor i wzorce informacji zostały spójne — layout i logika interakcji zbudowane od zera.
// nowy wzorzec interakcji, który nie rozwalił systemu, w którym żył
fig. 05
refleksje
Ograniczenia AI w tym procesie
AI było partnerem do myślenia, nie skrótem. Nie zastąpiło godzin rozmów technicznych z developerami — mogło tylko pomóc sprawdzić, czy dobrze je zrozumiałem. To, co zajmowało tygodnie odbijania piłeczki z devami, weryfikowałem w godziny; szybkość była w walidacji, nie w zastępowaniu rozmów.
Jak mógłby wyglądać post-MVP
Analiza diff wersji — pokazanie dokładnie, co zmieniło się między wersjami NLU, NLG i Dialog — była najczęściej proszoną kolejną funkcją. Konfigurowalne środowiska były jasnym drugim krokiem. Oba to świadome cięcia: stabilny v1, który wychodzi, jest wart więcej niż perfekcyjny, który nie.
Zadajesz pytania, które zmieniają mój punkt widzenia.
Masz złożony produkt, któremu brakuje jasności?
Otwarty na długoterminowy kontrakt B2B, projekt freelance albo jednorazową konsultację.
albo napisz bezpośrednio: