Projektuję zasady, z których korzysta AI

Pomysł potrzebuje formy i punktu odniesienia

Chcę, żeby człowiek mógł sprawdzić pomysł wtedy, kiedy ten pomysł się pojawia. Opisać potrzebę, przygotować prototyp i pokazać innym, co ma na myśli. Żeby taka rozmowa miała sens, potrzebuje jednak punktu odniesienia: produktu, jego użytkowników i zasad, które już obowiązują.

Przy prototypowaniu z AI zajmuję się więc również warunkami, w których powstaje interfejs. Porządkuję kontekst, opisuję reguły i ustalam, kiedy potrzebna jest ocena człowieka. Taki sposób pracy rozwijam pod nazwą Design Cortex. Tutaj opisuję samą metodę; szczegóły projektów, w których pracuję, pozostają poufne.

Projektuję słowem. Te słowa muszą jednak prowadzić do decyzji, którą potrafię ocenić i za którą mogę odpowiadać.

Zasady produktu od pierwszego szkicu

Biblioteka komponentów daje materiał do zbudowania interfejsu. Potrzebuję jeszcze wiedzy o tym, jaki problem rozwiązujemy, kto będzie korzystać z rozwiązania i dlaczego określony wzorzec pasuje do zadania. Sam poprawny przycisk nie wyjaśnia całego przebiegu pracy człowieka.

Chcę udostępnić tę wiedzę w formie, z której AI może skorzystać podczas tworzenia prototypu HTML. Łączę więc wybrane źródła, komponenty i reguły użycia. Ważna jest również możliwość wskazania braku: jeśli nie mamy wzorca albo nie umiemy rozstrzygnąć konfliktu, potrzebna jest decyzja.

Dla zespołu oznacza to wspólny punkt wyjścia do rozmowy o pomyśle. Dla mnie to szansa, żeby zasady produktu towarzyszyły tej rozmowie już przy pierwszym szkicu. W pilocie trzeba sprawdzić, czy tak przygotowany kontekst rzeczywiście pomaga i ile pracy wymaga jego utrzymanie.

Samodzielne tworzenie i dostęp do designera

Nie muszę uczestniczyć w każdej rozmowie, żeby pomóc zespołowi w tworzeniu prototypów. Mogę przygotować zasady, z których korzysta AI, oraz uzgodnić drogę do review. Osoba rozwijająca pomysł powinna wiedzieć, gdzie pokazać rezultat, jakie pytanie zadać i kto pomoże jej podjąć następną decyzję.

Zależy mi przy tym na widoczności wersji i celu prototypu. Czy oglądamy szkic do dyskusji, materiał do badania, czy rozwiązanie po uzgodnieniach? Sam wygląd interfejsu nie odpowiada na te pytania. Potrzebny jest kontekst pracy, żeby kolejna osoba wiedziała, do czego może użyć tego materiału.

Prototyp traktuję jako sposób przedstawienia i sprawdzenia hipotezy. Przejście do wdrożenia wymaga osobnej decyzji produktowej i technicznej oraz uzgodnionego projektu. Tę granicę chcę utrzymać czytelną również wtedy, gdy kolejne wersje powstają bardzo szybko.

Kontrola reguł i ocena rozwiązania

Automatyczna kontrola może pomóc w sprawdzeniu określonych reguł kodu i interfejsu. Jej wynik trzeba czytać razem z zakresem: co obejmowała, na jakich materiałach pracowała i czego nie udało się ocenić. Zapis wykonanych kontroli pomaga wrócić do tych informacji.

Potrzebuję też oceny zadania użytkownika, struktury informacji i sposobu prowadzenia przez interfejs. Część pytań da się postawić podczas review eksperckiego. Inne wymagają kontaktu z ludźmi, obserwacji lub badania. Zgodność z biblioteką nie daje mi podstawy do ogłoszenia, że rozwiązanie jest użyteczne.

Ważną częścią pracy designera staje się ustalenie, gdzie jego uwaga jest teraz potrzebna. Wspólny widok zgłoszeń i wyników kontroli ma pomagać wybrać temat do sprawdzenia oraz przygotować kontekst tej oceny. Zakres takiego widoku i sposób korzystania z niego trzeba uzgodnić z zespołem.

Decyzja może poprawić więcej niż jeden prototyp

Po review podejmuję również decyzję o zasięgu poprawki. Czy dotyczy pojedynczego rozwiązania? Czy ujawnia brak we wspólnej regule? Czy potrzebujemy więcej wiedzy, zanim cokolwiek zmienimy? Rozstrzygnięcie tej różnicy jest częścią mojego zadania.

Jeśli zmiana powinna trafić do wspólnych zasad, potrzebuje właściciela, uzasadnienia i sprawdzenia skutków. Chcę, żeby zespół mógł wrócić do tego, dlaczego przyjęliśmy dane rozwiązanie. To pozwala też rozpoznać moment, w którym wcześniejsze założenie przestaje pasować.

Tak rozumiem żywy Cortex: użycie dostarcza pytań, człowiek ocenia ich znaczenie, a zaakceptowane decyzje rozwijają zasady. Automatyzacja może pomóc przygotować zmianę i wykonać część kontroli. Odpowiedzialność za to, co staje się wspólnym standardem, musi pozostać określona.

