// case study · platforma lekta ai · projektowanie wspierane ai
Revision Tool
Jak wieloetapowe wydawanie modelu ML zamieniło się w jeden przycisk — projektowane z AI w pętli.
- rola
- Senior Product Designer · jedyny projektant
- zakres
- 0→1 — nowy moduł, wcześniej ręczna robota 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 same testować i publikować wersji modeli — każda zmiana szła przez developera, co rodziło opóźnienia, rozjazdy wersji i wąskie gardła.
// podejście
Zrozumieć backend na tyle, żeby go ukryć: godziny rozmów technicznych, pełna mapa stanów, a 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 z rąk developerów do zespołu produktu — i stały się rytuałem raz na sprint. Uczciwy UI w ograniczeniach ML, spójny z resztą platformy.
fig. 01
kontekst
Revision Tool to jeden z modułów Lekty — platformy enterprise do budowania botów głosowych i tekstowych dla bankowości i telco i zarządzania nimi. Zmiany ze wszystkich modułów spływają tu jako wersja robocza — user widzi je dopiero po zakończonym treningu. Zanim ten moduł powstał, każde wydanie szło przez ręce 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 miał widzieć jedną akcję.
// ograniczenia
- czas treningu nie do przewidzenia — rośnie ze złożonością modelu
- brak postępu backendu w czasie rzeczywistym
- środowiska na sztywno zakodowane 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
Długie godziny 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 — sprawdzałem z AI, czy dobrze przełożyłem logikę backendu na myślenie projektowe. Pułapką jest tu nadmierne zaufanie do outputów: każdą hipotezę i tak trzeba było zderzyć z tym, co realnie mówili devowie.
Mapowanie zależności
Pełny diagram stanów: co wyzwala freeze, co dzieje się w trakcie treningu, co blokuje przypisanie, co widzi user, kiedy trening się nie uda.
// 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 — rozrysowanie 12+ stanów i ich przejść pokazało, które są istotne dla usera (dokładnie jeden: „gotowe”), a które to tylko szczegół implementacyjny backendu.
Eliminacja złożoności
Pierwsze szkice UI w v0 miały wszystkie kroki backendu na wierzchu — paski postępu, etykiety stanów, wieloetapowe flow. Wniosek był natychmiast jasny: pokazywanie stanów backendu przeciążało poznawczo.
// 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 — wytłumacz jak 10-latkowi — stress-testowałem każdą etykietę, przycisk i komunikat. Jeśli zdanie wymagało wiedzy o backendzie, wypadał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 wyłapać dziury tu niż na QA — albo na demo u klienta.
// ai w pętli — cztery role, jedna zasada: przyspiesza myślenie, nie zastępuje go
◈ domain expert
sprawdzał, czy dobrze przełożyłem logikę backendu na decyzje projektowe
◈ system thinker
składał 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ł swoją osobę odpowiedzialną za wydania — częściej na starcie projektu, z czasem schodząc do raz na sprint. Wszystko bez udziału developera.
// wydanie przestało być zadaniem developera — stało się produktowym rytuałem
Uczciwy UI w ograniczeniach ML
Czas treningu był nie do przewidzenia — pasek postępu by kłamał. Zamiast niego: żadnego fałszywego wskaźnika, prosty komunikat na koniec i nowa wersja pojawiająca się na liście jako potwierdzenie.
// userzy przestali pytać „czy gotowe?” — lista odpowiadała za nich
Spójny system, wyjątkowy moduł
Jedyny moduł z customowymi komponentami na własnym modelu 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
Gdzie AI miało granice
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 diffa wersji — dokładne pokazanie, co zmieniło się między wersjami NLU, NLG i Dialog — była najczęściej proszoną kolejną funkcją. Konfigurowalne środowiska to był oczywisty drugi krok. Oba świadomie ucięte: stabilny v1, który wychodzi, jest wart więcej niż perfekcyjny, który nie.
Zadajesz pytania, które zmieniają mój sposób patrzenia.
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: