Overview
eDiary is a digital court bookings platform for the NSW Department of Communities and Justice. It is designed to replace existing fragmented paper processes with one application across the court system.
The product would grow into dozens of interconnected workflows, and early frontend decisions would be repeated for years, risking a codebase that became harder to evolve over time.
I led the frontend build, i established the design system, architecture and engineering conventions early, building for uncertainty and adding abstractions only once patterns had proven their value.
Building for uncertainty
Before feature delivery accelerated, I created the initial design system and engineering conventions that the wider team would build on. The objective was to establish a consistent foundation that would support developers and designers, and evolve alongside the product as complexity increased.
That meant establishing the core mechanics of the system: design tokens, shared components, naming conventions, implementation standards and the engineering patterns that tied them together. More importantly, it created a common language between design and engineering from the outset, making consistency the default rather than something developers had to consciously maintain.
Because only a small portion of the product had been designed at this early stage, I avoided over-engineering the design system. Instead, I focused on creating a flexible foundation that balanced consistency with adaptability, allowing new components and patterns to emerge naturally as the product evolved.
Evolving the design system with the product
As development accelerated and additional engineers joined the project, I lead the frontend implementation, directing developers and establishing the patterns and standards they needed to move quickly while keeping UI quality high. My focus shifted to ensuring the design system could support that growth without becoming restrictive or unnecessarily complex
As the product grew, many of the recurring challenges weren't individual components, but the interactions between them. Alongside the component library, I established reusable patterns for behaviours such as multi-stage search, filtering, page layouts and other interaction models that appeared repeatedly throughout the application. These higher-level patterns gave developers proven solutions to common interface problems while creating a more consistent experience for users.
Working closely with our product designer was fundamental to this process. We reviewed upcoming features, discussing where existing patterns could be reused, where new abstractions genuinely improved the product, and where implementation complexity outweighed the value of a bespoke interaction. Rather than following a traditional design handover, we evolved a shared language that continuously shaped both the design system and the frontend architecture.
Outcome
The project was released across NSW pilot courts, replacing fragmented paper-based booking processes with a single digital platform.
The platform continued to evolve beyond its initial rollout, with new functionality being added without requiring the frontend to be reworked. That was my original objective: to create a frontend that could grow with the product rather than constrain it. Seeing those foundations continue to support real-world development long after the initial release validated the investment made at the start of the project.
The project reinforced my view that frontend leadership extends beyond delivering features. It involves creating the systems, conventions and collaborative relationships that allow an entire team to build complex software with confidence.