01
Role and ownership
What I led
- The Luna interface, from home and status through to transactions, VAT and personal details.
- A navigation vocabulary built from words customers could say out loud.
- The front-end build of the designed screens, including the responsive behaviour.
Alongside
IN-SYNC colleagues who delivered the tax service and the support behind it. The tax logic and the Government Gateway integration sat with the service and its systems.
What this case does not claim
Measured outcomes, support-call reductions or customer satisfaction figures. The diagrams and screens here are reconstructions of the documented service, not original production captures.
The call
Make position and the next action visible, and keep the tax mechanics with the service.
Rather than
Digitising the old process faithfully and handing customers its screens and its vocabulary.
Why
A faithful copy of an assisted process is compliant and still unusable for someone who never needed to understand it. Customers needed to know where things stood and what only they could do.
02
Making Tax Digital crossed customer decisions, internal work and government systems.
The process moved across staff, Government Gateway, banking, documents, profile information and reminders. The design task was to make position and ownership clear without moving the tax mechanics onto customers.
Registration moved between Luna, customer decisions and Government Gateway.
Each hand-off needed an owner and a visible state, so a customer could tell whether they were waiting on themselves, on IN-SYNC or on HMRC.
Read this diagram as text
The VAT registration flow runs between three places: Luna, the customer and Government Gateway. Registration starts in Luna, passes to the customer for decisions and authorisation, and moves to Government Gateway for submission before the result returns to Luna.
Liabilities became understandable next actions rather than isolated figures.
The overview tied each amount to what it meant and what, if anything, the customer needed to do.
Read this diagram as text
The tax overview flow starts from the customer's liabilities and turns each one into a stated position and a next action, rather than listing figures alone.
Information and the relevant action stayed together, with recovery when access failed.
A document was never shown without what to do about it, and a failed access attempt led somewhere useful.
Read this diagram as text
The documents flow keeps each document next to the action it needs. If access fails, the flow routes the customer to a recovery step instead of ending.
Validation made changes clearer and reduced preventable mistakes.
Personal and business details were checked as they were entered, so an error was caught while it was still cheap to fix.
Read this diagram as text
The profile update flow validates each change before the customer confirms it, so errors are caught before they reach the service.
A failed bank connection became a recoverable task instead of a dead end.
The customer saw what had failed, what to try and how to reach a person.
Read this diagram as text
The bank sync recovery flow starts when a connection fails. It explains what happened, offers a reconnection route and falls back to human support if that does not work.
Reconstruction: portfolio diagrams of the documented service logic, not original historic artefacts.
03
The interface had to work across very different levels of confidence.
Customers ranged from running a business on a phone to never having used an online account for anything financial. Short by default and expandable on demand became a structural rule.
Lower confidence
Needs plain confirmation that the job is done, a product that looks official and a clear route back to a person. Design for reassurance first.
Middle
Uses banking and shopping apps but avoids official tasks. Needs ordinary words and visible consequence before commitment. Design for explanation in context.
Higher confidence
Runs the business from a phone. Needs the shortest viable route, and detail only when it supports control. Design for speed without hiding depth.
04
Digitisation did not have to mean transferring the tax work to the customer.
The product took on visibility. The service kept hold of the mechanics, with a small and deliberate amount of work moving to the customer.
Customer does
Service does
Customer can see
Before: IN-SYNC performs the work.
Customers call because position and next action are invisible.
The compliant failure: the old process, digitised faithfully.
Customers receive the screens and the tax mechanics, whether or not they can act on them.
With Luna: deliberate responsibility.
Customers see where things stand and what only they can do. Staff and systems keep the tax work.
Conceptual summary of the service, drawn for this page. Bar lengths show emphasis, not measured shares.
05
The service was complicated. Luna should not feel complicated.
Home establishes position, Transactions shows the financial overview, and the following screens move into classification, VAT and account information. Drag a phone to pick it up.
Reconstructions based on the Luna product and supplied interface evidence. They show task hierarchy, not original production captures.
The navigation used words customers could say out loud.
- HomePosition and next action
- TaxSelf Assessment position
- VAT“Am I MTD ready?”
- DocumentsSent and produced
- TransactionsPayments and deductions
- AdvancesCredit and repayment effect
- My DetailsPersonal information
Naming VAT readiness as a first-person question turned policy language into something customers could answer about themselves. A yes or a no came before the legislation.
06
Luna went live. The most important measurement decision should have happened before it did.
The available evidence shows a product and service model, not a quantified outcome.
What shipped
A navigation made from customer language, status before tasks, VAT readiness answered directly and financial consequences shown before confirmation. Human support stayed part of the service instead of being treated as failure.
What I would change
I would define contact-reason coding, unassisted completion and time between hand-offs before launch. Those measures are cheap to set up and hard to reconstruct later. I would also test the words harder than the layout. For this audience, the wording often is the interface.