CASE STUDY · DESIGN SYSTEMS · 2024 – 2025
NTT Data Services / Government of British Columbia
Justice Services Branch — Senior Product Designer + Service Designer

Justice,
finally modernized.

A 20-year-old Oracle desktop system serving citizens, front-line staff, and senior executives — sixty officials with veto power at every sprint, and no Plan B if the design wasn't approved. I led product and service design end-to-end: human-centred research, co-design workshops with executives and front-line staff, journey maps and service blueprints, 200+ shipped screens, two phases of usability testing — delivered four weeks early, with the buffer spent converting the system into a modular, AI-assisted toolkit.

Role
Senior Product Designer
+ Service Designer
Client
Gov't of British Columbia
Employer
NTT Data Services
Branch
Justice Services
Duration
10 months
Year
2024 – 2025
80%
Q1 adoption on a new platform
200+
Screens designed & shipped
60+
Senior stakeholders aligned
−4wks
10 months on a 12-month contract
Section 01 / Context

The system that almost wasn't.

The brief

The Justice Services Branch of the Government of British Columbia had been running on an Oracle desktop application for over twenty years. It needed local installs. It didn't work on tablets. It didn't work from home. The service it supported — from front-line intake through case management to executive reporting — was bottlenecked by the software underneath, and split awkwardly across channels (desktop, paper, phone) it was never designed to span.

NTT Data Services was contracted to migrate the system to the web. My job: design every screen, build the design system to support it, map the end-to-end service journey, and shepherd all of it through approval by a 60-person leadership group with veto power at every sprint review.

There was no fallback. If consensus broke down, the contract ended and the Justice Group stayed on Oracle.

The stakes, plainly
No Plan B. Just consensus, by way of biweekly sprint reviews, in front of sixty senior justice officials.
Section 02 / Approach

Three constraints, in tension.

My framing

The first month wasn't design — it was diagnosis. I needed to name the constraints that would shape every decision after, because in a project this politically loaded, the wrong frame quietly kills the work months later.

I landed on three.

01

Honor the existing service journey.

Senior users had built years of muscle memory around the Oracle workflow — and that workflow carried a real service path, from intake to disposition. The new web app had to preserve the end-to-end journey while modernizing the surface. I argued, repeatedly, against redesigning steps that already worked. Modernize the surface; preserve the path.

02

Inherit, but don't copy.

The government already had a design system for content websites. It was the wrong fit for a web application — denser data, more interaction, persistent state — but it was the visual language the public knew. I extended the language for an application context without forking the system. Same vocabulary, new sentences.

03

Approval is the deliverable.

The system wasn't done when it was beautiful. It was done when sixty senior justice officials said yes. That meant rituals, framing, and a feedback loop more disciplined than the design itself. I built the cadence as carefully as I built the components.

Section 03 / The Design System

A web-app system, on top of a website system.

Foundation

The Government of BC's existing design system was built for content websites — typography, navigation, marketing components. Web applications are a different animal. They need data tables with sorting, filtering, and bulk actions. They need persistent navigation, modals, dense forms, status indicators, audit trails. None of that existed.

Working with the government's design team and Justice Group leadership, I built a parallel system that inherited the public-facing visual language and reorganized it around application patterns.

Decision 01

The footer had to go.

The website system reserved 200+ vertical pixels for a global footer. In an application where users live in data tables all day, that space mattered more than brand reinforcement. We won the argument by showing what one extra row of data felt like across two hundred screens. Approved by leadership in week three.

Decision 02

Build the table from scratch.

The website system had a basic display table — rows, columns, the end. The application needed a workhorse: column resize, sort, filter, pagination, row selection, bulk actions, inline editing, sticky headers, density toggles. This single component took six iterations and three dedicated workshops to lock down.

Decision 03

Document for handoff, not for the wall.

I built a design and service documentation library — components, journey maps, service blueprints, process diagrams, user stories — so developers, QA, and future designers could reference the system without me being the bottleneck. Every component, every state, every interaction — documented as I designed it, not after.

Decision 04

Map the service before drawing the screens.

Before a single component was drawn I ran co-design workshops with both front-line staff and executives, then translated what I learned into journey maps, service blueprints, and process diagrams. Every screen we later designed traced back to a documented step in a documented service. It's also why scope creep stayed contained across ten months.

