Imagine someone installs a task management app to make sure nothing important slips through the cracks. Before long, every comment, status change, message and reminder becomes another interruption. Frustrated, they decide to switch off notifications altogether.
That might solve the immediate problem of distraction. But what happens when an important update, one that genuinely requires their attention, gets lost along with everything else?
This creates a familiar product design dilemma: How do we reduce unnecessary interruptions without preventing users from receiving information that matters?
That is the challenge behind the seventh question in this series of 1,000 Product Manager interview questions.
The Interview Question and What It Tests
Question: Design a notification control experience for a user who is tired of receiving too many notifications.
The source material classifies this as a difficult product sense and design question.
The interviewer is not simply looking for a list of notification settings. They want to understand whether the candidate can:
- Identify the underlying problem rather than immediately responding to the apparent request.
- Select a meaningful user segment and investigate its needs.
- Balance user convenience, the value of timely information and business objectives.
- Recommend a solution that can be tested with limited cost and risk.
- Define success measures and explain when the initial decision should be reconsidered.
What distinguishes a strong answer is not the number of features proposed, but the reasoning behind the decision.
First, Understand What Is Actually Frustrating the User
When someone says, "This app sends too many notifications", the problem is not necessarily the number of notifications.
Several different issues might be involved.
Excessive volume: The application generates a separate notification for every minor event.
Irrelevance: People receive updates that have little connection to their responsibilities or interests.
Poor timing: A notification may be useful, but it arrives during a meeting, a period of concentration or personal time.
Weak prioritisation: A promotional message and an urgent operational alert are presented with similar prominence.
Lack of control: Users cannot stop unwanted notifications without disabling everything, including information they need.
These problems require different interventions.
For example, if the underlying issue is irrelevant content, introducing a Do Not Disturb option may hide the symptoms without addressing the cause. If delivery timing is the problem, simply reducing volume may achieve very little.
Before designing anything, we need to establish what users actually want to change.
Which Users Should We Prioritise?
A common mistake in product design interviews is trying to solve the problem for everyone simultaneously.
A better starting point is a segment where the problem is particularly severe, frequent and observable.
For our hypothetical task management application, we could focus on highly active users who collaborate across several projects and receive frequent notifications about comments, assignments and deadlines.
This does not mean other users are unimportant. It simply gives us a concrete situation in which to investigate the problem.
There are four questions worth exploring.
How severe is the problem? Are people mildly irritated, or have they disabled notifications completely?
How frequently does it occur? Is the problem constant, or concentrated around particular activities and working hours?
What workarounds already exist? Do users mute their devices, rely on operating-system settings or simply ignore notifications?
Which notifications are genuinely valuable? Do all alerts prompt meaningful action, or do only particular categories matter?
Answering these questions requires a combination of user interviews, observation and product analytics.
Behavioural data can reveal which notification types are sent, how frequently they appear and what happens afterwards. However, those data alone cannot reliably explain the user's motivation.
Someone might not open a notification because the information displayed in the notification itself was sufficient, rather than because it was irrelevant.
This is why qualitative research matters.
What Solutions Could We Consider?
There are three credible approaches.
Option 1: Allow Users to Disable All Notifications
The simplest approach is a single switch that turns every notification on or off.
Its advantage is immediate control with almost no complexity.
The disadvantage is that it treats important information and unnecessary interruptions identically.
Users should retain this option, but it is not an adequate solution to notification fatigue on its own.
Option 2: Provide Highly Granular Notification Settings
We could introduce individual controls for every event, message type, project and activity.
This offers considerable flexibility, but it also increases complexity.
Someone already frustrated by notifications may have little interest in navigating dozens of switches to regain control.
Advanced settings can be valuable for experienced users, but they should not make the default experience unnecessarily demanding.
Option 3: Combine Sensible Prioritisation with Simple Controls
This would be my preferred starting point.
Rather than treating every notification equally, the product groups notifications according to their value, urgency and expected user action.
The user receives a small number of understandable options for controlling delivery.
For example:
Action-required notifications: Task assignments or changes that require a timely decision or response.
Routine updates: Comments, status changes and other information that can usually wait.
Recommendations and promotions: New feature announcements, offers and other optional communications that users should explicitly choose to receive.
These categories are illustrative, not a universal classification. Research must establish what genuinely counts as urgent in the product's context.
The benefit is that we can reduce interruption without eliminating useful communication.
The trade-off is the additional complexity of classifying events correctly, including the risk of incorrectly assigning urgency.
What Should the Experience Actually Look Like?
Instead of designing a complicated preferences screen, I would organise the experience around a few understandable behaviours.
1. Establish Sensible Defaults
Users should not have to configure numerous settings before they can enjoy a relatively calm experience.
Low-priority events could be delivered quietly, while related updates could be grouped rather than generating repeated interruptions.
Promotional notifications should require appropriate user consent rather than being enabled automatically.
2. Let Users Control Notifications in Context
When a notification becomes annoying, users should be able to change how similar notifications behave in future.
Possible actions include:
- Mute similar notifications.
- Pause notifications from a particular project.
- Receive a summary instead of separate alerts.
- Open the settings for that notification category.
Changes should be easy to understand, straightforward to reverse and available without unnecessary steps.
3. Group Non-Urgent Notifications
Instead of sending several individual messages about changes to the same project, the application could consolidate them into a summary.
Users should ideally be able to choose when they receive these summaries.
However, reducing notification volume must not become an excuse for delaying information that genuinely requires immediate action.
4. Respect Time and Concentration
Users should be able to define quiet hours or periods when interruptions are undesirable.
Where an operating system already provides features such as Focus and scheduled notification delivery, the product should respect those preferences rather than attempting to bypass them.
Apple's official notification guidance supports this principle, recommending timely, valuable information, avoiding unnecessary repetition and accurately representing urgency.
5. Explain Why a Notification Was Sent
People should understand why they are receiving an alert.
For example, "You're responsible for this task" provides more useful context than a vague notification indicating that something has changed.
Sensitive information must also be handled carefully, particularly when notifications may appear on a locked device.
An important technical consideration is that in-app preferences do not replace operating-system controls.
Android notification channels allow users to manage notification categories through system settings. On Android 13 and later, non-exempt notifications also require runtime permission. Apple platforms similarly require applications to respect notification permissions and system-level delivery preferences.
Hypothetical Scenario: Redesigning a Project Management App
Consider a fictional software company operating a collaborative task management platform.
Its support team receives complaints about excessive notifications from active users. Product analytics also indicate that some users have disabled notifications entirely.
These observations suggest a problem, but do not establish its underlying cause.
The Product Manager and UX designer investigate notification behaviour and interview affected users.
Suppose the research indicates that users want to receive alerts about important assignments and approaching deadlines, but do not need an interruption every time someone posts a routine comment or makes a minor status change.
The team compares three approaches: reducing notification volume across the board, building a comprehensive preferences interface, and introducing a limited set of categories with better defaults.
They choose the third option for an initial experiment.
The proposed experience includes:
- Consolidating consecutive comments relating to the same task.
- Delivering summaries of non-urgent changes at user-selected times.
- Preserving timely notifications for action-required events.
- Providing quick controls to mute a category or project.
- Offering simple default preferences with access to more advanced settings.
Engineers handle notification delivery, platform permissions and notification channels. The designer tests whether the categories and controls make sense to users. Support monitors confusion and reports of missed important updates.
The Product Manager makes the trade-offs between user value, business outcomes, implementation effort and risk.
If the organisation uses Scrum, the Product Owner is accountable for maximising product value and effective Product Backlog management under the Scrum Guide. Where a Project Manager is involved, their responsibilities may include coordinating delivery against agreed time and resource constraints. The division of these responsibilities varies between organisations.
The proposed changes are tested with a limited group of eligible users, while a comparison group retains the existing experience.
This is a hypothetical experiment; no actual performance results are being claimed.
How Would We Measure Success?
A reduction in notification volume does not automatically indicate success.
The application might send far fewer notifications while simultaneously causing users to miss important work.
We therefore need three different kinds of measures.
Outcome metric: The proportion of eligible high-priority events that users address appropriately within a time window relevant to the event's urgency. The denominator includes all eligible important events, not just notifications that were opened.
Diagnostic metric: The number of preventable interruptions per active user per week, alongside adoption of muting, summaries and notification preferences.
Guardrail metrics: Missed or delayed responses to important events, complete notification opt-outs, user complaints, and privacy or permission-related issues.
The observation period should be defined before the experiment and reflect how frequently important events occur.
If critical events are relatively uncommon, a short experiment may not provide sufficient evidence to support a confident conclusion.
Results should also be reviewed across user segments and operating systems.
Notification open rate is not an appropriate primary success metric.
A lower open rate might be positive if users can understand the information directly from notifications without opening the application.
Conversely, if important notifications no longer lead to appropriate action, the design needs reconsideration.
How Would I Answer This in an Interview?
Example spoken response:
"I'd start by understanding what the user is actually frustrated by. Is it the volume of notifications, their relevance, when they arrive, or the lack of control?
"Then I'd choose a specific user segment. For example, people who work across several projects in a task management app and receive frequent updates throughout the day.
"I'd use behavioural data and interviews to understand which notifications genuinely help users take action and which ones create unnecessary interruptions.
"For the first solution, rather than building a complicated preferences page, I'd group notifications into a few meaningful categories. I'd keep important alerts timely, consolidate lower-priority updates and give users quick ways to mute or adjust what they receive.
"I'd then test the experience with a limited group. I wouldn't measure success purely by counting fewer notifications. I'd want to see whether unnecessary interruptions decrease without reducing users' ability to respond to important events.
"If users remain frustrated or start missing relevant alerts, I'd revisit the categories and defaults."
This is a stronger answer because it demonstrates a clear decision, explains why that decision makes sense, and identifies what evidence would lead to a different approach.
Two Important Interview Follow-Up Questions
1. What Would You Do If You Had Only Two Weeks?
I would not attempt to build a comprehensive notification management system.
First, I would examine existing data by notification type, frequency, permission status and user segment. In parallel, I would interview a small number of highly active or dissatisfied users to identify the main source of frustration.
I would then select a small, reversible intervention.
For example, we might consolidate repetitive notifications within one category or add a quick mute control for that category.
Before releasing the change, I would define success criteria and acceptable guardrail thresholds.
Two weeks might be sufficient for initial diagnosis and usability testing, but not necessarily enough to establish long-term impact. I would make that limitation explicit rather than overstating what the results prove.
2. What Evidence Would Make You Reject Your Proposed Solution?
If notification summaries caused users to respond more slowly to important events, I would reconsider the classification or delivery timing.
Similarly, if users struggled to understand the simplified settings, repeatedly reversed their preferences or continued disabling all notifications, the assumption that our design was sufficiently simple would be questionable.
Research might also reveal that the primary issue is not notification volume at all, but poor relevance.
In that case, improving notification targeting and event-generation rules would probably be a better investment than introducing additional controls.
Good product judgement means defending a decision through evidence without becoming attached to the solution itself.
What Would Make an Interview Answer Weak?
"I'd add a switch to turn off notifications."
That provides control, but does not solve the distinction between useful information and unwanted interruptions.
"I'd make every notification type configurable."
Without understanding user needs, this simply transfers the design complexity to the user.
"I'd use AI to decide which alerts matter."
Without reliable data, a clear decision mechanism, acceptable error rates and user correction controls, this is a technological promise rather than a credible product recommendation.
"I'd optimise notification click-through rates."
Higher notification engagement is not necessarily better user experience. It may even conflict with the objective of reducing interruptions.
"This feature would benefit everyone."
A user waiting for a time-critical operational alert has different needs from someone who only wants an occasional activity summary.
All these weak answers share the same underlying problem: they select a solution before adequately establishing the user need.
Conclusion
For users overwhelmed by notifications, the best starting point is neither a comprehensive settings interface nor switching everything off. We first need to identify which notifications create genuine value, which cause unnecessary disruption and how user context changes what counts as important.
My recommendation is a combination of user-centred prioritisation, sensible defaults, consolidated low-priority updates, and simple, reversible controls. It should be tested against actual user outcomes and reconsidered if it delays important responses or increases confusion.
Better product design does not always mean adding more features. Sometimes the most valuable design decision is knowing when the product should leave the user alone.
Sources
- Apple Human Interface Guidelines — Notifications
- Apple Human Interface Guidelines — Managing Notifications
- Android Developers — Create and Manage Notification Channels
- Android Developers — Notification Runtime Permission
- Reforge — Product Manager Interview Questions
The fifth source provides general interview design and evaluation context.
Question 7 is presented as a contextual product design exercise in the series' reference material, not as a verified official interview question from a particular company.
