Case study / tolling & transit / web, mobile & responsive
E-ZPass · New York & New Jersey

Rebuilding how millions of drivers pay a toll.

I grew from responsive design into end-to-end ownership of E-ZPass billing and payments across web and native mobile for New York and New Jersey.

Problem: Drivers had to hunt for their balance and payment methods, then work out what they were paying and whether it had gone through.

68% → 92%Found their balance and chose a payment method without help.Usability testing
62% → 94%Correctly understood payment status.Usability testing
36 → 14Payment-status support contacts per 1,000 payments.Program team data

Separate controlled walkthrough: one-time bank payment, roughly 45 seconds to under 12. Results and methods ↓

Redesigned E-ZPass Tolls NY homepage
The redesigned E-ZPass account experience I designed, shipping from July 2023 onward and approved as Tolls NY.
01 The problem

A civic service with an interface from another decade.

E-ZPass is not optional for most drivers in the Northeast, making every rough edge a real cost paid by customers who require this software. Three conditions shaped the work.

01

Critical tasks were buried

Dense tables, small fields, jargon, competing alerts, and weak hierarchy made it difficult to find the right task, understand account status, or recover when money was involved.

02

The system exposed its complexity

Authority rules, plan codes, payment types, and account conditions appeared as system concepts instead of clear customer decisions. Drivers had to understand the organization before they could complete a task.

03

Mobile features were adapted instead of designed

New website features were routinely converted for smaller screens after desktop decisions had already been made. I established the responsive experience, then expanded my ownership across native mobile and web so each platform could support the same product intent without simply shrinking desktop.

1 / 3Flick a card to shuffle
02 How it works

What actually happens when you pay a toll.

The product spans four jobs. The redesign treated them as one connected account, not five separate screens bolted together.

01

Sign up

Open an account, add a vehicle, pick a plan.

→
02

Choose a plan

Standard or a commuter discount, per bridge or road.

→
03

Get billed

Tolls post to the account. Statements summarize activity.

→
04

Pay

Auto-replenish, or pay a bill directly from a bank or card.

03 Process

Seven decisions that shaped the redesign.

The interesting part of this project was not the screens, it was the calls made to get there. The screens are the output. This is the thinking that produced them, including surfaces the product never had before, pay types, disputes, support, collections, and correspondence, designed from zero.

Prioritization

Started where value breaks

I pulled analytics on the account flows and started where money and trust changed hands. Payments and statements had the clearest drop-off, and failure in those moments carried more customer and business risk than a cosmetic problem anywhere else. That gave the redesign a product order, not a visual order.

Reframe

The problem underneath the problem

The legacy flow looked like a navigation problem. The evidence pointed to trust. Drivers needed to know what a plan would cost, what would happen after they pressed pay, and how to recover when something failed. I reframed five separate portals as one connected account built to answer those three questions.

Constraint

Simplified the experience, not the rules

NY and NJ, multiple toll authorities, and legal language that could not be designed away. I separated what had to stay legally exact from what could become clearer through hierarchy, sequence, and shared patterns. The goal was never to pretend the system was simple, it was to make the complexity navigable.

Results

A clearer payment flow, completed faster

In usability testing, finding a balance and choosing a payment method without help rose from 68% to 92%. Correctly understanding payment status rose from 62% to 94%. Separately, my controlled one-time bank-payment walkthrough went from roughly 45 seconds to under 12.

System

Shared core, controlled variation

One product language does not mean flattening real policy differences. I separated what should stay shared across authorities from what genuinely had to vary, so the result reads as one coherent product with controlled exceptions instead of forced consistency.

Communication

Made decisions legible

I presented the flow directly to executive and agency stakeholders, framing the decision through policy, customer risk, and implementation cost so the team could align on a direction that worked across New York and New Jersey.

Accessibility

Built it in, not bolted it on

A public toll service has to work for everyone forced to use it. I moved contrast, focus behavior, and labeling rules into shared components so accessibility repeated wherever those components were used.

1 / 7
04 Before & after

Same tasks, rebuilt around clarity and control.

I designed from screenshots of the live product, since the source files were not accessible, so these befores are the real state I worked from.

