> For the complete documentation index, see [llms.txt](https://matheus-draau.gitbook.io/solana-onboarding-kit/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://matheus-draau.gitbook.io/solana-onboarding-kit/key-observations.md). # 6. What stood out the most Three observations go beyond simply counting problems and reorient the project's perspective. ## The paradox of technical maturity The most technically well-built onboardings, Phantom is the clearest example, are, in some cases, the ones that fail the beginner the most. Phantom is consistent, clean, fast, with good error prevention; and precisely because it assumes a user already fluent in Web3, it fails exactly at the points of greatest risk and irreversibility. **Quality of execution is not the same as fit for the newcomer.** The problem is not that these apps are poorly made, it is that they were made for another kind of user, not for the layperson who is arriving. ## The clean separation between "mechanics" and "welcome" The Meteora case exposes a recurring pattern: the well-rated items concentrate in the *mechanics of use* (control, flexibility, immediate feedback: severity zero), while the poorly rated ones concentrate in *welcome, language, and clarity*. In other words: **for those who already know how to operate, the apps are efficient; what is systematically missing is receiving and teaching whoever arrives.** That border is exactly where an entry-point design system can act without touching the product logic. ## Categorical absence as a category of its own Orca, Kamino, and Meteora do not fail at isolated points, they simply offer no entry layer at all ("the app assumes the user already has everything they need, from knowledge to wallets"). For them, the recommendation is not to refine: it is to build from scratch. This means the design system needs to serve **two distinct regimes**: refining onboardings that exist and founding onboardings that do not. {% hint style="success" %} **The positive counterpoint.** The three best-rated (**Tangem, Backpack, and Exodus**) are precisely the ones that **neutralize the recurring patterns**. Tangem has no critical item; Exodus has impeccable error prevention; Backpack is cohesive and predictable up to the KYC gate. They prove the solutions exist and work, what is missing is systematizing them. {% endhint %} *** ➡️ Continue to [**7. From diagnosis to design system**](/solana-onboarding-kit/conclusion.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://matheus-draau.gitbook.io/solana-onboarding-kit/key-observations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.