Skip to main content
Back
Prototype

Design notes

Why this journey is shaped the way it is, and what I would test next.

Built with the GOV.UK Prototype Kit 13 and GOV.UK Frontend 6. Not a real service, and not affiliated with the FCA or any regulator. The fund, firm and reference numbers are invented.

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 inputmode so 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

  1. 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.
  2. 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.
  3. Is the materiality result trusted? If users override the service's answer or ring the regulator anyway, the explanation is not doing its job.
  4. 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