Explore secondary cross-platform visuals.Homepage + responsive comparison

The front door

Legacy E-ZPass homepage Redesigned Tolls NY homepage BeforeAfter
Drag ↔
↔
Before, where it broke down
  • 1
    Buried tasks. The things people came to do were hidden inside a text nav bar.
  • 2
    No hierarchy. Every element competed for attention, nothing said start here.
  • 3
    Alert overload. Messages, promos, and shortcuts all shouted at once.
After, what changed
  • 1
    Four clear entry points. Pay a bill, log in, open an account, on-the-go, as large tappable targets.
  • 2
    One obvious start. A single hero over a real image of the road focuses the eye.
  • 3
    Calmer surface. Alerts live in their own place, tasks lead the page.

From desktop adaptation to responsive product design

Dense legacy E-ZPass dashboard on desktop and squeezed into a mobile viewport
Before: the desktop information architecture was compressed for a phone, preserving its tables, competing alerts, tiny actions, and internal system structure.
Redesigned E-ZPass dashboard on desktop and intentionally responsive mobile
After: the same product intent becomes a platform-specific hierarchy: status first, one dominant action, stacked tasks, and touch-sized controls.
Before, heuristic evaluation
  • 1
    Aesthetic and minimalist design. Tables, alerts, links, and utilities competed at the same visual weight.
  • 2
    Match with the real world. Authority codes and account-system language appeared before customer goals.
  • 3
    Recognition rather than recall. Customers had to remember where statements, correspondence, pay types, and account actions lived.
  • 4
    Flexibility and efficiency. Desktop tables and side rails created too much density on a small screen.
After, design response
  • 1
    Prioritized hierarchy. Balance, status, and the next likely action lead every viewport.
  • 2
    Customer language. Tasks are organized around what people need to do, not the authority's internal structure.
  • 3
    Responsive reordering. Mobile changes sequence and disclosure instead of shrinking desktop.
  • 4
    Consistent cross-platform intent. Web, responsive, and native mobile share states and goals while using patterns suited to each platform.

Five disconnected screens, one customer problem

Each page exposed a different piece of the system and left the customer to assemble the meaning.

Five-screen legacy E-ZPass journey showing account overview, plan selection, payment setup, payment review, and confirmation with transaction history
Legacy journeySystem structure exposed to the customer
Five-screen redesigned E-ZPass journey showing a prioritized dashboard, understandable plan selection, saved payment methods, consequence-aware review, and explicit payment status
Redesigned journeyCustomer decisions, consequences, and status made visible
01 / Overview

Status without priority

Balances, violations, vehicles, statements, messages, and payment tools competed at once. The redesign introduced a task-led dashboard and clearer account status.

02 / Plans

Codes instead of choices

Customers had to decode authorities, abbreviations, eligibility, and prepayment before choosing. Plan cards made coverage, qualification, and cost visible before commitment.

03 / Setup

The organization became the form

Primary and secondary payment rules, bank fields, card fields, and authorization copy appeared together. The new flow disclosed one decision at a time and added clearer pay-type paths.

04 / Review

Data repeated, consequences hidden

The page verified entered values but did not foreground timing, account impact, or what would happen next. The redesign turned review into an explicit decision checkpoint.

05 / Confirmation

Success was treated as finished

A receipt could say submitted without explaining processing, posting, rejection, reversal, or recovery. I designed payment status as a continuing system, not a single confirmation page.

Choosing a plan

Legacy plans table Redesigned Add Another Plan cards BeforeAfter
Drag ↔
↔
Before, where it broke down
  • 1
    Coded table. Plans were a dense checkbox grid with codes like MCC and NRC.
  • 2
    Decode, not choose. Users had to translate jargon before they could pick.
  • 3
    Unexplained prepayment. Required amounts appeared with no reasoning.
After, what changed
  • 1
    Plain-language cards. Each plan is a card with a real name and what it covers.
  • 2
    A choice reads like a choice. Name, the tags it applies to, and its cost, on each card.
  • 3
    Cost before commitment. The price sits on the card, before you add it.

Make the amount clear, the payment easy to find, and the outcome unmistakable.

