Product Design
yuse.ai
A complete consumer LLM interface, designed during the period when the field was still working out what one should look like.
Context
When we started in April 2023, ChatGPT had been public for five months and dominated the consumer-LLM conversation. Bard had launched only weeks earlier and was still nascent; Claude was API-only with no consumer surface; Gemini wouldn't ship for another eight months. The patterns we now take for granted weren't yet standardized: how an LLM product onboards a new user, how it shows an error, where it puts model selection, how it organizes history. Each team building in this space was making its own decisions.
yuse.ai was our team's bet on a specific gap: making LLMs accessible and approachable for general consumers who weren't already comfortable with the technology. The product was a web app that wrapped multiple models (GPT, DALL·E, Stable Diffusion, Midjourney) behind a single chat interface, with prompt suggestions and a hand-held onboarding flow that didn't assume users already knew what to ask. The design covered six interconnected flows: chat, error handling, onboarding, settings, auth, and password reset. A complete consumer surface, not a hero-flow demo. Engineering built what design specified.
A note on the artifact: this case study lives as static Figma screens because in 2023–2024, that's what design output was. Designers shipped pixels; engineers shipped code. This was the pre-vibe-coding era, when a designer couldn't generate a working prototype the way one can today. What you're looking at below is the actual deliverable.
TL;DR
14 months. Six flows. A team of six: one PM, three backend engineers, one frontend engineer, and me as the sole designer. PM scoped what to build; I owned how it looked and worked; engineering shipped it.
Four of the flows have design decisions worth talking about: the chat surface, error handling, onboarding, and settings. The other two (auth and password reset) are included as evidence that this was a real product with all the connective tissue intact, but they follow well-established conventions and don't need narration.
One honest limit before diving in: we shut down before launch, so none of the screens below were tested with real users. The design decisions are reasoned, not validated.
Below: a walk through the four substantive flows, then a brief look at the auth + password reset surfaces that close the system.
01 · The chat surface
The main canvas, designed across several states: empty, in-conversation with formatting, conversation with tags, destructive confirmation, and favorited messages. The goal was a chat surface that scaled gracefully from a brand-new user's first prompt to a power user organizing months of history.
From empty state to favorited messages — the chat surface in five states
Non-intrusive empty-state guidance
A numbered card in the canvas shows new users what to do first: pick a model, write a message. Once a conversation exists, a softer "getting stuck? try one of these prompts" card surfaces sample prompts for both text and text-to-image models. The guidance never overlays the input box, so a user who already knows what they want isn't interrupted.
Prompt libraries were one of the defining patterns of 2023–2024 LLM design. The assumption was that general consumers didn't yet know how to prompt, and needed worked examples to get started. The assumption fit our target user. It has aged out: by 2026 most users have internalized prompting, and the pattern has quietly disappeared from mainstream chat interfaces.
Tags as multi-select
Conversations can hold multiple tags. The tag picker is a small checkbox menu, not a single-select dropdown. The structure of the data is legible from the affordance itself. You can see, without trying it, that a conversation can belong to more than one bucket.
Destructive confirmation
Deleting a conversation surfaces a modal with the conversation name and a red "Delete" button. Red because the convention reads as danger; modal because the action is irreversible. The interface should slow you down here.
Favorited messages
Messages can be starred from the message itself. Favorited messages get a tinted background. Not a separate view to dig through, just a visual lift on the same surface where the conversation lives, so it's easy to scroll back and spot.
02 · Error handling
The work I'm proudest of in this project, because it's where I pushed back on the brief.
The PM came to me with a specific ask: a pink banner at the top of the canvas for trial-limit errors, with the prompt suggestions beneath it dimmed to discourage further use. I worked through it and surfaced two problems: the dimming wasn't visually strong enough to read as "disabled," and the pattern only made sense for this one error. A network failure couldn't reuse it; there was nothing to dim, no trial limit to explain. What I proposed instead was a system of three patterns used together, each scoped to a different kind of error, so the product had one coherent error vocabulary rather than a custom treatment for every case.
The PM’s original banner, plus the three patterns I proposed in its place
The brief: pink banner
The starting point I inherited. It worked for the one scenario it was designed for (trial limit reached), but couldn't carry the weight of a general error system. The dimming was too subtle; the layout assumed there was always something to "dim beneath." Both assumptions broke as soon as you tried to apply it to anything else.
Toast: non-blocking warnings
A floating toast in the upper-right names the issue and lets the user dismiss it. The canvas stays fully usable. This is the pattern for anything informational: rate-limit nudges, save warnings, anything where the product itself still works and the user just needs to be told.
Partial-disable modal: a context frame for the error
An over-the-canvas dialog scoped to the surface that's erroring. The framing matters more than the visual: "this conversation is erroring, not the whole site." The user can still navigate the rest of the product, start a new conversation, change settings. The error is contained to one context, and the modal tells them where the boundary is.
Full-disable modal: errors you can't get around
Same modal, harder enforcement: no interaction allowed until the issue resolves. Reserved for errors with no path around them: offline, auth expired, model down, account locked. Letting the user keep typing would only frustrate them; better to be explicit that the product itself is blocked.
The system, in one sentence: three patterns used together as a vocabulary, not as alternatives to choose between. Each one handles a different scope of error: informational, contained, or total. The PM's banner got cut because it tried to do all three jobs at once and didn't do any of them well.
03 · Onboarding
A four-step flow that aimed to do three things, in order: welcome the user, surface the marketing points (tags, model switching), and set up their first conversation. Every screen has a "previous" link so a user who clicked too fast can back out.
Four onboarding screens, plus a branched API-key walkthrough for users supplying their own keys
The third step is the most interesting. yuse.ai offered two ways in: use the platform's hosted API access (free trial, with a usage cap) or bring your own API key. The setup step explains both, then lets the user choose. Choosing "I'll use my own keys" routes to a tiny illustrated walkthrough that points to exactly where in Settings to paste them. Choosing "let you take care of it" skips ahead to the finalize step.
04 · Settings
Tabbed settings covering Account, API Keys, Display, and Usage. The two flows worth walking through are password change (because it shares the validation system with signup) and API keys (because it's the surface the onboarding flow points to).
Credentials management — password change and per-model API key management
Password change
Requires the current password before allowing a new one. Standard security pattern. The same live-validation strip from signup carries over, so the rules a user is being held to are visible while typing, not after submit.
API keys, per model
Each supported model (GPT, DALL·E, Stable Diffusion, etc.) has its own row with its own "Save" button. Saving one key doesn't affect the others. The right pattern for a product that lets users mix self-hosted and platform-hosted access across models.
Usage
A donut chart broken down by model, plus a free-message counter and a token spend total. Sized to leave room for additional data viz blocks depending on what the user is paying attention to: trial users care about free messages remaining, paying users care about token spend by model.
05 · Closing the system: auth & password reset
Both of these flows are included for completeness rather than novelty. They follow established conventions: inline password validation, captcha-protected signup, send-an-email reset with a separate set-new-password screen. The interesting work was making sure the conventions matched the rest of the product's visual language and reused the same validation strip across signup, password reset, and password change in settings.
Reflection
The interesting thing about designing in a space that's actively standardizing is that you get to see, in retrospect, which of your decisions were ahead of the convention and which were idiosyncratic.
Decisions that have aged well: the three-tier error system (toast / partial-disable modal / full-disable modal), the inline validation strip shared across signup, settings, and reset, the per-model API key surface, and the destructive-action confirmation pattern. These all became more conventional as the field matured.
Decisions I'd still defend even though they didn't become standard: multi-tag organization of conversations, and mid-conversation model switching as a first-class action with a visual transition. Both assume a user who treats the LLM as a workshop of different tools rather than a single conversational entity.
Decisions I'd cut on a redo: the prompt library (a 2023–2024 staple that assumed users couldn't prompt, an assumption that aged out faster than expected), the four-step onboarding flow (too long by current standards), and the original pink-banner error pattern, which is why it lives in this case study as a “before” image rather than a final design.
What happened to yuse.ai
We were close to launching when ChatGPT closed the gap yuse.ai was built to fill: the accessible, hand-held entry point for general consumers. By mid-2024 ChatGPT had a free tier with image generation, suggested prompts, and a consumer-friendly onboarding of its own. The team pivoted, couldn't outpace OpenAI's release cadence, and shut the project down. It's a familiar story for products built in the AI wrapper layer in 2023–2024.
What it taught me
yuse.ai was my pivot point as a designer, from UI/UX as visual craft toward product design as a discipline. The 14 months taught me to think about features in both purpose and execution: not just what a screen should look like, but why a feature exists, who it serves, and what business model it fits inside.
The harder lesson was about moat. If a foundation-model lab can ship the same feature in its next release, building on top of its API is a race you can't win. The work I want to do next lives in spaces that large foundation-model companies can't or won't move into in the next two-to-three years: where a product has room to stabilize, where the value is real and sustainable, and where the moat isn't a thin UX layer over someone else's model.