Fig. 01 — Application component inventory (abstracted) Confidential — illustrative
Data Table
01
Buttons
SaveMore
02
Form
03
Tabs
04
Modal
05
Toast
SAVED 09:42
06
Stepper
07
Status
ActivePending
08
Side Nav
09
Search
10
Pagination
123
11
Dropdown
Status
12
Legacy — Oracle desktop~2004
JUSTICE.EXE — [CASE LIST]×
FileEditViewRecordsHelp
IDNAMESTATUSDATE
4023OPEN03/11/04
4024HOLD03/11/04
4025OPEN03/12/04
4026CLSD03/12/04
4027OPEN03/13/04
New — Web application2025
Section 04 / The Application

200 screens. 60 stakeholders. Biweekly reviews.

Execution

I designed and presented every two weeks during sprint review, in front of 60+ senior justice officials — and ran parallel co-design workshops with front-line staff between sprints. Each review surfaced new edge cases: a service step we hadn't mapped, a permission state we hadn't accounted for, a phrase a user wouldn't understand.

Over ten months we ran two phases of usability and concept testing, produced 200+ screens for a clickable walkthrough, journey maps and service blueprints for the full case lifecycle, and a roadmap document for what came after the migration. The contract was for twelve months. We finished in ten.

Fig. 02 — Ten months of work, on a twelve-month contract Delivered −4 weeks
Research & workshops
Design system v1
Lo-fi → hi-fi prototypes
Usability — Phase 1
Final screens · Dev handoff
Usability — Phase 2
AI-assisted modular system
M1
M2
M3
M4
M5
M6
M7
M8
M9
M10
Design phase Research / testing Buffer → AI-powered modular design system
Worked with — 01

Program teams & front-line staff

Co-designed processes and policies with executives and the people doing the work. Ran field research, journey-map workshops, and concept testing — the inputs that shaped every later decision.

Worked with — 02

Front-end developers

Paired during component build to guide implementation. Adjusted specs where engineering reality didn't match design intent — and held the line where it did.

Worked with — 03

Architects & DB designers

Kept the data model honest. Pushed for UX improvements that didn't compromise data integrity — accepted constraints when they did.

Worked with — 04

QA & service performance

Ran design QA against the spec and helped define the post-launch performance measures — adoption, time-on-task, error rates — that told us whether the service was working, not just the software.

Section 05 / Impact

What shipped.

80%
Q1 adoption
The design held. Muscle memory still in transition — by users' own admission.
200+
Screens shipped
Designed, prototyped, and handed off with documented specs for every state.
−4wks
Delivered early
Ten months of work against a twelve-month contract. Four weeks of buffer.
+1sys
AI-assisted system
Built in the buffer time. Modular, generative, maintainable by the team after I rolled off.
Outcome

The application replaced a 20-year-old Oracle system and re-platformed the service end-to-end. Migration is ongoing — first-quarter adoption sat at 80%, and senior users were honest that the rest would take time as muscle memory transferred.

Their feedback was unanimous on the thing I cared about most: the design worked. The service held.

With four weeks of unspent contract time, I converted the design system into a modular, AI-assisted toolkit — components, journey maps, and service blueprints all searchable, generative, and maintainable by the team after I rolled off.

It's still in use.

Section 06 / Reflections

What this taught me.

i.

Approval is a craft.

I came in thinking the design was the deliverable. By month three I knew the narrative around the design — the rituals, the framing, the language I used in front of sixty stakeholders — was at least half the job. Senior designers don't just design. They translate the design for people who don't speak design.

ii.

A design system is only as good as its handoff.

The system shipped well because we documented everything alongside the work — components and journey maps, states and service blueprints, interactions and the policy decisions behind them. The documentation took as long as the design. It was worth it.

iii.

Honor the legacy.

I'm proud of the new application. I'm prouder that we preserved the muscle memory of the people who used the old one for twenty years. The most senior designers I've worked with share this instinct — respect what came before, even as you replace it.

Gurcharanjeet
Singh Kauldhar.

Senior product and service designer working at the intersection of systems, services, and senior stakeholders. Currently exploring next roles — gurcharanjeetsingh@gmail.com.