Research showed: Drivers had to hunt for their balance and payment methods. They also needed to understand what they were paying and whether the payment had succeeded.

So I changed: I made the balance and payment options easier to find, clarified what the payment covered, and made successful completion explicit.

What improved: In usability testing, finding a balance and choosing a payment method without help rose from 68% to 92%. Correctly understanding payment status rose from 62% to 94%.

Separately, post-launch operational data shared by the E-ZPass program team showed payment-status support contacts falling from 36 to 14 per 1,000 payments.

Legacy bank account form Redesigned Banks and Cards BeforeAfter
Drag ↔
↔
Before, where it broke down
  • 1
    Dropped into raw fields. Routing and account numbers with no framing or context.
  • 2
    Wall of legal text. Authorization copy buried the one thing the user came to do.
  • 3
    No sense of what's on file. One long form, no view of existing methods.
After, what changed
  • 1
    What you have, first. Existing methods are listed up front, with the primary one marked.
  • 2
    Adding is one step. A single clear path to add a bank or card, guarded against errors.
  • 3
    Bank vs card at a glance. Each method carries an icon you recognize.
Click here for the mobile product experience.Mobile payment flow + statements

Paying a bill on a phone

Pay Toll Bill, amount due
Step 1  Amount due up top, payment methods below, and a nudge to convert to E-ZPass and save.
Add Checking Account, filled
Step 2  Drilling into a method keeps one field per line, with a check diagram where people need it.
Statements on mobile
And  Statements carry the same rhythm, searchable, scannable, one tap into any period.
C4

Concept: one decision per screen

The mobile flow never asks for two things at once. Amount, then method, then the detail for that method. Each screen has a single obvious action.

Statements

The redesign moved statements from a document people had to interpret into an account history they could search, filter, and act on. The two sides below are different product models, not a restyling of the same screen.

Legacy printed statement Redesigned desktop Statements page BeforeAfter
Drag ↔
↔
Before, where it broke down
  • 1
    Dense printout. A "please read carefully" statement, tabular and unsearchable.
  • 2
    No way to find a period. You scanned a document instead of searching for one.
  • 3
    Print-first. Built to be mailed, not read on a screen.
After, what changed
  • 1
    Searchable by date. Pick a range, open the statement, download it in one tap.
  • 2
    Clear empty state. "No activity this period" instead of a confusing blank.
  • 3
    One pattern everywhere. The same rhythm as statements on mobile.
05 Evidence

The decisions in detail.

Start with the payment walkthrough, shared design system, and stakeholder decisions. Four additional examples cover prioritization, trust, legal constraints, and accessibility.

Open four additional examples of the design decisions and their supporting work.

04 / 07 Payment walkthrough

I measured the flow, not the presentation.

My measured result + product context
Open the decision logic
Need
I needed a result I could attribute to the flow, not a broad product number I could not defend.
Research
Fifteen real customers participated in the legacy-site study and shaped the priorities for the redesign.
Method
Run the same payment task from the same account state, with the same start and finish points, three times per flow.
Decision
Keep the customer research and the repeatable timing comparison explicit instead of presenting either as a broad product metric.
TaskMake a one-time payment from a bank account.
StartFrom the account dashboard with balance due visible. Timing began on clicking Make a Payment.
FinishPayment confirmation screen fully visible.
EnvironmentChrome, with the same account state and test data used across all six walkthroughs.
RunsThree timed walkthroughs per flow, legacy and redesign.
Participants15 real customers in the legacy-site research.
Timing scopeA repeatable task comparison using identical start and completion points.
45s → <12s
This controlled walkthrough measured task efficiency. The separate usability results above describe whether drivers could find payment information and understand the outcome.

Research included 15 real customers. Timing protocol: legacy roughly 45 seconds, redesign under 12 seconds, with identical start and completion points across all runs.

Open the full-size image
05 / 07 Design system

Shared core, controlled variation.

