What is happening
A modern, user-friendly refund and cancellation experience needed to be introduced into the Driver and Vehicle Internal Solution — a large-scale enterprise platform undergoing modernization as part of the broader ServiceOntario ecosystem.
System Background
The Driver and Vehicle Internal Solution is part of the broader ServiceOntario application ecosystem. It is an internal, over-the-counter platform used exclusively by licensed ServiceOntario agents (“tills”) to process high-stakes citizen services such as identity verification and official document issuance.
👉 Large-scale, multi-team system with complex transactional workflows.
What Problem Are We Solving?
Prior to the modernization effort, cancelling an order was operationally expensive and frustrating for both agents and citizens.
Orders often contained multiple products tied to different departments and business rules. As a result, refund processing required several manual phone calls, fragmented coordination between teams, and lengthy waiting periods before customers could recover their funds.
The modernization initiative aimed to transform this into a guided, transparent, and operationally efficient workflow directly embedded into the application experience.
My contribution
I was responsible for designing and developing the entire order cancellation and refund flow.
Working from UX prototypes, user stories, and discussions with subject matter experts, I engineered the feature architecture while a significant portion of the backend infrastructure was still unavailable.
This required balancing two competing realities:
The UI needed to behave like a production-ready workflow
The backend contracts and APIs did not yet exist
Instead of treating this as a blocker, I designed the system to be state-driven from the beginning, allowing the front-end to evolve independently while remaining ready for future backend integration.
Deep Dive
Extending the Existing Order Architecture Instead of Rebuilding It
Rather than creating a completely separate “refund application,” I chose to extend the existing Order Page architecture already used throughout the platform.
The original page already fetched and rendered detailed order information through an API response. Instead of duplicating screens or introducing temporary workflows, I transformed the order model itself into the source of truth for cancellation logic.
This became a critical architectural decision.
I reshaped the order response structure to support new transactional states such as:
Refund eligibility
Product-level cancellation rules
Order cancellation markers
Relationship tracking between original and cancelled orders
Once these states existed in the data layer, the interface could react dynamically without requiring separate UI architectures.
The same Order Page could now intelligently render:
Refund-eligible products
Cancellation badges
Confirmation alerts
Disabled or protected actions
Cancellation summaries
The result was a far cleaner and more scalable solution:
the workflow became an evolution of the existing order lifecycle rather than an entirely new system.
The page itself never changed.
Only the order state changed.
Transforming Cancellation Into a State-Driven Workflow
The cancellation process itself was designed as a guided multi-step experience intended to reduce operational mistakes while maintaining clarity for ServiceOntario agents.
Instead of exposing a large, overwhelming form, the experience progressively guided users through:
Confirmation
Information capture
Review
Submission
Each step had isolated responsibilities and validation logic, allowing the workflow to remain predictable and maintainable as business rules evolved.
Behind the scenes, the architecture was intentionally designed so that submission did not “navigate to a different system.” Instead, submission transformed the existing order into a new state.
When the mocked cancellation completed:
A simulated API response generated a cancellation order ID
The user was redirected back to the original Order Page
The page re-rendered based entirely on the updated order state
This created a seamless mental model for users:
they were not leaving the order experience — they were witnessing the order evolve.
The benefit of this approach was substantial:
future backend changes would primarily affect data contracts rather than UI architecture.
Engineering Around Missing APIs Without Blocking Delivery
One of the largest technical constraints was that the backend APIs required for the feature were still under active development.
Two critical endpoints did not yet exist:
Cancellation processing
Refundable product retrieval
Waiting for backend completion would have delayed development, stakeholder validation, and UX iteration.
Instead, I engineered the feature around simulated but realistic service behavior.
I created mocked API responses designed to mirror anticipated production contracts as closely as possible. Route-based logic was introduced to emulate transactional behavior using order identifiers and controlled state transformations.
This allowed the application to behave like a production-ready system long before backend integration existed.
As a result, the team was able to:
Demonstrate working flows to stakeholders early
Validate UX decisions in realistic conditions
Continue parallel backend development
Reduce future redesign risk
Most importantly, the architecture itself remained stable.
When real APIs become available, the mocked service layer can simply be replaced without rewriting the UI workflow or state model.
That separation between interface architecture and service implementation became one of the project’s strongest technical advantages.
Impact
The final solution delivered significantly more than a cancellation form.
It established a scalable transactional architecture capable of supporting future order lifecycle states while immediately improving operational usability for ServiceOntario agents.
The project delivered:
A scalable order lifecycle architecture
Clear visibility into refund eligibility
Traceable linkage between original and cancelled orders
Guided operational workflows for agents
Early stakeholder validation despite missing backend dependencies
A backend-ready front-end system built ahead of integration timelines
More importantly, the project demonstrated an engineering approach centered around adaptability:
Design for evolving systems
Build around state, not screens
Decouple UI architecture from backend readiness
Deliver value before dependencies are complete
This is the kind of systems-thinking I bring to enterprise product engineering initiatives.
Next steps
Architecting a Resilient Bank Deposit Flow for High-Volume Service Operations.
Replacing Mocked Data with Production APIs.