MegaGPT — Redesigning the Entry Point of an AI Product

MegaGPT is a Russian AI aggregator: one interface for several neural networks, no VPN, no separate subscription for each.
The task was to close the gap between what the landing page promises and what the product actually delivers.
Role: UX/UI designer, full cycle.

• Not designed by me: the backend, token calculation and model, how the networks generate answers, the authorization flow. I designed a simplified sign-in window and the display of token spend in the interface.
• Worked on: the entry point, information architecture, chat UX, monetization, the account area.

That frame shapes everything below.

Across the AI products I reviewed, one pattern held: services that put an action on the first screen get users to first value faster. ChatGPT and Perplexity offer the action immediately. Syntx and Unitool show a catalog of tools.

MegaGPT asked for several decisions before any action: read the benefits block, understand tokens, pick a model by hand.

The project came in as a redesign of a live product. The brief was "refresh the design." The problem turned out not to be visual.

Two batches of work. First: landing, models page, empty chat: entry and first experience. Second: monetization, states after generation, the account area; it came with four working days.

Constraints: four working days for the second batch, a fixed scope, designs in Figma for desktop and mobile.

I handed the designs of both batches to development with recommendations; the interface is implemented.

The whole process ran in a pair with Claude. I explain how near the end.

The project ran through Claude as an option generator and a systems critic. The architectural decisions stayed mine.

• Claude proposed /models as a conversion funnel with a side panel for picking a model. I rejected it: for an aggregator with a small set of models that is premature complexity, and the advice not to compare models contradicted the USP my research found: price transparency.
• While I was designing error states, Claude proposed a separate "Retry" screen on top of the generation-error screen. I merged them into one state: it was one scenario split into two artifacts for no reason.

The AI held context at a scale I couldn't hold in my head: prioritizing 30 ideas by complexity and effect, and every monetization state across two platforms. What to keep and what to reject was my call.

Acquire → Activate → Monetize → Retain → Return

Fig. 1. From the landing page to the return visit

Observation: products that offer the action before the explanation get users to a first request faster than catalogs do.

Decision 1. A hero with a prompt that leads straight into the chat, not "learn more."
Decision 2. /models is a showcase outside the main path, not a required step. The chat defaults to automatic model selection.
Fig. 2. The request becomes the entry point; the catalog stands apart
Decision 3. "No subscription" → "Tokens never expire". The condition is in the client's wording; I did not design the calculation or commercial parameters, I designed how token spend is displayed.
Decision 4. Monetization is an overlay inside the chat, not a separate page. Four contextual headings for different balance and plan states.
Fig. 3. The payment overlay and the return to the same chat (interactive mockup)
Decision 5. An action panel after the reply, tied to the content type, instead of one universal "retry."
Fig. 4. The action panel after a reply

Hero

Problem: nothing on screen states the main advantage for a Russian audience.
Decision: the line "Access to neural networks without VPN" and a button straight into the chat.
Intent: value reads before the text does.

Chat: the first request

Problem: no first-visit scenario, and a dead end after a reply.
Decision: an empty state with the field in focus, an action panel under every reply.
Intent: the user starts acting on the first screen, with no layer of explanation.

Monetization

Problem: payment sits outside the task, one wording for every situation.
Decision: an overlay in the chat, four contextual headings, a return to the same conversation.
Intent: the paywall doesn't throw the user out of a task they already started.

Account

Problem: a flat list of data; "Delete account" looks as weighty as "Choose a plan."
Users need to see where their tokens go and what they get for their money, or trust in paying never forms.
Decision: five zones: Balance, Plan, Profile, Statistics, Spending history. Account deletion is a separate action with two-step confirmation.
Intent: transparent spending as a condition for paying again.