The net value a financial product brings its user is subject to three sets of constraints. Markets decide what can be offered. Users decide what they want, what they can bear and on what grounds they believe. AI decides how much can be done on a person's behalf. Under these three sets of constraints, design reduces to twelve principles in four layers: value, contract, implementation and trust. None of the principles is a preference; each is a consequence of a particular constraint. Violate one, and some term of net value suffers. The principles are also in tension: convenience against confirmation, initiative against interruption, transparency against information overload, speed of iteration against level of assurance. The basis for the trade-offs is still the size of the consequences and whether the result can be verified.
The core of the market constraints is this: time compensation and risk compensation are available to everyone, information advantage is used up in competition, trading costs must be paid, short-term results come mainly from luck, and everything presupposes that promises are kept. The core of the user constraints: what users want is to get tasks done, their decisions are shaped by directional biases, their tolerance is set by its lowest face, and trust is a belief updated by evidence. The core of the AI constraints: the amplification factor is limited by the applicable share, reliability and the cost of checking, and in finance the advantage of prediction diminishes as it spreads. Each of the twelve principles follows from one or more of these.
First, promise only value that markets can provide, the product can deliver and users can verify: returns and direction cannot be promised; costs, execution, discipline and coverage can. Second, measure a product by net value: the result minus the user's own input and the risk the user bears, not by returns alone. Third, place value where it does not disappear as it spreads: lower costs, sustained diversification and discipline, fewer behavioural biases, and enabling people to do what they could not do before. Violate the principles of this layer, and the product promises what markets cannot give, or makes users pay for input and risk they cannot see.
Fourth, write instructions as a mandate: the goal and how it is measured, the constraints, default rules for what is not written down, and a review date; pair the goal with a risk constraint that covers the tail. Fifth, allocate authority by the reversibility of consequences and the cap on losses: the irreversible step is taken by the principal in person, boundaries are enforced by the execution layer, and authority rises and falls with the record. Sixth, put the agent's income and goals on the user's side, handle conflicts of interest through structure rather than disclosure, and let responsibility follow control. Violate the principles of this layer, and the agent optimizes for whatever is measured, or makes mistakes where the user cannot recover.
Seventh, start with tasks that have a high applicable share and are cheaper to check than to produce, and first widen the range the agent can take on in full. Eighth, shorten the stretches no one checks: let the agent stop to ask for instructions or say "I don't know" when it is unsure, and take numbers from data sources and calculation. Ninth, store the mandate, the portfolio and the records as long-lived objects, keep a point-in-time record of what was known at the time, make items under way, awaiting confirmation and blocked visible at a glance, and allow every decision to be replayed. Tenth, keep the level of assurance proportionate to the consequences and the difficulty of verification, validate with statistical and stratified evaluation, and after launch monitor continuously and release in stages. Violate the principles of this layer, and however well the promise is written, it will be distorted in execution.
Eleventh, earn trust with evidence that is highly diagnostic and hard to fake: make process records visible, let users open the raw data and third-party records, disclose mistakes first, and begin with low-stakes tasks. Twelfth, put defaults and presentation on the user's side: put information relevant to the goal first, match the frequency of evaluation to the horizon, and make leaving and withdrawing easy. A user's current way of doing things is also a steady state: respect the habits they already have first, then use their own records to show the results, invite rather than require improvement, and promise only to improve the process. Seek trust proportionate to trustworthiness, not more trust. Violate the principles of this layer, and users either dare not start, or feel secure when they should not.
The principles do not always agree. Confirming every action is safest, but it takes up the user's attention. Proactive reminders prevent missed deadlines, but too many of them get ignored. Showing the whole process is most transparent, but it can bury the key evidence. Stronger assurance is more reliable, but iteration is slower. Respecting the user's habits keeps the user, but simply going along with current practice lets costs such as those of frequent trading accumulate year after year, while pressing for improvement at every turn may drive the user away. These trade-offs have no single answer, but they have a single basis. The more severe the consequences and the harder they are to undo and verify, the more the design should lean towards confirmation, reminders, transparency, assurance and guidance. The lighter the consequences and the easier they are to undo and verify, the more it should lean towards convenience, quiet, simplicity, speed of iteration and respect for habit.
The basis for trade-offs: consequences and verifiability
Five pairs of principles that pull against each other. Drag how severe a function's consequences are (the more severe, and the harder to undo and verify, the further right), and see which way the balance point of each pair moves.
The twelve principles can serve as a checklist for design review: what a new feature promises, and whether that can be verified; whether its level of authority matches its consequences; where it can go wrong, and how an error will be detected; what evidence it produces, and whether users can see it. A "yes" to every item does not guarantee the product will succeed, but every "no" corresponds to a foreseeable loss in some term of net value.
Under the three sets of constraints, a good financial product promises value it can deliver, sets authority by agreement according to the consequences, makes its implementation open to checking, and earns proportionate trust with diagnostic evidence.
Measure by net value, and place value in cost, discipline, behaviour and access.
Write instructions as a mandate, have the principal take the irreversible step, and put income and goals on the user's side.
Start with tasks that are easy to check, shorten unchecked stretches, keep point-in-time records, and keep assurance proportionate to risk.
Make evidence seen and hard to fake, disclose mistakes first, put defaults on the user's side, invite rather than lecture, and make leaving easy.