Wiedza z badań i historia wdrożeń

Uzupełnienie z 04.11.2026

Rozwijam Cortex o coś, czego nie chcę zostawiać poza procesem prototypowania: wiedzę, którą już mamy od użytkowników. Zbudowałem moduł Research Studio, w którym transkrypcje rozmów stają się materiałem do insightów i raportów z cytatami powiązanymi ze źródłem. Połączenie go z Cortexem daje tym wnioskom miejsce w kontekście wybieranym przed zbudowaniem prototypu. Nadal muszę ocenić, czy dany wniosek pasuje do zadania i czy rozmowa rzeczywiście uzasadnia taką interpretację.

Weźmy hipotetyczny przykład. Ludzie opisują, że powtarzają tę samą czynność na długiej liście, element po elemencie. Proszą o operacje zbiorcze. Kiedy później prototypuję taki ekran, chcę, żeby agent trafił na tę potrzebę obok komponentów i reguł. A podczas review chcę zapytać, jak propozycja na nią odpowiada. Operacje zbiorcze są jednym z możliwych rozwiązań. Trudnością jest praca, którą ludzie muszą powtarzać. Zachowanie tej różnicy zostawia miejsce na inny sposób jej rozwiązania.

Potem produkt się zmienia. Operacje zbiorcze trafiają na produkcję. Pięć miesięcy później ktoś pyta bazę researchu o największe problemy i dostaje informację o ich braku. Cytaty z rozmów mogą być wierne, a odpowiedź już wprowadza w błąd. Jedna taka odpowiedź daje zespołowi powód, żeby przestać ufać bazie.

Dlatego rozwijam również połączenie wniosków z changelogiem wdrożeniowym. Kamienie milowe produktu mają dopisywać do researchu informację o tym, co się zmieniło, kiedy i dla kogo. Wniosek zachowuje źródło i datę, a powiązane wdrożenie zmienia sposób, w jaki powinniśmy go odczytywać. Dawna obserwacja pozostaje częścią historii produktu. Nie powinna wracać jako niezmieniony, aktualny problem bez uwzględnienia tego wdrożenia.

Samo dodanie funkcji nie mówi mi jednak, czy trudność zniknęła. Ludzie mogą jej nie znaleźć, nie zrozumieć albo nie móc z niej skorzystać w badanej sytuacji. Wdrożenie może zmienić status wniosku na „wdrożono, efekt do sprawdzenia”. Zamknięcie wymaga dowodu dotyczącego rezultatu. Nowa rozmowa, obserwacja lub odpowiedni pomiar mogą potwierdzić poprawę, zawęzić problem do określonej grupy albo pokazać, że pozostaje otwarty.

Chcę móc prześledzić cały ten ciąg: doświadczenie ludzi, decyzję o zmianie, wdrożenie i to, co wydarzyło się później. To rozszerzenie nadal powstaje. Nie ustaliłem jeszcze, jak niezawodnie pomoże utrzymywać aktualność wiedzy. Daje mi jednak kolejne pytanie na moment, w którym „wszystko się zgadza”: czy ten kontekst opisuje produkt, z którego ludzie korzystają dzisiaj?

Kontekst potrzebuje kontaktu z ludźmi

Kontekst zapisuje to, co wiemy. Rozmowa i badanie mogą tę wiedzę zmienić. Dlatego chcę zachować w tym sposobie pracy miejsce na odkrywanie potrzeb, ocenę rozwiązań i kwestionowanie samych zasad. To wymaga czasu oraz udziału ludzi.

Tanner Kohler w artykule The Role of UX in Agentic Software Factories dla NN/g opisuje udział UX w wyborze tego, co warto budować, ocenie wyników i dostarczaniu kontekstu dla AI. Ten podział jest mi bliski, bo pomaga utrzymać pełny zakres pracy designera.

Wraca tu moje Human Speed: czas potrzebny człowiekowi, żeby przyswoić kontekst, ocenić zmianę i świadomie w niej uczestniczyć. Przy organizowaniu prototypowania chcę uwzględnić również ten czas.

Co chcę sprawdzić w kolejnym wdrożeniu

Taki sposób pracy wymaga prowadzenia. Źródła trzeba aktualizować, review wykonać, a decyzje wdrożyć i przekazać dalej. W ofercie uwzględniam więc również operatora, zakres odpowiedzialności i utrzymanie. Te elementy wpływają na koszt całego rozwiązania.

Z tej praktyki rozwijam ofertę pilota Design Cortex. Zaczynamy od jednego produktu, zadania i kryteriów odbioru. Chcę wspólnie sprawdzić spójność prototypu, wysiłek potrzebny do oceny oraz pracę przy aktualizowaniu zasad. Korzyści dla konkretnego zespołu trzeba ustalić na podstawie tej próby.

Gdy następnym razem pokażesz prototyp, spróbuj razem z nim przekazać trzy informacje: do czego ma posłużyć, co już sprawdzono i jaka decyzja jest teraz potrzebna. Od tego zaczyna się dla mnie kontrola nad szybkim tworzeniem.