← Wszystkie projekty / Projektowanie produktu
Sep 2025 – Apr 2026 / 7 min czytania
nexos.ai
System projektowy, rozszerzenie do przeglądarki i kluczowe przepływy produktowe dla przestrzeni roboczej AI obsługującej wiele modeli LLM na trzech platformach, od zespołu stojącego za NordVPN.
nexos.ai to platforma do orkiestracji AI: jedna przestrzeń robocza, w której zespoły rozmawiają z najlepszymi dużymi modelami językowymi, pracują z agentami AI oraz zarządzają dostępem, rozliczeniami i governance w jednym miejscu. Produkt wchodzi w skład Tesonetu, wilnieńskiego ekosystemu zbudowanego przez ludzi stojących za NordVPN. Projektowanie dla niego oznaczało projektowanie dla kategorii, która wciąż wymyśla własne konwencje: multi-modelowy chat, biblioteki agentów i AI-first workflows nie miały ustalonego playbooku, kiedy zaczynałem.
Jako Starszy projektant produktu odpowiadałem end to end za kilka powierzchni produktu i pomagałem wyznaczać wzorce interakcji leżące w centrum produktu. Moja praca obejmowała pięć powiązanych obszarów: budowę design systemu, który zunifikował trzy platformy, zaprojektowanie od zera rozszerzenia do przeglądarek Chromium, prowadzenie flow logowania, onboardingu i płatności za subskrypcję, pomoc w definiowaniu domyślnych zachowań chatu i agentów oraz prowadzenie przejścia produktu na w pełni responsywną aplikację webową w miejsce natywnej aplikacji mobilnej.
Produkt działa, a wszystko opisane poniżej jest wdrożone i dostępne na nexos.ai już teraz.
Disclaimer: wszystkie opinie wyrażone w tym tekście są moje własne i nie muszą odzwierciedlać poglądów firmy. Niektóre elementy designu zostały zmodyfikowane względem oryginału.
Moja rola
Do nexos.ai dołączyłem jako Starszy projektant produktu i pracowałem we wszystkich pięciu obszarach wymienionych wyżej, od design systemu przez rozszerzenie aż po przebudowę na responsywny web. Prace były zorganizowane w "village'ach", interdyscyplinarnych zespołach łączących product managera, developerów i designera. Praca w tak zwartym zespole oznaczała, że design nigdy nie działał w osobnym silosie: uczestniczyłem w tych samych codziennych rozmowach co product i engineering, decyzje podejmowaliśmy wspólnie, a odległość między ideą a wdrożonym ekranem była najkrótsza, jaka może być.
Organizacja i jej kultura
nexos.ai odziedziczyło DNA Tesonetu: wysokie ambicje, duże tempo i silne nastawienie na wdrażanie. Kilka innych rzeczy definiowało to, jak faktycznie wyglądała praca, i to one ukształtowały każdy z obszarów opisanych poniżej.
Stała zmiana. Otoczenie wokół village'ów było, delikatnie mówiąc, niestabilne. Firma działała w modelu dostawy zbliżonym do waterfall, a strategia zmieniała się na tyle szybko, że cel produktu mógł się przesunąć z B2B na B2C w ciągu jednego miesiąca. To napięcie nauczyło mnie projektować pod zmianę: trzymać flow i design system na tyle elastyczne, by przetrwały strategiczny zwrot, i szybko przedefiniowywać zakres pracy bez spadku jakości.
Zespół wielokulturowy. Zespół był międzynarodowy, z angielskim jako codziennym językiem pracy: od design critique i standupów w village'ach po asynchroniczną dokumentację.
AI-first, na zewnątrz i wewnątrz. AI było dla mnie produktem i częścią codziennego toolkitu. Na bieżąco pracowałem z Claude, ChatGPT i wewnętrznymi narzędziami AI nexos.ai: do eksplorowania kierunków projektowych, sprawdzania wytrzymałości flow i treści oraz przyspieszania dokumentacji. Projektowanie produktu AI przy codziennym korzystaniu z AI trzymało mnie blisko perspektywy ludzi, dla których projektowałem.
Design system dla trzech powierzchni
Produkt wychodził jednocześnie na webową przestrzeń roboczą, rozszerzenie do przeglądarki i mobile. Każda z tych powierzchni ma zupełnie inne ograniczenia: obszerny panel desktopowy, wąski viewport rozszerzenia i małe ekrany zorientowane na dotyk, a użytkownicy mimo to oczekiwali, że będzie to jeden, spójny produkt.
Zbudowałem design system, który to umożliwił, podzielony świadomie na dwie biblioteki. Product Components to biblioteka komponentów: tokeny, prymitywy i komponenty złożone z wariantami pokrywającymi wszystkie trzy powierzchnie, dzięki czemu jeden komponent mógł zmieniać formę z panelu desktopowego na popup rozszerzenia bez forkowania. Product Patterns to jej behawioralny odpowiednik: dokumentacja zachowań razem z wyglądem, obejmująca sposób, w jaki nawigacja zwija się na różnych breakpointach, jak input chatu reaguje na różne stany i jak układy przełamują się na mobile. To właśnie opisanie responsywnego zachowania na poziomie patternów umożliwiło później przejście na responsywny web bez przeprojektowywania produktu ekran po ekranie.
System stał się wspólnym językiem designu i engineeringu: komponenty mapowały się na kod, a patterny odpowiadały na pytanie "jak to powinno się zachowywać?", zanim trafiało ono do ticketu.
Rozszerzenie do przeglądarki: każdy model, w każdej karcie
Większość korzystania z AI dzieje się w tle innej pracy: czytania, pisania, researchu w przeglądarce. Zmuszanie użytkownika do przełączenia się na inną kartę rozbija ten flow. Zaprojektowałem rozszerzenie nexos.ai dla przeglądarek opartych na Chromium, które pozwala otworzyć rozmowę z wybranym LLM-em dokładnie tam, gdzie użytkownik już jest.
Projektowanie rozszerzenia to projektowanie pod presją: ułamek ekranu, brak miejsca na drugorzędną nawigację i użytkownicy, którzy otwierają je w środku zadania i oczekują natychmiastowej wartości. Wynik ukształtowały trzy decyzje. Wybór modelu stał się obywatelem pierwszej klasy: główną obietnicą nexos.ai jest wybór między modelami, więc przełączenie LLM-a jest jedną interakcją od ciebie, nigdy nie jest zakopane w ustawieniach. Zamiast projektować osobne komponenty dla rozszerzenia, wyprowadziłem kompaktowy wariant gęstości (density mode) design systemu: skondensowane warianty istniejących komponentów, które utrzymują rozszerzenie wizualnie i behawioralnie spójne z główną przestrzenią roboczą. Układ jest też conversation-first: każdy piksel oprawy interfejsu musiał zasłużyć na swoje miejsce, więc interfejs priorytetyzuje rozmowę i pole input, a wszystko inne chowa się w progressive disclosure.
Logowanie, onboarding i płatności: ścieżka przychodu
Odpowiadałem za flow, przez które przechodzi każdy płacący klient: autentykację, onboarding przy pierwszym uruchomieniu, wybór planu i zarządzanie subskrypcją wewnątrz przestrzeni roboczej użytkownika. To najmniej efektowna i najbardziej znacząca część produktu SaaS: każdy punkt tarcia tutaj przekłada się bezpośrednio na stracony przychód.
Logowanie i dostęp do konta zaprojektowałem tak, by wprowadzały użytkownika do produktu z minimum ceremonii, z jasnymi ścieżkami odzyskiwania dostępu i stanami błędów, które wyjaśniają, a nie obwiniają. Onboarding prowadzi użytkownika do pierwszej udanej rozmowy jak najszybciej, odkładając konfigurację do momentu, w którym jest faktycznie potrzebna. Subskrypcja i płatności obejmowały porównanie planów, checkout i pełny cykl życia stanów rozliczeniowych wewnątrz panelu: upgrade'y, downgrade'y, odnowienia, nieudane płatności i fakturowanie. Szczególną uwagę poświęciłem unhappy paths, takim jak odrzucone karty czy wygasające subskrypcje, bo to właśnie tam zdobywa się albo traci zaufanie.
Definiowanie zachowania chatu
Widok rozmowy to rdzeń produktu, a w produkcie AI najmniejsze detale mają największą wagę. Pomagałem definiować domyślne zachowania chatu, zaczynając od pola input, które traktowałem jak instrument: jak rośnie przy wielu liniach tekstu, co się dzieje po wysłaniu, jak zachowuje się w trakcie streamowania odpowiedzi i jak obsługiwane są stany typu edycja czy regenerowanie. Celem było stworzenie inputu, który czuje się przewidywalny niezależnie od tego, co w danym momencie robi model.
Zaprojektowałem też widoki agentów: ekrany, na których użytkownicy przeglądają i wybierają agentów AI z dostępnej biblioteki, kuratorowanego katalogu w stylu marketplace, porównywalnego z agent store'ami w produktach jak Claude czy ChatGPT. Wyzwaniem było uczynienie agentów zrozumiałymi na pierwszy rzut oka: co każdy z nich robi, kiedy po niego sięgnąć i jak zacząć go używać w jednym kroku.
Dzięki temu, że te patterny zostały skodyfikowane w bibliotece patternów design systemu, pytanie "jak input powinien się tutaj zachowywać?" miało jedną, udokumentowaną odpowiedź wspólną dla panelu, rozszerzenia i mobile.
Od natywnej aplikacji do responsywnego webu
Pierwotny plan zakładał dedykowaną aplikację mobilną. Odpowiadałem za strategiczne i praktyczne przełożenie produktu na responsywną aplikację webową: jeden produkt, jedna baza kodu, każdy rozmiar ekranu.
Praca polegała na systematycznym przedefiniowaniu produktu pod małe ekrany: przekształcenie nawigacji tak, by struktura przestrzeni roboczej zwijała się we wzorce odpowiednie dla mobile bez utraty dostępu do najważniejszych akcji, zdefiniowanie reguł breakpointów na poziomie patternów (udokumentowanych w bibliotece Product Patterns, tak by inżynierowie implementowali responsywne zachowanie spójnie, a nie improwizowali ekran po ekranie), oraz przemyślenie na nowo ergonomii dotyku, od obszarów dotykowych (hit areas) i gestów po gęstość informacji, dla komponentów pomyślanych pierwotnie pod kursor i klawiaturę.
Doświadczenie mobilne jest teraz wdrażane w parze z produktem desktopowym, za ułamek kosztu utrzymywania osobnej natywnej aplikacji, a każde udoskonalenie design systemu trafia na wszystkie rozmiary ekranu jednocześnie.
Efekt
Efektem jest spójne doświadczenie produktowe na web, rozszerzeniu do przeglądarki i mobile web, zbudowane na jednym design systemie, działające i dostępne na nexos.ai już teraz.
Design bez precedensu. Projektowanie produktu AI w tym okresie oznaczało projektowanie bez playbooku: nie istniała ustalona konwencja, jak powinien działać multi-modelowy chat, marketplace agentów czy rozszerzenie AI do przeglądarki. Każdy pattern, który wdrożyłem, był pierwszym szkicem dla całej kategorii.
Najpierw zachowanie, potem wygląd. Design system okazał się pracą o największym wpływie, jaką wykonałem przy tym projekcie. Zakodowanie zachowania razem z wyglądem pozwoliło jednemu małemu zespołowi wdrożyć spójny produkt na trzech bardzo różnych powierzchniach.
Usystematyzowanie zwrotu. Udokumentowanie reguł breakpointów na poziomie patternów, z wyprzedzeniem, zmieniło przejście z natywnej aplikacji na responsywny web w systematyczne ćwiczenie, a nie przeprojektowanie ekran po ekranie.
To prawdziwy produkt. Śmiało, sprawdź go.