Cashback Browser Extension
product design
interaction design
product strategy
Overview
Recovered a stalled cashback browser extension redesign by diagnosing design, product, and engineering debt, aligning the team around a shippable activation loop, and delivering an implementation-ready design foundation.
Tools
Figma, Linear.app, FigJam, Miro, pen and paper, After Effects.
Duration
~6 months
Outcomes at a glance
Product direction
Defined the MVP around the core cashback loop: detect, inform, activate, confirm.
Separated release-critical functionality from secondary features to prevent scope drift.
Design delivery
Rebuilt the design foundation with full scenario coverage, defined states, edge cases, and inline rationale.
Delivered a structured Figma handoff that the engineering team could implement from directly. Implementation is active, initial tests are successful, release is currently in progress.
Organizational alignment
Co-authored an assessment with the lead engineer that made the inherited blockers visible and gave leadership a credible path forward.
Facilitated a backend capabilities assessment workshop and translated the findings into three architectural directions for leadership decision.
Context
The browser extension is the product surface that intercepts users at the moment of shopping decision. It detects a partner shop, signals cashback availability, and enables activation before checkout. This makes it a strategically important surface, not a peripheral utility.
For users, the extension sits in a fragile moment. They are already shopping and need to know whether cashback is available, whether it has been activated, and whether they can trust the feedback they receive. An unclear state risks hesitation, abandonment, or later confusion about missing cashback.
Challenge
When I took over the redesign, the project had been stalled for months.
The challenge was not primarily a visual one. It was a product, process, and architecture problem that needed shared diagnosis before it could be solved.
Four layers of inherited debt
To structure the solution, I translated the key insights into five focused design directions.
Design
Unstructured Figma file, missing states, no edge-case coverage, not implementation-ready
Product
No defined MVP, accumulated feature ambiguity, misaligned scope across design, engineering, leadership
Engineering
Performance issues, broken authentication flows, localization errors
Business
Commercial exposure & data governance concerns and unreliable cashback activation experience
Objective
My role was to create the conditions for the right solution:
assess what was actually broken, align the team on a coherent MVP, rebuild the design foundation, and hand off a structured file ready for implementation.
Role
I owned product design and acted as interim product owner for the browser extension scope.
This covered strategic assessment, stakeholder alignment, workshop planning and facilitation, MVP scoping, design ownership from foundation to handoff, and ongoing coordination with the engineering lead throughout.
Understand
Assessing the Inheritance
Purpose
Before any redesign work could continue, the team needed an honest, shared account of what was actually broken. Without that, the project would absorb the same unresolved ambiguity under a new name.
Approach
The first step was to produce a structured assessment rather than begin execution.
Working with the lead engineer, we co-authored an assessment document combining design and engineering perspectives.
The goal was to give leadership a credible explanation of the delay and a grounded argument for the path forward.
In parallel, I reviewed the inherited design file in detail.
Inherited design file
Components used to solve layout instead of structure
Overlapping and redundant component definitions
Missing or inconsistent state logic across similar elements
No clear ownership between components and interaction patterns
Lack of scalability due to non-modular system design
The inherited component set contained many overlapping variants without a clear state hierarchy or reusable component logic. Several elements appeared to solve isolated Figma layout needs rather than stable product patterns, making the file difficult to maintain, extend, or hand off reliably.
Navigation and bottom-bar elements mixed layout decisions, tab states, and icon variations across detached components. This created unclear ownership between component, pattern, and screen behavior, increasing ambiguity for both design maintenance and engineering implementation.
Key finding
The assessment helped reframe the blockers as systemic rather than individual capacity issues.
This shifted how the broader situation was understood at leadership level, and gave the project a foundation that informal escalation could not have created.
Decision
Produce a documented joint assessment before continuing any redesign work.
Trade-off
Delayed visible execution in exchange for a defensible, shared diagnosis that leadership and engineering could act on together.
Output
Co-authored assessment document and an annotated review of the inherited design file.
Define
Creating Shared Clarity
Purpose
A diagnosis without a shared path forward does not move a project.
This phase translated the assessment into aligned direction: a defined MVP scope, a trackable project structure, a roadmap leadership could evaluate, and a technical foundation the team agreed on.
Approach
I structured the work in an issue tracker, creating and tracking issues, maintaining a backlog, and managing the product roadmap.
This shifted the extension from an informal problem to a visible initiative with defined acceptance criteria.
A system design workshop with the lead engineer produced four artifacts that became the explicit foundation for the prototype and MVP:
A user story for the MVP
A user flow for the cashback activation path
A system flow connecting interface states to technical behavior
An initial implementation boundary for the prototype and MVP
These were the shared reference point before any implementation work continued, not documentation produced afterwards.
Regular alignment with the relevant product stakeholder kept expectations calibrated as the scope became clearer.
Backend workshop
As the engineering situation surfaced deeper architectural questions, I planned, facilitated, and analyzed a backend capabilities assessment workshop.
The goal was to generate structured evidence rather than informal opinion.
The output was synthesized into a peer-reviewed executive summary.
At the leadership meeting that followed, I presented three architectural directions: extending the current approach, a dual-track, and a full rebuild.
Option A: Extend current system
Continue development on the existing architecture and address issues incrementally.
Pros
Fastest path to release
Low upfront effort
Minimal disruption
Cons
Structural issues remain
Limited scalability
Continued implementation ambiguity
Risk
Reinforces existing architectural constraints.
Option B: Dual-track approach
Stabilize the current system while building a new architecture in parallel.
Pros
Reduces immediate risk
Allows gradual transition
Keeps delivery moving
Cons
Increased coordination complexity
Higher total effort
Risk of duplicated work
Risk
Extended transition period with overlapping systems.
Option C: Full rebuild
Redesign the architecture based on a clean system model and aligned product logic
Pros
Resolves structural issues at the root
Enables scalable, maintainable system
Clear foundation for future features
Cons
Higher upfront effort
Slower initial delivery
Requires strong alignment
Risk
Delayed release if scope is not tightly controlled.
The recommendation was the full rebuild, supported by the joint assessment with the lead engineer, but presented alongside the alternatives so leadership could decide on the merits.
Result
Decision
Frame the workshop and follow-up summary as evidence-generating artifacts rather than recommendation pitches.
Trade-off
Significant preparation time in exchange for a leadership conversation grounded in shared evidence rather than competing opinions.
Output
Backend capabilities assessment, executive summary, three architectural directions presented for decision and one decision.
Ideate
Scoping the MVP
Purpose
Scope ambiguity had stalled this project before.
The MVP decision needed to create a clear, defensible boundary between what was shippable and what was not, without discarding the broader feature set.
Approach
Working closely with the lead engineer, we aligned the MVP around the core cashback loop:
detect partner shop → inform user → activate cashback → confirm activation state
This was scope around a coherent, shippable unit, not reduction for its own sake.
Since activation feedback directly affects user confidence, confirmation was treated as part of the core loop rather than a secondary state. Secondary features were fully documented but explicitly placed outside the MVP boundary.
MVP Loop
Result
Decision
Scope the MVP around the complete cashback loop rather than a reduced feature list.
Trade-off
Fewer surface features at launch in exchange for a coherent, releasable unit with a defensible "shippable" criterion.
Output
Defined MVP boundary aligned across design, engineering, and product.
Design
Rebuilding the Design Foundation
Purpose
Turn the aligned scope and product logic into a structured, implementable design file that the engineering team could work from and leadership could evaluate.
Approach
After a structured assessment of the inherited components, the decision was to build a new design foundation rather than extend the existing one.
The inherited components were redundant, non-atomic, and not driven by defined user needs.
Building on top of them would have reproduced the same structural problems at greater cost.
Inherited design file
This resulted in a design that could not be implemented reliably, as key interaction logic remained implicit, missing or even broken.
Design Revision
The revised file is organized by feature and user state.
Four core browse scenarios are fully mapped, covering all combinations of partner and non-partner shops crossed with logged-in and logged-out users.
Each scenario includes defined states, edge cases, and browser progressions.
The primary activation flow: a logged-in user browsing a partner shop is informed about cashback, activates it inline, and receives immediate confirmation without leaving the browsing context.
When a user is not logged in, the system interrupts activation with authentication and restores the flow afterward.
For non-partner shops, the system detects the context and suggests relevant partner alternatives instead of offering activation.
User Flow
The user flow diagram covers all decision branches from arriving at a shop through cashback activation, with drop-off points annotated for future improvement.
The complete user flow maps every decision branch in the core cashback loop, including drop-off points marked for future iteration.
Trust: a design requirement
A user who encounters an unclear error or an opaque activation state has reason to doubt whether the extension is doing what it claims.
The error state work illustrates the depth of coverage absent from the legacy file.
It is built around an explicit user story:
The system was designed to communicate important states as clearly and persistently as possible.
Availability, activation status, login requirements, warnings, and errors were reflected not only inside the extension panel, but also directly through the browser extension icon, allowing users to recognize system status at a glance while browsing.
When a session expires during activation, the system interrupts the flow with a login prompt and restores the user to the previous state after authentication, allowing activation to continue without loss of context.
If cashback is already active but the user is unaware of it, the system surfaces the current state on interaction, preventing duplicate actions and resolving ambiguity through explicit confirmation
When activation cannot be confirmed instantly, the system enters a visible pending state with retry logic, ensuring feedback continuity until confirmation is reached.
If activation fails after retry attempts, the system transitions to a clear error state and provides a direct recovery action, allowing the user to re-initiate activation without confusion.
In case of a connection error, the system attempts automatic recovery before falling back to a blocking error state, guiding the user to restore functionality with animations when automatic resolution is not possible.
Beyond the core scenarios, the file includes dedicated sections for error states, favorites, notifications, referral, settings, deals, DOM injection, and general patterns. Inline annotations document design rationale and flag areas identified for future iteration.
Result
What was previously fragmented and undocumented is now structured into a complete and reviewed interaction system, covering detection, activation, confirmation, and failure handling.
This level of definition reduced ambiguity in implementation and enabled development to proceed without additional clarification or rework.
Decision
Build a new design foundation rather than extend the inherited file.
Trade-off
More upfront design effort in exchange for handoff readiness, lower implementation ambiguity, and a foundation that could carry future feature work.
Output
Structured, scenario-based Figma file with full state coverage, edge cases, and inline rationale.
Deliver
Handoff and Implementation
Purpose
Ensure the design work translates into a running product.
Approach
The handoff was delivered as a fully structured Figma file with scenario-level organization, annotated rationale, and complete state coverage.
The revised handoff introduced a more explicit standard for scenario coverage, state definition, and design rationale than had previously been established for this product surface.
The shift was from interpretation to implementation: the engineering team no longer had to infer missing states or reconstruct flows from disconnected mockups.
Implementation began shortly after handoff and the file was reported as a useful working basis by the engineers using it.
Current state
The redesign was not primarily a visual change. It was a shift in how the product behavior was specified, scoped, and made implementable.
Before
Mockups without complete state logic
Unclear MVP boundary
Feature ambiguity
Error states, edge cases missing or undefined
Engineering interpretation required
After
Scenario-based design file
Core cashback loop defined
Clear MVP scope
Progressive, trust-led error and edge cases handling
Annotated, implementation-ready handoff
Implementation is active. Initial tests are successful. Release is currently in progress.
Measuring what comes next
Because the release was still in implementation at the time of writing, I treated measurement as a readiness layer rather than a claimed result.
The redesign was delivered with a defined framework so outcomes can be benchmarked once the extension is live.
Learning
Diagnosis before execution
The most consequential early decision was not a design decision. It was to stop and produce a shared, documented assessment before any redesign work continued. Without it, the same ambiguity would have produced the same stall under a new name.
Scope as a design decision
Scoping the MVP around a coherent loop rather than a reduced feature list was a product call with design implications throughout. Every design choice could be tested against a clear criterion. That kind of focus is harder to maintain than it sounds when a project carries accumulated expectations.
Trust is structural, not cosmetic
In any product where users extend meaningful permission, the moments when things go wrong are not secondary to the core experience. They are part of it. Treating error and activation states as trust mechanisms rather than polish tasks changed the scope and depth of the design work in a way that a visual redesign framing would have missed.
What I carry forward
In lean, fast-moving environments, the designer often has to design the process before they can design the product.
That meant the assessment document, the workshops, the issue tracker structure, and the executive summary were not adjacent to the design work. They were the conditions that made it possible.
When a project has stalled, the instinct is to push faster. The more productive question is usually: what does the team need to share before they can move together?
Clarity is not a precondition to real work. It is the work.
More works
Let’s talk.
Prefer a quick conversation? We can align on expectations, product context, and whether there is a good fit.
15 minutes