Design notes
Why this journey is shaped the way it is, and what I would test next.
The problem
When a fund's net asset value is calculated incorrectly, the manager has to decide quickly whether the error is material. That decision changes everything downstream: whether the regulator must be told, whether investors are owed money, and how fast it all has to happen.
In practice the decision is made under time pressure by whoever spotted the error — often an operations analyst at a third-party administrator, not a compliance specialist. It is a judgement call with a defined numerical threshold, which is exactly the kind of judgement a service can take off the user.
The main design decision
The obvious question to ask is "Is this a material breach?" That would be a mistake. It asks the user to interpret regulatory guidance, produces inconsistent answers across firms, and hides the reasoning.
Instead the service asks for the error as a percentage of net asset value and applies the 0.5% threshold itself. The user is then shown which route they are on and why, in one sentence, before committing to a longer journey. The percentage is parsed forgivingly, because these figures get pasted out of spreadsheets and arrive with stray percent signs and commas.
Two consequences worth noting. First, every notification is assessed the same way, which makes the data usable for supervision. Second, the non-material route still explains what the user must do — record it, correct it, tell the depositary — because "not material" is not the same as "nothing to do", and a service that just says "you don't need to report this" would be misleading.
Patterns used, and why
| Pattern | Where | Reason |
|---|---|---|
| One thing per page | Throughout | Each question can be answered from a different source document |
| Check answers before you submit | Before sending | This is a regulatory declaration — the user is attesting to accuracy |
| Confirm pre-held data | Fund details | Reference number lookups fail silently; showing the fund name catches a wrong PRN early |
| Branch on a calculated value | After the value question | Removes a regulatory judgement from the user |
| Task list | Material route only | The material journey is long enough that users will need to leave and return |
| Character count | Root cause | Free text has a length limit downstream; showing it prevents lost work |
| Warning text | Non-material route | A prospectus can commit a fund to a stricter threshold than the guidance |
Accessibility
- Every input has a visible, programmatically associated label
- Question pages use the question as the
h1, so screen-reader users hear the question first - Radio and checkbox groups are wrapped in a fieldset with a legend
- Change links on check-answers carry visually hidden text naming what they change
- Percentage and currency use prefix and suffix elements rather than placeholder text
- Numeric fields set
inputmodeso mobile keyboards are correct, without restricting paste - Materiality is communicated by text as well as tag colour, so it does not rely on colour alone
What I would test, and what would change my mind
- Does the percentage question work at all? My assumption is that users have this figure to hand. If they arrive with a monetary error and no percentage, the calculation belongs in the service and the question order is wrong.
- Is one error percentage enough? Multi-class funds may have a different error per share class. If users cannot answer without splitting it, this becomes a repeating pattern — the sort of change that would ripple through the whole journey.
- Is the materiality result trusted? If users override the service's answer or ring the regulator anyway, the explanation is not doing its job.
- Does the deadline land? The 5 business day clock starts at identification, not submission. Whether users understand that from the current wording is a testable question, and I would expect to get it wrong first time.
Known gaps
This is a prototype, so several things are deliberately absent: server-side
validation with error summaries, a real register lookup, save-and-return,
authentication, and the repeating pattern for multiple share classes. The
routing logic is a single commented function in
app/routes.js — worth
reading, because the branch is the point of the prototype.
Built by Davendra Patel · davendra.com · source on GitHub · LinkedIn