Reviewing a billing statement should mean checking the proposed invoice or credit note against its evidence. In Zero, the Low Carbon Contracts Company’s internal contract-management platform, operations teams had to move between product areas and manually match records before making that decision.
I led research, problem framing and design for a shared settlement review flow across schemes where LCCC is responsible for payments. The shipped single-PIN flow brought statement calculations, supporting evidence and reviewer actions into one contextual review, removing manual record matching and making the hand-off to finalisation visible.
The context pane patern, mirrored record data and shared confirmation pattern also established reusable approaches for critical decisions across Zero, informing a later effort to make the platform easier to learn as schemes and teams grew.
Task
Enable operations teams to check settlement statements against their calculations and supporting evidence across schemes where LCCC makes payments, with clear reviewer hand-offs before invoice or credit note generation.
LCCC is a government-owned company that manages contracts and payment arrangements supporting investment in renewable electricity, hydrogen, carbon capture and nuclear energy. Its role connects long-term government support with the delivery of energy infrastructure, making dependable contract management and settlement essential to its work.
Zero was the internal contract and settlements platform used to manage this work. Scheme requirements translated into milestones, tasks and binding dates across a contract’s lifecycle. Teams needed a reliable view of what was due, which evidence supported it and whether a contract or statement was ready to progress.
The quality of that information had direct operational and financial consequences. Incorrect calculations, figures or statuses could carry into Finance, create rework and delay payments. Those delays could incur credit interest payable by LCCC. Accurate records, clear responsibilities and timely hand-offs were therefore central to compliance, financial assurance and confidence in the system.
The product also had to support a growing and changing operations team as LCCC took responsibility for more and larger schemes. It needed to help new and experienced colleagues work consistently, preserve the required reviews by two different people, and accommodate scheme-specific calculations and evidence within a common review structure.
This case study focuses on the shared review flow I designed to support Low Carbon Hydrogen Agreements (LCHA) and Contracts for Difference (CfD), illustrated by a hydrogen statement containing one Payment Information Notice (PIN). My brief was to reduce manual effort and the risk of error, strengthen operational assurance, and establish a structure that could scale to other schemes.
The wider rebrand also created room to improve information architecture and interface design alongside the contractual requirements. Bulk actions and broader IA/UI improvements were stretch goals, allowing us to plan for higher volumes and a more intuitive product experience while keeping the first release focused on the core single-PIN review.
Mapping the existing task showed a review split between Contract Management and Settlements. Operators found the contract and PIN, inspected submitted documents and checked calculation data. They then returned through Home, opened Billing Overview and used the Contract ID to find the related bill again.
The interface left operators to reconstruct the connection between the evidence and the financial decision. That created coordination work and an opportunity to select the wrong record. The problem was to remove that manual connection while preserving the separate review and finalisation responsibilities.
The legacy route required operators to check PIN evidence in Contract Management, return through Home and find the related bill using its Contract ID. The redesigned route brought the evidence and decision together within Billing.
Legacy User flow
Re-designed user flow
Refining the table clarified which information belonged in the worklist. One exploration still foregrounded invoice generation before review; another made Review primary. Neither connected the evidence lookup across products. I focused the solution on making review one connected task.
This also supported a wider UX aim: standardise high-use pages around key workflows and establish predictable patterns for reviewing evidence, confirming decisions and showing progression.
Task-relevant data; invoice generation still leads.
Review becomes primary; the evidence lookup remains disconnected.
The early Billing worklist exposed Invoice, Reject and Approve actions without giving operators a coherent view of what they were about to approve. I made review the entry task, with generation following review and finalisation.
Generating an invoice created work in a downstream Finance system. Its issue date also determined the due date, so a static document created too early could fall out of step with later changes.
The expanded worklist revealed the Contract → Statement → PIN relationship and provided a Review action for the selected PIN. Operators could enter the review before choosing an outcome, creating a checkpoint for inspecting the statement before it progressed towards generation.
I explored expanding PIN detail inline in the Billing table. It preserved the queue and exposed record relationships, but increased density and left little room for a coherent statement preview.
I proposed a contextual drawer to separate scanning the queue from reviewing a statement. Working with Product, Business Analysis and Engineering, we combined the useful elements: the worklist retained identity and status, expansion revealed Contract → Statement → PIN, and the drawer brought calculations, supporting evidence and reviewer actions together.
This gave operators a functional view of the proposed financial output, with access to authoritative PDF and CSV evidence, without generating the final document. It removed the cross-product lookup and manual Contract ID match.
The trade-off was space: long financial tables needed careful hierarchy and scrolling, with clear close behaviour and deliberate keyboard and focus handling. The preview supported the decision; it was not a pixel-identical issued PDF.
The drawer supported the required reviews by two different operations colleagues using the same evidence surface. Role permissions determined the actions available at each stage; Generate invoice or Generate credit note became available after the second review.
Interim product UI · calculations, supporting evidence and reviewer actions.
I separated choosing an outcome from confirming it, while preserving the first reviewer’s Approve/Reject responsibility and the next reviewer’s Finalise/Reject responsibility. The interface needed to make the commitment and the next person’s task clear.
Choose
Confirm
Hand off- Review confirmed acknowledges approval; Awaiting Finalisation tells the team what happens next.
Review confirmed acknowledges approval; Awaiting Finalisation tells the team what happens next.
A shared confirmation dialog followed the selected action, with acknowledgement, Submit and Cancel. Keeping it generic supported reuse, but it did not repeat the action or record identity: meaning depended on the choice immediately before it.
After first-review approval, Review confirmed acknowledged the event. The persistent Awaiting Finalisation status showed the hand-off after the temporary toast disappeared.
Together, the role cues, confirmation and lasting status established a consistent way to communicate responsibility and progression in a consequential workflow.
Step 1: Enter Settlements from Home, opening Billing Overview.
Step 2: Find and open the billing statement.
Step 3: Reveal its Contract, Statement and PIN relationship.
Step 5: Check calculations, supporting evidence and statement information.
I moderated five internal sessions between 27 August and 5 September 2025, with participants of mixed workflow familiarity. The connected direction was broadly understood and valued, while the sessions exposed specific problems.
The entry wording suggested immediate approval.
“Ready for Billing” implied progress towards issuing, and “Approve Statements” sounded final although it opened review. The revised entry used “Awaiting Review” and “Mark as Reviewed”; Approve/Reject stayed inside the review, followed by a separate confirmation boundary.
The hierarchy needed clearer explanation.
Four participants initially misread the expanded hierarchy or arrow. The response clarified the relationship between records while preserving direct access to PIN evidence.
Rejection needed a visible route forward.
Participants expected rejection, correction and visible progression. The core flow provided Reject and approval status; PIN-level reasons followed in later increments, while activity history remained in Contract Management.
Some understanding followed facilitation.
Revised labels and the completed rejection flow were not formally retested in the available record. Unaided comprehension and recovery therefore remained priorities for the next research phase.
The shipped flow gave operations a connected checkpoint for billing review. Financial evidence was available where the decision happened, manual record relocation was removed, and the hand-off to finalisation was visible.
Evidence at the decision point
Statement calculations, supporting evidence and reviewer actions were brought into one contextual review.
Manual record matching removed
Operators no longer needed to leave the evidence, return through Home and relocate the related bill using its Contract ID.
Reviewer hand-off made explicit
Confirmation acknowledged the first review, while persistent status showed that the statement awaited finalisation.
What I carried forward
The most useful shift was treating billing review as one connected decision: which record is this, what supports it, and who acts next? That provided a clearer basis for both the interface and conversations about scope.
The contextual review pane, mirrored record data and consistent confirmation dialogue also provided reusable patterns for critical workflows. The later IA uplift built on that direction, aiming to make Zero easier to learn and use as schemes expanded and teams changed.
I went on to shape, design and release multiple-PIN, bulk-review and IA improvements with the team and helped commit them to the roadmap before I left. They shipped afterwards.
I would next test comprehension without facilitation and observe review time and corrections in everyday use.
Explore the design alternatives, research findings and annotated flow behind the case study.