In-app feedback and store ratings — designing to a compliance line

Context

Two connected pieces of work: an always-on and event-triggered in-app feedback channel, and a system governing when the app asks a customer to rate it in the App Store or Play Store.

Institutions wanted better store ratings. The obvious way to get them is also the one that gets your app rejected.

The distinction that defined the project

There are two things that look similar and are not.

Satisfaction gating asks the customer how they feel, then routes the happy ones to the store prompt and the unhappy ones to a private feedback form. It works. It is also prohibited by both Apple and Google — the store review APIs may not be filtered by sentiment, because doing so manufactures a biased rating distribution.

Prompt gating controls when you ask, based on observable behaviour rather than declared sentiment. Asking after a customer has successfully completed something meaningful is permissible. Asking everyone, constantly, is merely bad.

Establishing that line early was the most valuable thing I did on this project. It was raised as an option, it is what several competitor apps visibly do, and it would have been built if nobody had said otherwise.

What I designed

An eligibility engine

Rather than a prompt tied to a single screen, the rating request runs off a set of conditions evaluated centrally:

• Positive-action triggers — the prompt becomes eligible only after a customer completes a task with a clear successful outcome, not on app open or on arrival at a screen
• Frequency governors — caps on how often a customer can be asked, respecting the operating system quotas underneath and the platform's own tolerance for interruption
• Suppression rules — states where asking is inappropriate regardless of eligibility

An always-on feedback channel

Separately from the rating prompt, a persistent route for customers to report a problem or make a suggestion at the moment it occurs — so that the feedback the institution actually needs is not dependent on someone being intercepted by a prompt.

Native prompt recreation

Recreated the native iOS and Android review prompts in the design files so that stakeholders reviewing flows could see exactly what the customer sees — including the parts neither we nor the institution control. That mattered: the system prompt cannot be restyled, cannot be tenant-branded, and does not confirm whether it was shown. Several conversations resolved themselves once that was visible rather than described.

Handoff

Produced wireframes, architecture diagrams and specification documentation for business analyst and developer handoff. Because the logic is conditional and mostly invisible, the specification had to be exhaustive about states that never render — eligible but suppressed, triggered but quota-exhausted, shown but undetectable.

Why this case study

Most of the design here is invisible. There is one small native dialog and a feedback form; everything else is rules about when to interrupt someone. It is a good illustration of senior design work being mostly about deciding what the system is allowed to do.