At a glance
Presto is the transit fare card for the GTHA. I chose the Add Funds flow because it is the highest-frequency task on the site and the one users perform under real time pressure. Riders top up because they need to ride now, which means friction here has direct, tangible consequences.
The flow is mostly well structured and the majority of heuristics are respected. But five issues share a common pattern: the experience works for a first-time user on a linear path. It breaks down the moment a returning user tries to adjust, correct, or move faster.
Subject
prestocard.ca · Add Funds to a registered card
Method
Heuristic evaluation against Nielsen's 10 + severity rating.
Issues found
5 total. 4 rated major or catastrophic.
Top finding
No saved payment methods. Every reload forces full card re-entry on a registered account.
The right flow to evaluate.
The Add Funds flow is the most consequential task on prestocard.ca. Users don't visit to browse. They arrive with a specific goal: my card is low and I need to top up before my commute. That focus makes it the right scope for a heuristic evaluation: high traffic, real stakes, and narrow enough to produce actionable findings.
Why it's worth fixing
- Failure here doesn't just frustrate. Users who hit friction may abandon the flow and pay cash at a station kiosk instead, pushing them off the digital channel entirely.
- The flow spans login, account management, and payment entry, meaning a single task cuts across multiple categories of usability concern.
- Because this is a recurring task for the same users, small friction compounds in a way it wouldn't on a one-off interaction.
Approach.
I walked the Add Funds task end to end as a registered user on desktop, capturing each screen and logging violations against the 10 heuristics. Each issue was documented with a screenshot, the affected heuristic, a description of the impact on the user, and a severity rating using Nielsen's 0 to 4 scale.
Severity ratings
Nielsen's 10 heuristics.
Each finding maps to one or more of Jakob Nielsen's 10 usability heuristics. Highlighted rows were violated in this evaluation.
Mapping the task.
Five steps from sign-in to confirmation. I evaluated each step independently before consolidating findings.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Issues identified.
Each finding is documented with a screenshot, the violated heuristic, the impact on the user, and a concrete recommendation.
Observation
Every reload requires users to re-enter full payment details: card number, expiry, CVV, and billing address, even after dozens of prior transactions on the same registered account. PRESTO offers a "last loaded amount" shortcut, but that solves the wrong problem. Users don't struggle to remember the amount. They struggle with the data-entry burden.
Why it matters
A task that should take 30 seconds for a returning user takes over 3 minutes. For a service used multiple times a month by millions of GTHA commuters, that friction compounds fast and gives users a reason to abandon the digital channel entirely.
Recommendation
Allow users to save payment methods to their registered account and surface them at checkout with a single-tap selection. This is a standard pattern across payment flows and users already expect it here.
Observation
If a user adds $5 to the cart, then returns and adds $10, the cart silently updates to $10 rather than totaling $15. The interface uses the visual language of a shopping cart but breaks the behavior every e-commerce user expects: that carts accumulate. No feedback is shown when the prior amount is overwritten.
Why it matters
Users can load less than intended without realizing it, then arrive at a station short of fare. The cart looks and behaves exactly like every other cart they have used, so there is no signal that this one works differently.
Recommendation
Either make the cart accumulate as users expect, or drop the cart pattern and use a single confirmed amount. If it must replace, show an explicit warning before overwriting: "This will replace the $5 currently in your cart."
Observation
To change the load amount after it is in the cart, users must remove the item entirely and navigate back to the add-funds page to start over. Inline editing is a standard pattern across modern e-commerce, and its absence here creates unnecessary steps for a common adjustment.
Why it matters
Fixing a number requires restarting the flow. Taken with Issue 02, the cart actively resists users who change their mind, even though adjusting a transit reload amount is a completely expected behavior.
Recommendation
Add an editable input or stepper directly in the cart row. This is standard across every modern cart implementation and removes the need to navigate away to correct a single number.
Observation
The checkout page has no clear path back to the cart or any prior step. Users who want to verify their amount or switch cards have no in-page option. Their only recourse is the browser back button, which loses checkout context and forces a restart. This is a standard affordance in checkout flows that PRESTO omits entirely.
Why it matters
Users who catch a mistake at checkout are stuck. They can push through with the wrong settings or start over from scratch. Both outcomes are preventable with one link.
Recommendation
Add a "Back to cart" link at the top of the checkout page. It gives users an intentional, in-page way to step back without losing their place.
Observation
The "Add Funds" icon on the page differs from the "Add Funds" icon in the side navigation. More critically, the in-page icon is the same one used for "Autoload" in the navigation, meaning the same visual symbol represents two different functions depending on where it appears.
Why it matters
Icons should reduce cognitive load by making functions recognizable at a glance. Here they do the opposite: the same icon means different things in different places, forcing users to rely on memory rather than recognition. This points to a broader inconsistency in how the icon set is being managed across the product.
Recommendation
Audit and align the icon set across navigation and page content. Each icon should map to exactly one function. Adopt a shared icon library and treat it as a design system resource, not a per-page decision.
Where to fix first.
Issues plotted by severity and step in the flow. The checkout step carries the heaviest load, with a catastrophic issue and a major issue landing in the same column.
Redesigning the cart and checkout.
I redesigned the Cart and Checkout pages to address the four highest-priority issues: no saved payment methods, a cart that replaces instead of accumulates, no inline amount editing, and no way to step back from checkout.
The static amount display is replaced with an editable input directly in the cart row. Users can adjust their load amount without removing the item and navigating back. This resolves Issues 02 and 03 together: the cart no longer silently overwrites, and fixing a mistake costs one tap instead of a full restart.
A step indicator at the top of the page shows where users are in the flow: Cart, Checkout, Confirmation. Knowing how many steps remain reduces the uncertainty that drives mid-flow abandonment.
A "Back to cart" link at the top of checkout gives users an explicit, in-page way to step back and adjust before committing. They no longer have to use the browser back button as their only exit, which loses checkout context and forces a restart.
A checkbox at checkout lets users save their payment details to their registered account. On future visits, their card is pre-filled and ready to use. This directly addresses Issue 01, turning a 3-minute re-entry task back into a 30-second one.
What I learned.
Individual issues often point to a single root decision. Going in, I expected to document a list of separate problems. What I found was that Issues 01 through 04 were all symptoms of the same thing: a flow built for a first-time user on a linear path, not the returning commuter who uses it every week. Identifying that pattern, rather than treating each issue in isolation, made the recommendations sharper and gave the redesign a clear through line.
If I had more time. I would revisit the lower-priority findings that didn't make the cut but would still improve the experience over time. I would also extend the scope to other high-frequency tasks: setting up Autoload, registering a new card, and managing payment methods. Applying the same framework across those flows would give a much fuller picture of where the product stands as a whole.