Approved redesign + Apollo documentation
Open the decision logic
Reality
New York and New Jersey needed the same interaction language, but their policies, codes, disclosure content, and program messaging were not interchangeable.
Risk
Two separate products would drift. One forced version would hide meaningful authority differences and eventually break trust with the agencies.
Decision
Standardize anatomy, states, behavior, accessibility, and actions. Keep policy and authority content explicit as controlled variants inside that shared structure.
Changed
The system stopped treating consistency as sameness. Teams could reuse the part customers needed to recognize while preserving the parts the authorities needed to own.
System receipt showing Apollo foundations, the shared bank account component, and controlled New York and New Jersey variants.
Apollo foundation, shared
TokensTypographySpacingInputsButtonsIcons
↓
Shared component

Payment method, bank account

Routing numberAccount numberPrimary account
↓

New York variant

  • NY-specific disclosure language
  • NY plan codes and rules
  • NY program messaging

New Jersey variant

  • NJ-specific disclosure language
  • NJ plan codes and rules
  • NJ program messaging
I built one component system and intentionally varied only where the authorities and their policies required it. Consistent behavior, local truth.

Shared component with authority-specific variants. The rows that differ are policy, not preference. See how the decision was implemented in the Apollo foundation.

Open the full-size image
06 / 07 Stakeholder decisions

Made decisions legible. The matrix, then the decision it produced.

Decision synthesis
Open the decision logic
Room
Legal, agency stakeholders, product, engineering, and design were not disagreeing because one group misunderstood the problem. They were protecting different things: policy fidelity, delivery effort, maintenance, accessibility, customer clarity, and future scale.
My move
I stopped presenting the design as a preferred screen and made the competing costs visible. The matrix gave each concern a place in the decision instead of asking one stakeholder to surrender to another.
Decision
Move forward with a shared component core and controlled authority variants.
Why it held
Customers gained a consistent interaction model. New York and New Jersey retained explicit control over the content and rules that were actually different. Engineering gained a maintainable foundation rather than another set of near-duplicate screens.
Changed
The conversation moved from whose version would win to which structure could carry all of the real constraints.
Option Separate NY and NJ experiences One universal experience Shared core with controlled variants
Policy fidelityHighLow, riskyHigh
User consistencyLowHighHigh
Engineering effortHighMediumMedium
Long-term maintenanceHighBrittleSustainable
AccessibilityHarderHard to maintainStronger
Scalability to new authoritiesLowLowHigh
Decision

Shared core with controlled variants. Consistency where it helps. Variation where it is required.

I framed the decision in the terms each group owned, which made the tradeoff clear and the path forward aligned.

The decision that changed

The question

How similar should the New York and New Jersey experiences be across toll and billing?

The disagreement

Different priorities across groups made agreement hard without clarity on what was actually at stake.

The artifact

A tradeoff matrix comparing three approaches against the criteria each group cared about.

The decision

Shared core with controlled variants, with authority-specific content handled as exceptions.

StakeholderWhat they cared aboutInitial stance
NYTA, legalAccurate policy, required language, approval riskLeaned separate
NJTA, legalAccurate policy, required language, approval riskLeaned separate
EngineeringReuse, fewer implementations, maintainable codeLeaned shared
ProductCoherent experience, scale, future flexibilityLeaned shared
Design, meClarity, trust, accessibility, consistency with real differencesProposed shared core plus variants
One interaction language
Shared components and states
Authority-specific content as variants
Less duplication, lower maintenance
We moved from duplicated authority-specific designs to one system with intentional exceptions. The decision balanced policy fidelity with a better customer experience and a more sustainable system.

Stakeholder tradeoff matrix and the decision it produced.

Open the full-size image
Explore the new design system.3 key exhibits + full documentation

Inside the Apollo foundation.

R5 establishes the product decision. This section shows the implementation evidence: the Apollo tokens, responsive rules, input states, buttons, and icons I designed and documented across web and mobile. Three exhibits provide the fast read. The full 11-page documentation is one click deeper.

Tokens and responsive foundations
Tokens and responsive foundationsThe breakpoints and scale the whole system designs against.
Form anatomy and states
Form anatomy and statesEvery input state specified once: enabled, focus, error, warning, disabled.
Buttons across platforms
ButtonsPrimary through link, with sizes, usage rules, and accessible contrast built in.
06 What changed

Clearer payments, fewer status questions.

