Case study / tolling & transit / web, mobile & responsive
E-ZPass · New York & New Jersey
Rebuilding how millions of drivers pay a toll.
At Conduent, I owned product design across tolling and transit for web, native mobile, and responsive experiences. For E-ZPass New York and New Jersey, I led the complete cross-platform product: dashboards, new accounts, signup and login, plans, tolling, billing, statements, correspondence, payments and pay types, business and retailer tools, FAQs, support, and net-new features. I also extended that systems work into AI-assisted service concepts for regulated, high-stakes workflows.
The redesigned E-ZPass account experience, 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.
Measurement
Measured impact without borrowing it
Fifteen real customers participated in the legacy-site research. I also timed the same payment task on both flows with identical start and completion points: roughly 45 seconds on the legacy experience and under 12 on the redesign. Adoption and download figures stay where they belong, as product context rather than personal impact.
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.
The front door
Drag to compare
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
Reconstructed from the legacy patterns
The legacy source files were unavailable. These high-fidelity reconstructions combine the patterns visible in the live legacy product with the account surfaces I inherited, showing the structural problem and the responsive approach I established.
Before: the desktop information architecture was compressed for a phone, preserving its tables, competing alerts, tiny actions, and internal system structure.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
High-fidelity legacy reconstruction
The source files no longer existed, so I reconstructed the connected journey from the live legacy patterns and the screens available during the work. The point is not that the old product had five pages. It is that each page exposed a different piece of the system and left the customer to assemble the meaning.
Legacy reconstructionSystem structure exposed to the customerRedesigned 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
Drag to compare
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.
Adding a payment method
Drag to compare
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 more shipped product evidence.Mobile payment flow + statements
Paying a bill on a phone
The flow, one step to the next
Step 1 Amount due up top, payment methods below, and a nudge to convert to E-ZPass and save.
Step 2 Drilling into a method keeps one field per line, with a check diagram where people need it.
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
From a static document to searchable account history
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.
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
Three receipts carry the argument.
Measurement, system strategy, and stakeholder alignment form the fast read. Four supporting receipts remain available for the complete evidence trail. The measured task result is mine. Product-context figures are labeled separately.
Three primary receipts make up the fast read. Open the supporting set here to see the four additional decisions and the complete evidence trail.
01 / 07 Supporting evidence / Prioritization
Proves: Started where value breaks.
Verified project dataOpen the decision logic
Signal
The May account analytics were a pre-arrival baseline. When I joined in June, Payments and Statements already carried the clearest combination of drop-off and support burden.
Question
Do I start with the screens that look oldest, or the tasks where confusion is already creating consequences for customers and support teams?
Decision
Start with Payments and Statements. They were not the easiest surfaces to modernize, but they were the places where clearer design could remove the most friction first.
Changed
The data changed the sequence of the redesign instead of being used later to justify an order I had already chosen.
Account experience overview by journey area
Journey area
Task completion rate
Drop-off
Support volume (per 1K users)
Priority
Signup
79%
21%
12
3
Payments
42%
58%
87
1
Statements
48%
52%
64
2
Plans and tags
66%
34%
31
4
Profile and settings
74%
26%
18
5
Payments and statements had the highest drop-off and the highest support volume across the account experience. I focused first on the two areas causing the most friction and operational cost, because improving them would help the most drivers the fastest.
Pre-arrival account analytics baseline, May 1 to May 31, 2023. I used this existing baseline after joining in June to set the first redesign priorities. Support volume normalized per 1,000 users.
Proves: The problem underneath the problem was trust.
Case-study artifact + original production evidenceOpen the decision logic
Signal
Backlog feedback kept circling the moment after submission. People could find the payment action, but they still had to guess whether it worked, what changed, and whether trying again would make things worse.
Wrong target
A cleaner form would make the same uncertainty look better without resolving it.
Decision
Make status, balance change, next steps, and recovery the center of the flow. Confirmation could not be treated as the last decorative screen in the sequence.
Result
The work shifted from improving button visibility to building confidence after money moved.
01 Find the action
Pay balance Current balance $48.75 [ Make a payment ]
The driver can find where to pay.
Findability was not the failure. The entry point worked.
02 Enter payment
Payment details Bank account ••••••7890 Amount $48.75 [ Continue ]
They complete the form and submit.
The mechanics of the transaction were survivable.
03 Unclear outcome
Thank you Your payment has been submitted. We will update your balance shortly. Return to account
The confirmation leaves too much uncertainty.
Submitted is not the same as paid, and the screen never closes the gap.
Questions the flow left unanswered
Did the payment go through?
What changed?
What do I owe now?
Can I safely try again?
What happens if it fails?
Drivers could start the flow, but they were left unsure about status, outcome, and next steps. The deeper problem was clarity and confidence after the action, not findability.
Journey failure pattern in the legacy payment flow. Reconstructed from contemporaneous backlog feedback and the available legacy interface. Not an original end-to-end production capture.
The bank authorization language had to remain legally intact.
Decision
Keep the meaning, change the experience around it: plain-language orientation first, structured full terms second, and consent placed beside the content it authorizes.
Why
The legal constraint was real. The wall of text was a design choice.
What was hard
A dense paragraph of legal language
Buried at the bottom of the form
Hard to understand what you were agreeing to
The action was not clearly connected to the authorization
What changed
A heading that names the purpose of the section
A plain-language summary of what is being authorized
The same legal meaning, chunked into short readable sections, with the full terms still available
The checkbox placed directly with the language it relates to, and the primary action visibly tied to it
The legal meaning is unchanged. What changed is hierarchy, sequence, and where consent sits relative to the thing being consented to.
Auto-replenishment authorization, legacy experience beside the approved redesign.
Proves: I measured the flow, not the presentation.
My measured result + product contextOpen 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
Using identical start and completion points let me measure the flow rather than the presentation. The redesigned task required substantially less time to complete.
Research included 15 real customers. Timing protocol: legacy roughly 45 seconds, redesign under 12 seconds, with identical start and completion points across all runs.
Approved redesign + Apollo documentationOpen 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.
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.
Proves: Made decisions legible. The matrix, then the decision it produced.
Decision synthesisOpen 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 fidelity
High
Low, risky
High
User consistency
Low
High
High
Engineering effort
High
Medium
Medium
Long-term maintenance
High
Brittle
Sustainable
Accessibility
Harder
Hard to maintain
Stronger
Scalability to new authorities
Low
Low
High
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.
Stakeholder
What they cared about
Initial stance
NYTA, legal
Accurate policy, required language, approval risk
Leaned separate
NJTA, legal
Accurate policy, required language, approval risk
Leaned separate
Engineering
Reuse, fewer implementations, maintainable code
Leaned shared
Product
Coherent experience, scale, future flexibility
Leaned shared
Design, me
Clarity, trust, accessibility, consistency with real differences
Proposed 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.
Proves: Built into the component, not bolted on per screen.
Apollo component specificationOpen the decision logic
Problem
Fixing accessibility screen by screen would repeat the same work and leave the next implementation free to regress.
Decision
Put labeling, focus, error behavior, contrast, target size, and keyboard expectations into the component specification.
Effect
Accessibility repeated wherever the component was used.
Bank account input
Default
Focus
Error
Disabled
Label
Routing number
Routing number
Routing number
Routing number
Value
123456789
123456789
12345
123456789
Helper text
9 digits
9 digits
9 digits
9 digits
Error message
None
None
Enter a 9-digit number
None
Account number helper
4 to 17 digits
4 to 17 digits
Enter a valid account number
4 to 17 digits
Focus style
None
2px ring, 2px offset
2px ring on error color
Not focusable
Target size
44 × 44 px min
44 × 44 px min
44 × 44 px min
44 × 44 px min
Label programmatically associated with the input.for / id
Error text associated with the field it describes.aria-describedby
Contrast at AA 4.5:1 for text, AAA 7:1 or better for important text.AA / AAA
Focus, labeling, errors, contrast, and target size live in the component, so accessibility repeats with the system instead of being rebuilt on a single screen at a time.
Bank account input, approved Apollo component specification.
Open the full-size imageExplore the Apollo implementation evidence.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 foundationsThe breakpoints and scale the whole system designs against.Form anatomy and statesEvery input state specified once: enabled, focus, error, warning, disabled.ButtonsPrimary through link, with sizes, usage rules, and accessible contrast built in.
BreakpointsBreakpoints from xs mobile to lg desktop, the four screens the system designs for.
Color, principlesOne core action color across every product, everything else used sparingly.
Color, anatomyThe full palette, secondary and alert tokens, the layering model, and light and dark themes.
Type, scaleWeights, a scale built on one equation, and the full set of heading styles.
Type, fluidHeading and display styles that resize across breakpoints.
ButtonsPrimary, secondary, danger, tertiary, and link, with sizes and usage rules.
Forms, specThe structure and measurements behind every text input.
Forms, statesEvery input state, enabled, focus, error, warning, and disabled.
Icons, usageSizing on 16 to 32px artboards, color, and alignment.
Icons, darkThe app, web, and line icon library in dark mode.
Icons, lightThe same library in light mode.
06 What changed
The numbers.
45s→<12s
Core payment task, timed with identical start and completion points.My measured impact
n=15
Customers studied on the legacy site. I used the findings to prioritize and adjust the redesign.My research scope
3M+
Downloads of the app the redesigned experience shipped in.Product context, not personal impact
07 The system behind the assistant
I designed the controls behind trustworthy AI.
Months before these questions dominated the AI conversation, I was addressing them in NJ TRANSIT’s chatbot, payment, and multi-authority work. The interface was only the visible layer.
Reliability depends on the system around the model: context, permissions, memory, evaluation, and recovery. The harness, tools, supplied context, permissions, memory strategy, evaluation criteria, and recovery behavior determine whether an AI agent actually works reliably.
These artifacts extend that interaction work into a fuller system proposal using the same constraints and service problems.
Why this matters to the business
A confident error in this environment is not simply bad copy. It can cause a duplicate payment, missed deadline, incorrect account change, privacy exposure, legal escalation, avoidable support contact, and lost trust. The business case is therefore not “add a chatbot.” It is resolve more routine work without increasing financial or operational risk.
220M+support conversations analyzed across 18 industries in Comm100’s 2026 benchmark
+8.4%generation helpfulness in a production Agent-in-the-Loop pilot shaped by human feedback
13.3% to 38.3%in an OpenAI-reported ARC-AGI-3 experiment using retained reasoning and context compaction, with six times fewer output tokens
Read the strategic framingThe principle and three capabilities behind the artifact setOpen overview
My principle
I use AI to expand the solution space, then apply systems thinking, accessibility, and domain constraints to decide what ships.
Explore the AI system7 artifacts covering context, permissions, memory, interface states, review, evaluation, and orchestrationOpen collection
01
Context packThe inputs, rules, risks, and release criteria guiding every response.
View artifact
Artifact 01 / Context pack
Give the assistant the right context before asking it to help.
The quality of an AI experience depends on more than the model. I packaged the existing E‑ZPass research, payment rules, authority differences, brand intent, and accessibility requirements into reusable context that could guide every response. This makes the design system usable by the AI, not just visible to the team.
Why it matters Without shared context, the chatbot may sound capable while giving advice that ignores account status, jurisdiction, authorization, or the financial consequence of being wrong.
Confirm the issuing authority before applying policy.
Match authenticated account context before discussing account-specific details.
If authority or identity is uncertain, gather only non-sensitive information and escalate.
02 / Response contract
State what is known and identify the source.
Separate payment status from violation status.
Disclose what remains uncertain.
Offer one safe next action; never imply the issue is resolved.
03 / Accessibility requirements
Plain language with short, descriptive headings.
No color-only status or instruction.
Structured summary for screen-reader review.
Keyboard-operable confirmation and handoff controls.
04 / Prohibited behavior
Invent a balance, date, policy, or account outcome.
Promise violation removal or offer legal conclusions.
Change an account, dispute, or payment without permission.
Recommend another payment while the first remains unresolved.
Required response anatomy
StatusWhat the current source confirms
MeaningWhat that state does and does not mean
UncertaintyWhat cannot yet be verified
Next actionThe safest available step
Release criteria
The driver can explain what happened, distinguish known from unknown, avoid duplicate payment, and choose the next action without guessing.
4 of 4 criteria Pending sign-off
02
Action boundariesWhere the assistant may answer, gather, confirm, escalate, or stop.
View artifact
Artifact 02 / Action boundaries
Instructions are guidance. Permissions are the control.
I separated conversational ability from operational authority. The assistant can explain and gather information, but higher-consequence actions pass through confirmation, identity, and human-review gates.
Why it matters “Do not do this” is not a dependable safeguard. Financial workflows need least-privilege access, visible confirmation, action logs, reversible operations, mandatory human escalation, and a technically enforced stopping point.
Memory and contextWhat is retained, refreshed, compacted, session-only, or discarded.
View artifact
Artifact 03 / Memory model
Remember enough to help, not enough to create a new risk.
I defined memory by purpose and duration instead of treating the entire conversation as reusable history. The assistant compacts a long interaction into the minimum verified context needed for continuity, refreshes information that may have changed, and gives the customer control over anything retained beyond the session.
Why it matters Memory strategy and context compaction are product architecture, not backend tuning. Retained context can improve continuity, but unnecessary memory can expose account details, preserve a wrong assumption, or influence a later answer after the situation has changed.
Chatbot statesFive production states for certainty, consent, recovery, and handoff.
View states
Artifact 04 / Chatbot states
Show uncertainty before it becomes a financial mistake.
I applied the system rules across five production-ready states. The assistant can explain verified information, disclose uncertainty, request confirmation before an account change, recover safely from a system error, and transfer a complete case to a specialist.
Why it matters A confident but incorrect answer could cause a duplicate payment or missed deadline. The experience must remain useful when information is incomplete, an action needs consent, a system fails, or a person needs to take over.
01 / Verified response02 / Uncertain response03 / Confirmation required04 / Error and recovery05 / Human handoff
05
Human reviewThe failed AI proposal, designer intervention, and approved correction.
View review
Artifact 05 / Human-in-the-loop review
Use generation to explore, then review against the system.
I treated AI output as a proposal, not a decision. The process is visible from beginning to end: AI proposal, designer review, business-rule failure, designer correction, and final accessible state.
Why it matters Speed is useful only when review can expose the failure. Showing the correction demonstrates judgment: the designer owns what ships, including the states the AI did not anticipate.
01 / AI draft blocked by business rules02 / Designer review and approved correction
06
Evaluation scorecardScenarios, acceptance criteria, results, blockers, and ownership.
View scorecard
Artifact 06 / Evaluation
Define “good” before measuring the assistant.
I converted the experience goals into measurable acceptance criteria and a visible verification chain: generated response → automated checks → expert review → disclosed uncertainty → final approval. A response does not pass because it sounds natural; it passes only when the facts, permissions, accessibility, uncertainty, and escalation behavior all hold together.
Why it matters Generation makes output faster. Verification determines whether that output is dependable enough for a high-consequence customer workflow. Measurable acceptance criteria, staged review, and named ownership make confident errors detectable before they reach a customer.
End-to-end systemThe complete path through context, permissions, action, failure, and escalation.
View system
Artifact 07 / End-to-end system
The interface is one part of the product.
The complete design makes the system behind the experience visible: context supplied, actions allowed, memory retained, evaluations used, failure behavior, and human ownership. Each layer answers a different trust question.
The chatbot earns trust when the surrounding system makes safe behavior easier than unsafe behavior, while keeping a person accountable for the exceptions.
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.
