Role & Contribution

The first version of onboarding asked for every permission directly, up front. Internal testing — before any public release — showed why this failed: users weren't refusing out of caution, they simply didn't understand what they'd get in return.

The redesign reordered the logic: explain the outcome first, then ask. After login, a per-category status view makes the cost of refusing concrete — a "not protected" label on the calls tab, for instance, tied directly to the specific permission still missing.

Beyond the core product, Dinesh designed Sardine's first public marketing site and used AI tools during early ideation to test more directions before bringing work into formal review.

Design Decisions & Iterations

One disagreement defined a phase of the project. An early dashboard included a circular meter showing an overall protection score — 0–40% not protected, 40–70% warning, 70–100% protected — sitting above an existing breakdown of stats per category (e.g. "Calls: 120 stopped"). Sardine's team felt the radial visualization didn't fit their minimal pattern. They asked for it to be cut entirely rather than restyled, keeping the category breakdown and moving it to the top.

"They didn't just want it redrawn. They wanted the idea of a single score gone — and kept the breakdown that was already working."

Challenges

Two distinct ones: building enough trust to ask for unusually invasive permissions before the product has proven anything, and learning — in real time, on a first international client relationship — where personal design authority ended and an existing system's conventions began.

Outcome

Live, in active development, with continued contribution across multiple feature cycles since 2025.

Reflection & Lessons Learned

The score concept didn't survive in this product — Sardine moved away from it entirely, not just its visual style. A similar single-score idea has since shown up in other Sardine products; whether that traces back to this work isn't something to claim, just something worth noticing.

Working as an outside designer inside someone else's live system means the job is sometimes to be told no — and the simplification that follows can be the more disciplined outcome, even when it isn't the first instinct.

Role & Contribution

The original direction called for four-directional navigation around a central player — content name and channel up top, controls below, with a separate set of navigation buttons on each of four sides. In practice it failed on two fronts: it was hard for engineering to make feel smooth, and slow for users — reaching a simple action like opening the EPG took several sequential steps.

Dinesh raised the constraint directly and proposed an alternative: a single horizontal row of icon CTAs in the bottom-right, next to play/pause, navigable left-to-right with one consistent focus state. Fewer steps, one model instead of four, and feasible to build well.

Design Decisions — Simplifying to five buttons

The core decision of this project was reducing four separate navigation zones to one. With only five physical buttons available, every additional navigation zone multiplies the number of focus jumps needed to reach an action — the four-way model meant a user pressing in any direction first had to discover which of four button sets was now active before doing anything useful.

Collapsing this to a single row meant one mental model: left and right always move along the same row, OK always confirms the current icon. That consistency is what made the interaction learnable in a few seconds on a remote with no labels beyond directional arrows.

Iterations

Dinesh personally QA'd builds on real Kogan TVs at every checkpoint alongside the dev team, rather than relying on design-file approval. The 4-way navigation was the one interaction that changed most visibly as a result — replaced once it was clear the issue wasn't taste, it was step count and feasibility.

Challenges

Changing a CEO-originated direction required evidence, not opinion — engineering difficulty and step count, demonstrated on real hardware. Validating every interaction repeatedly, rather than assuming a design file translates directly to a TV remote in someone's hand.

Outcome

Shipped and live on Kogan Google TV devices in Australia, publicly launched as a free ad-supported platform in November 2025. Design and frontend involvement ended at launch; the backend team now manages ongoing maintenance.

Reflection & Lessons Learned

The strongest decision here wasn't adding something — it was simplifying a requested four-direction system down to one, backed by evidence rather than instinct. On hardware-constrained platforms, "this works in the design file" and "this works in someone's hand on a real TV" are different claims.

Design Decisions & Challenges

Ownership here looked different from Sardine or Kogan TV+: end-to-end direction early on, shifting toward a more collaborative process as the team and partner network grew — more opinions in the room, not a single point of decision-making.

Outcome

Live, serving 2M+ monthly users across a growing partner network. Now maintained on an as-needed basis — typically new assets for partner-specific plan benefits, rather than active new design work.

Reflection & Lessons Learned

A white-label product's hardest constraint isn't visual consistency — it's deciding which parts of the experience are actually load-bearing (the scoring system, the tagging model) versus which parts each partner should be free to make their own.