68% → 92%
Drivers found their balance and chose a payment method without help.Baseline and follow-up usability testing
62% → 94%
Drivers correctly understood payment status.Baseline and follow-up usability testing
36 → 14
Payment-status support contacts per 1,000 payments.Post-launch operational data shared by the E-ZPass program team

Controlled efficiency comparison: The one-time bank-payment task took roughly 45 seconds in the legacy flow and under 12 seconds in the redesign. I ran three timed walkthroughs per flow with the same account state and test data, starting on clicking Make a Payment and ending when confirmation was fully visible. These were designer walkthroughs, separate from customer usability testing.

Legacy research: 15 customers studied on the legacy experience helped shape the redesign priorities. This is the discovery sample, not the sample size for the follow-up results.

Product context: The app the redesigned experience shipped in has 3M+ downloads. This describes the product's reach, not an outcome attributed to my work.

07 What’s next

Where I’d take it.

The redesign made individual payment states clearer. The next opportunity is to make the whole account experience more aware of uncertainty, especially when money moves, systems disagree, or a driver does not know what happens next.

The next problem is not another screen.

I would sequence the work by customer risk, learning value, and reversibility. Start with the questions that can prevent financial mistakes. Test the smallest credible intervention. Expand only when the evidence supports it.

RiskCould uncertainty cause a financial or account consequence?
LearningWill the test resolve an important product assumption?
ReversibilityCan we learn before committing the whole system?
01 / Highest priority

Make payment status a system, not a confirmation page.

A successful submission is one moment in a longer financial state change. The product should distinguish submitted, processing, posted, rejected, reversed, and action required, then explain what each state means for the balance and the ability to retry.

See the decision logic
First move
Map the payment state machine across the interface, transaction history, notifications, support tools, and agency systems. Find the moments where those surfaces can disagree.
Test
Give drivers realistic payment scenarios and ask whether the payment succeeded, whether the balance changed, whether retrying is safe, and what happens next.
Decision
Do not expand the solution until drivers can interpret the state and choose the safe next action without relying on support.
02 / Prevent the problem

Move from reactive billing to exception prevention.

Most account systems wait for customers to discover a problem. I would test an exception layer for unusual charges, failed replenishments, expiring payment methods, and other conditions before they become violations or support cases.

See the decision logic
First move
Choose one high-consequence exception and trace it from detection through resolution. Design timing, explanation, channel, and recovery as one experience.
Measure
Resolution without support, repeated failed actions, alert comprehension, opt-outs, and whether the intervention prevents the downstream problem.
Stop if
Messaging raises anxiety or produces alerts without a useful action. That is noise, not trust.
03 / Resolve the boundary

Create one mental model across New York and New Jersey.

A single technical account may not be politically, legally, or operationally feasible. The more important goal is a coherent customer model that makes shared behavior and authority-specific rules understandable.

See the decision logic
First move
Build a cross-authority service blueprint for identity, account ownership, policy variation, data movement, support responsibility, and failure recovery.
Test
Can drivers with activity across both states identify where to complete a task, understand which rules apply, and recover after starting in the wrong authority context?
Decision
Pursue deeper account unification only if it reduces customer confusion without recreating the same complexity in policy, operations, or implementation.
04 / Find structural failures

Use accessibility research to go beyond conformance.

Compliance testing verifies an interface against a standard. It does not reveal the full experience of paying a bill with assistive technology, managing cognitive load, or recovering from an error under financial pressure.

See the decision logic
First move
Test the complete payment journey with drivers who use screen readers, keyboard navigation, magnification, voice control, or other assistive strategies.
Include
Failure and recovery states, not only the happy path.
Look for
Places where the experience is technically operable but difficult to understand, sequence, verify, or recover from.

What I would change in my original process.

I validated the components and timed the payment task, but I would move rough end-to-end testing earlier. The component states were comparatively predictable. The greater risk lived between them: whether drivers understood the sequence, trusted the outcome, and knew how to recover.

The next version should not optimize for more capability. It should reduce the moments in which a driver must guess what the system has done.

Unshipped concept: designing trust controls for an E-ZPass AI assistant →

Nate Douglas / product designer / payments, billing, and complex workflows

← back to work