# Open Questions & Design Tensions Observations from an honest review of the product spec, design system, and design context. None are reasons to change direction — they're the seams where things will stretch first as real users arrive. Each needs time and thinking to address properly. --- ## 1. Terminal character vs. broad audience Monospace fonts, left-rail accents, and CLI-like patterns signal "developer tool" to most people. Notion succeeds with a broad audience partly because it doesn't look technical — it looks like a blank page. The mono-for-conversation choice is a strong aesthetic call, and it works, but it's doing subtle filtering. A marketing manager or small business owner may feel this wasn't made for them before they type a word. **Question:** Is the early beta audience technical enough that this is fine for now? At what point does the terminal character need to soften for broader adoption? --- ## 2. Discoverability gap A blank text input is simultaneously the most open and the most paralyzing interface. The onboarding spec says "no tutorial, no tooltips, the interface is simple enough that it shouldn't need explanation" — that's confident, but it assumes the interaction model is self-evident. It isn't. Notion has `/` commands. ChatGPT has suggestion chips. Solid has nothing yet. **Question:** What's Solid's discoverability mechanism? Something that helps users understand what they can ask for without feeling like onboarding or hand-holding. --- ## 3. Credits vs. "never punish curiosity" The monetization model charges credits for every interaction — conversations, tasks, tool use. The design principles say "encourage agency" and "reward exploration." These are fundamentally opposed. Every time a user tries something to see what happens, it costs them. The profile view puts credit counts front and center (big numbers, transaction log), reinforcing the cost of every action. **Question:** Should credits be less visible during active work, only surfacing when running low? Does the profile credit display need to feel less like a bank statement? --- ## 4. "AI-native" needs concrete patterns The design system is thorough and well-crafted, but it describes a conventional UI: sidebar, chat, cards, buttons, modals. The "AI-native" and "fluid and exploratory" aspirations don't yet have design patterns. What does it look like when the agent proactively surfaces something useful? How does the interface adapt to context? How do users discover capabilities they didn't know existed? **Question:** What are the first AI-native interaction patterns beyond chat? Where should the interface feel different from a standard messaging app? --- ## 5. The 2-column constraint may be premature "Never add a third panel, inspector, drawer, or workflow builder" is the right instinct for V0 leanness. But framing it as "never" conflicts with "powerful to customize." Users will eventually want to reference an artifact while chatting, compare outputs side by side, or adjust settings beyond a simple overlay. **Question:** Should this be reframed as "not in V0" rather than "never" — so it doesn't become doctrine that blocks future evolution? --- ## 6. Onboarding expectation gap The landing page says "Solid does the work." Then the user signs up, fills in their context, and waits. The copy carefully avoids "waitlist" language, but the experience is still: promise of autonomous execution → indefinite wait. This is the first test of the trust the product is trying to build, and the user has zero evidence yet that it delivers. **Question:** Is there something — even small or limited — that could happen before full activation? A taste of the product that validates the promise before the wait? --- ## 7. Empty chat state feels emotionally flat The empty chat state ("Start a new conversation" / "What do you need help with?") is functional but emotionally flat. This is the user's first moment in a new workspace — it should feel inviting, not blank. There are no suggested tasks, no hint of what the agent can do. **Question:** What should the empty state communicate beyond "type here"? How do we make it feel like the start of something — not an empty form — without adding onboarding clutter? --- ## 8. Result cards are one-size-fits-all Agent outputs can be code, data tables, deployed apps, documents, reports, analysis. The result card pattern treats them all the same: title, description, action. The artifact view helps for deep viewing, but the inline chat representation is uniform. **Question:** When should output-type-specific cards be introduced? What are the first output types that need distinct inline treatments?