Designed for Real Users: Gavin's Core Thoughts on Polkadot Products

After a typical payment failure, Gavin realized that payment systems couldn't just serve 80% of people; they had to serve 100% of real users.

At the time, he wanted to download and try a DJ app. The app itself was fine, but because he didn't have his iPad with him, he had to borrow someone else's device to install and use it. To unlock the full functionality, he needed to pay €6.99 for a one-month subscription. What should have been a simple transaction was repeatedly blocked by the system due to factors such as bank verification, international address, and credit card origin.

The amount was small, and the risk was extremely low, but the system still treated it as an "abnormal situation." Apple's system couldn't understand a slightly more complex real-world user.

This isn't a technical problem, but a product design problem. In many Apple product philosophies, there's a default logic: design for 80% of users. As long as most typical scenarios are covered, the few "abnormal users" can be ignored. This approach might hold true in interface design, but it becomes dangerous when applied to payment systems or infrastructure. A payment system cannot serve only 80% of people. It must serve 100% of real users. If a system rejects a transaction because "the situation is uncommon," it's actually prioritizing process standardization and risk control over the users themselves. Efficiency is placed before fairness. This experience made him realize that edge cases are the real test when products enter the real world. Designing the next generation of Polkadot products starts here. Gavin stated that Parity's goal is not only to deliver excellent official products, but also to provide the right infrastructure for the entire ecosystem, enabling independent developers to better interact with users, quickly find their product positioning, and naturally integrate into the ecosystem. In this process, Gavin believes two things are particularly important. 1. User Entry Point Any ecosystem cannot grow if users cannot easily enter. This is especially true when the product involves financial components, making entry point design even more complex. KYC, identity verification, cross-chain asset transfer, account recovery… each step can be an obstacle. However, difficulties are not a reason to give up. The entry point experience determines whether the product truly belongs to the user. If the entry cost is too high, the ecosystem becomes a playground for tech professionals, not a tool for ordinary users. The next generation of Polkadot products must make "seamless access" a fundamental design goal, not an afterthought. The true usability of an ecosystem depends on how easily users can access it. 2. Ecosystem Collaboration In many ecosystems, everyone is chasing the "killer app." But true long-term value doesn't come from a single blockbuster app, but from the synergy between products. If combining two products can create five times the value of the individual product for users, that's true compound growth. This means developers need to: Actively understand existing products within the ecosystem; Think about how to create combined value; Communicate and collaborate with other teams; Don't be shy, but don't be intrusive either. One problem with Polkadot in the past was the lack of strong synergy between products. Each project grew independently, but without truly creating "value synergy." The next stage goal should be to build a "collaborative product ecosystem". To support this collaboration and entry point capability, Parity will continuously deliver a suite of infrastructure, including: Proof of Personhood, serving as a crucial user entry point; Official applications and portals; and tools such as the Polkadot console. These will become vital channels for products to reach users. In addition, it will include more general-purpose infrastructure, such as message storage and decentralized data components. These were mentioned by Gavin many years ago in his vision of Web3 technology, and are now gradually becoming building blocks of reality. In the future, we will also launch: Identity infrastructure (supporting the smooth operation of any existing Web2 components) and key storage on public infrastructure, as well as "Agency" related mechanisms. The goal of this infrastructure is not to control developers, but to empower them. What is "Agency"? Gavin's use of "agency" here isn't a technique, but a very simple stance—you are a person with judgment, not a child who needs to be cared for by the system. "Agency" emphasizes individual responsibility and autonomy. Simply put, it treats people as adults. You don't need a "Big Brother" to make decisions for you. You don't need a "nanny" to manage everything for you. You have the ability to assess risks and take responsibility for your choices. In many Web2 products, the system assumes you are unreliable. It makes judgments for you, controls risks for you, and decides what is "reasonable" for you. But Web3 starts differently. Web3 assumes that users are capable. This doesn't mean there are no security mechanisms, but rather that the system shouldn't treat users as incompetent. If you promise to do something, you must be responsible for it. If you can't, be honest about it. If your decisions have consequences, you bear them. That's true autonomy. At the same time, agency also means that you don't arbitrarily shift responsibility to others. You don't rely on a centralized structure to "cover your losses." You also don't easily transfer risks to others. You can remain open and welcome different opinions. You can change your mind. But that's because you've thought it through yourself, not because someone else has decided for you. In an ecosystem context, this means developers are responsible for their products. Users are responsible for their choices. The system provides tools, but doesn't take responsibility for people's lives. If we don't want to create a system that "designs for 80% of users and ignores 20% of anomalies," what kind of system should we create? The answer is: a system that respects users' judgment. Not a system that shuts users out. It's not a system that makes all decisions for users. It's a system that empowers users and also gives them responsibility. Web3 is not just a technological upgrade, but a tool for reconstructing social rules. If we truly want to build the next generation of Polkadot products, we can't just design for "80% of people." The goal of Web3 has never been to optimize process efficiency, but to restore the agency capabilities of individuals. This means: Products must confront the complexities of the real world and take responsibility for 100% of users. This is not just a product issue, but a value issue. If we understand this, then the next generation of Polkadot products will not just be faster, cheaper, or have higher TPS. It will be more responsible.