Earning the right to ask for permissions before earning anything else.
Problem
The app's entire value depends on permissions it has no automatic right to — contacts, phone, call logs, SMS, notifications, display-over-other-apps. Without them, it can't function. Asking before earning trust kills adoption.
Context
Sardine already had a live product with its own design system. The job wasn't to design something new in isolation — it was to extend an existing system without breaking it, as an outside contributor.
Constraints
No formal limits were set on creative direction. But as a first international client relationship, where his judgment ended and Sardine's conventions began wasn't written anywhere — it had to be learned through the relationship itself.
My 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.
Asked for everything immediately. Users had no reason yet to say yes.
Outcome explained first. Status made visible and specific, screen by screen.
Fig. 1 — Permission flow, before and after internal QA.
Design Decisions
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 2015.
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.