nexos.ai

nexos.ai is an AI orchestration platform: a single workspace where teams chat with the leading large language models, work with AI agents, and manage access, billing, and governance in one place. It's part of Tesonet, the Vilnius-based ecosystem built by the people behind NordVPN. Designing for it meant designing for a category still inventing its own conventions: multi-model chat, agent libraries, and AI-first workflows had no established playbook when I joined.

As Senior Product Designer, I owned several product surfaces end to end and helped shape the interaction patterns at the heart of the product. My work fell into five connected streams: building the design system that unified three platforms, designing the Chromium browser extension from scratch, owning sign-in, onboarding, and subscription payment flows, helping define the default behaviors of the chat and agent experience, and leading the translation of the product into a fully responsive web app in place of a native mobile app.

This isn't shelf-ware. The product is live, and everything described below is shipped and available at nexos.ai today.

Disclaimer: All views expressed are my own and do not necessarily reflect those of the company. Certain design elements have been modified from the original.

My Role

I joined nexos.ai as a Senior Product Designer and worked across the five streams above, from the design system to the extension to the responsive web rebuild. Development was organized into "villages," cross-functional pods pairing a product manager, developers, and a designer. Working in that tight a unit meant design was never thrown over a wall: I sat in the same daily conversations as product and engineering, decisions were made together, and the distance between an idea and a shipped screen was as short as it gets.

The Organization and Its Culture

nexos.ai inherited Tesonet's DNA: high ambition, high pace, and a strong bias for shipping. A few other things defined how work actually got done, and they shaped every stream below.

Constant change. The environment around the villages was anything but stable. The company operated on a waterfall-style delivery process, yet strategy moved fast enough that the product's target could pivot from B2B to B2C within a single month. That tension taught me to design for change: keeping flows and the design system flexible enough to survive a strategic pivot, and re-scoping work quickly without letting quality slip.

A multicultural team. The team was international, with English as the everyday working language, from design critiques and village stand-ups to async documentation.

AI-first, inside and out. AI wasn't just the product, it was part of my own toolkit. I worked with Claude, ChatGPT, and nexos.ai's internal AI tooling day to day, for exploring design directions, pressure-testing flows and copy, and speeding up documentation. Building an AI product while using AI daily kept me close to the perspective of the people I was designing for.

A Design System for Three Surfaces

The product shipped simultaneously on the web workspace, a browser extension, and mobile. Each surface has radically different constraints: a spacious desktop panel, a narrow extension viewport, and touch-first small screens, yet users expected them to feel like one product.

I built the design system that made that possible, split deliberately into two libraries. Product Components is the component library: tokens, primitives, and composed components with variants covering all three surfaces, so a single component could adapt from the desktop panel to the extension popup without forking. Product Patterns is its behavioral counterpart: documentation of behavior, not just visuals, covering how navigation collapses across breakpoints, how the chat input responds to different states, and how layouts reflow on mobile. Encoding responsive behavior at the pattern level is what later made the responsive web transition feasible without redesigning the product screen by screen.

The system became the shared language between design and engineering: components mapped to code, patterns answered "how should this behave?" before the question reached a ticket.

The Browser Extension: Any Model, in Any Tab

Most AI usage happens around other work: reading, writing, researching in the browser. Forcing users to switch to a separate tab breaks that flow. I designed nexos.ai's extension for Chromium-based browsers, letting users open a conversation with the LLM of their choice directly where they already are.

Designing for an extension is designing under pressure: a fraction of the screen, no room for secondary navigation, and an audience that opens it mid-task and expects instant value. Three decisions shaped the result. Model selection became a first-class citizen: the core promise of nexos.ai is choice between models, so switching LLMs is one interaction away, never buried in settings. Instead of designing bespoke extension components, I derived a compact density mode of the design system, condensed variants of existing components that keep the extension visually and behaviorally consistent with the main workspace. And the layout is conversation-first: every pixel of chrome had to justify itself, so the interface prioritizes the conversation and the input, with everything else collapsing into progressive disclosure.

Sign-in, Onboarding and Payments: The Revenue Path

I owned the flows every paying customer travels through: authentication, first-run onboarding, plan selection, and subscription management inside the user workspace. This is the least glamorous and most consequential part of a SaaS product: every point of friction here is measured directly in lost revenue.

Sign-in and account access were designed to get users into the product with minimal ceremony, with clear recovery paths and error states that explain rather than blame. Onboarding moves users toward their first successful conversation as fast as possible, deferring configuration until it's actually needed. Subscription and payments covered plan comparison, checkout, and the full lifecycle of billing states inside the panel: upgrades, downgrades, renewals, failed payments, and invoicing. I paid particular attention to the unhappy paths, like declined cards and expiring subscriptions, because that's where trust is won or lost.

Defining How the Chat Should Behave

The conversation view is the product's living room, and in an AI product its smallest details carry the most weight. I helped define the default behaviors of the chat experience, starting with the input field, which I treated as an instrument: how it grows with multi-line input, what happens on submit, how it behaves while a response is streaming, and how states like editing or regenerating are handled. The goal was an input that feels predictable no matter what the model is doing.

I also designed the agent views, the screens where users browse and select AI agents from an available library, a curated, marketplace-like directory comparable to agent stores in products like Claude or ChatGPT. The challenge was making agents legible at a glance: what each one does, when to reach for it, and how to start using it in a single step.

Because these patterns were codified in the design system's pattern library, "how should the input behave here?" had one documented answer across the panel, the extension, and mobile.

From Native App to Responsive Web

The original plan assumed a dedicated mobile application. I was responsible for the strategic and hands-on translation of the product into a responsive web app instead: one product, one codebase, every screen size.

This wasn't a matter of letting layouts squish. It meant systematically redefining the product for small screens: transforming navigation so the workspace's structure collapses into mobile-appropriate patterns without losing access to core actions, defining pattern-level breakpoint rules (documented in the Product Patterns library so engineers implemented responsive behavior consistently instead of improvising per screen), and revisiting touch ergonomics, from hit areas and gestures to information density, for components originally conceived for cursor and keyboard.

The mobile experience now ships in lockstep with the desktop product, at a fraction of the cost of maintaining a separate native app, and every design system improvement lands on every screen size at once.

The Outcome

The result is a coherent product experience across web, browser extension, and mobile web, built on a single design system, live and available at nexos.ai today.

Design without precedent. Designing an AI product in this period meant designing without a playbook: there was no settled convention for how a multi-model chat, an agent marketplace, or an AI browser extension should work. Every pattern I shipped was a first draft for the category, not an adaptation of something proven.

Behavior first, appearance second. The design system turned out to be the highest-impact work I did. Encoding behavior, not just appearance, is what let one small team ship a consistent product across three very different surfaces.

Systematizing the pivot. Documenting breakpoint rules at the pattern level, ahead of time, is what turned the move from native app to responsive web into a systematic exercise instead of a screen-by-screen redesign.