A technically impressive demo can still leave me wondering why the product should exist. The engineering may be difficult and the result may look new. Neither tells me whether it deserves a place in someone's life.
I prefer to begin with a less glamorous question: what is the person trying to do, and what is getting in the way? That question often exposes whether a team is solving a real problem or defending a tool it already chose. It also changes the conversation. Instead of asking how much capability can fit into a product, we can ask how much of it a person can understand and use without giving up more than they intended.
My work has included self-sovereign identity, verifiable credentials and personal AI products. These fields use different language, but they keep returning to control. Who can see something? Who can act? Can a decision be changed later? A system can answer those questions correctly in a technical document while leaving the person using it with no clear answer at all.
The tool is not the starting point
Starting with a tool creates a subtle pressure to justify it. Once a team has decided that AI, a credential or a particular infrastructure is the answer, every user problem begins to resemble the question it was built for. It is an understandable bias. It is also how technically polished products become strangely irrelevant.
I have seen product discussions become absorbed by what is possible at the infrastructure layer. Those discussions are necessary, especially when trust and sensitive information are involved. But a person does not experience an architecture diagram. They experience a request they have to interpret, a choice they may not understand, and the result of whatever they decide.
This does not mean every product should remove friction. Confirming a sensitive action should take a moment. Giving meaningful consent may require more than one click. A warning can be annoying and still be useful. The important part is knowing why the friction exists and whether it helps the person make a better decision.
Product language can make that harder to see. Words such as seamless, intelligent and user-owned are often used before anyone has explained what changes for the person on the other side of the screen. I want to know what they can do now that they could not do before. I also want to know what happens when they make a mistake. If an ordinary mistake can only be repaired by an expert, the interface has left an important part of the work unfinished.
Identity made the problem concrete
In my work across digital identity and personal AI, the difference between technical control and usable control became difficult to ignore. Digital identity made it especially clear because the information involved can affect access to services and how much of a person's life becomes visible to an organisation.
A well-designed digital credential can let someone prove only what is needed, without defaulting to another copy of the underlying document. That potential matters, but it is not the whole experience. The person still has to recognise what is being requested, understand what will be shared and decide whether the request makes sense.
The wording matters. A request to prove that someone meets a condition is different from a request for the underlying document, even if both appear as a button in the same interface. A product that preserves that distinction in the technology but blurs it in the language has missed part of the point. The user may agree without knowing how much they have agreed to reveal.
There is also a risk of moving responsibility in the wrong direction. An institution may collect less data while the individual is asked to manage unfamiliar concepts and carry the consequences of getting them wrong. Decentralisation does not automatically solve that problem. It can leave someone unsure where their information went or what to do after losing a device.
I do not see those problems as arguments against the model. They are reasons to treat the surrounding experience as part of the identity system itself. Permissions, recovery and revocation are not secondary screens to complete after the important work. For the person using the system, they are the important work.
Consent has a life after the click
Consent is often designed as a moment: read this request, make a choice, continue. The consequences last much longer. Information can remain available, permissions can stay active, and the purpose behind an original request can change. A person needs some way to understand that continuing relationship without reconstructing it from technical logs.
This is where many claims about ownership become difficult to test. A person can hold a right in a technical sense and still have little practical power over it. If changing a decision requires specialist knowledge, the right exists but remains hard to use. The interface should make the current state legible: what is active, who is involved and what will happen if access is withdrawn.
None of that requires exposing every part of the machinery. Most people do not want an architecture lesson before completing a task. They do need a dependable mental model. They should be able to predict what an action will do, notice when the state has changed and find the place where they can change it again.
Recovery belongs in the same conversation. Losing a phone, forgetting how an account was set up or misunderstanding a permission should not turn control into a permanent lockout. Recovery always introduces another form of trust, which is why it cannot be added casually at the end. The question is not whether trust disappears. It is whether the person can understand where it sits and what protections surround it.
Reversibility will not be possible in every system. Some actions have consequences that cannot be undone. In those cases, the product should make the boundary unmistakable before the action happens. A vague confirmation followed by an irreversible result is not meaningful control.
What a personal AI remembers
Personal AI makes these questions more intimate. An assistant becomes more useful as it learns how someone works. It may remember preferences, relationships and unfinished thoughts. That context can save time and make the product feel less generic. It can also become a record the person never intended to maintain.
Memory should not be treated as a single switch. There is a difference between using something in the current conversation, keeping it for later and allowing it to influence an action taken on the person's behalf. Those differences need to be visible at the point where they matter. A settings page found months later is not enough.
Deletion needs similar care. Removing a conversation from view may not answer whether its contents still shape future responses. A person who corrects an assistant should know whether the correction applies once or changes what the system remembers. These are product questions, not merely explanations for a privacy policy.
The boundary becomes more important when an assistant can act. Drafting something is different from sending it. Finding an option is different from choosing it. A useful product can move quickly while keeping those boundaries clear. When the consequence grows, I want the person closer to the decision, not hidden behind a broad approval given earlier.
Uncertainty should change the experience
I am cautious when "AI-powered" is presented as a benefit by itself. A model may remove tedious work. It may also produce another layer for the user to verify. The difference becomes visible when the answer is incomplete, the context is stale or the system is simply wrong.
A product cannot promise that those moments will disappear. It can decide how to behave when they arrive. Sometimes the right response is to ask a question rather than make an assumption. Sometimes it is to show the person what information shaped the answer. If the system is about to act, a preview and a chance to stop it may matter more than another improvement in speed.
This changes how I think about convenience. The fastest path is not automatically the best one. A product should be quick when the cost of a mistake is small and more deliberate when the consequence is harder to reverse. That balance cannot be decided by the model alone. It is a product decision, and the team remains responsible for it.
The standard I use
My test is practical: after using the product, can the person tell what happened and what options remain? I look at ordinary actions such as granting access, correcting an error, recovering from a lost device, changing a remembered preference or leaving a service. If those moments are confusing, the product's claim to give people control is not yet supported.