Before Building Proactive AI Messages, Listen for “No”

Start with the question behind the feature

A proposal to make an AI “more proactive” can hide several different ideas: a reminder, a suggestion, a check-in, or a message tied to a routine. Those are different experiences. Before recruiting, write down the specific proposed behavior in plain language: what might prompt a message, what it could say, and where the person would see it. This gives participants something concrete to react to without pretending the feature already exists.

Keep the research question open. For example: “In what situations, if any, would you want this kind of message, and when would you prefer not to receive it?” Avoid asking only whether someone likes the idea or how often they want messages. A broad positive answer can conceal important boundaries: someone may welcome an occasional note while cooking, for instance, and want quiet during work, travel, or time with other people. These are prompts for discovery, not claims about what users will say.

Recruit people who are actual or likely users of the experience you are designing, and explain the invitation before they agree to take part. GOV.UK user-research guidance recommends making the purpose and activity clear, participation voluntary, and the ability to stop or withdraw explicit. It also recommends giving people the information in advance so they can prepare and decide whether they are comfortable taking part (Getting informed consent for user research; Finding participants for user research).

Ask about situations, not just preferences

In a short interview, begin with recent, ordinary examples. Ask what kinds of digital messages people already notice, when they tend to welcome them, and what is happening when they ignore or dismiss them. Then explore context: time of day, what they are doing, whether they initiated an activity, and whether another person is nearby. Keep the discussion focused on observable routines and choices rather than asking participants to predict an abstract ideal.

Useful neutral prompts include: “Tell me about a recent time an app contacted you when you were busy,” “What would make a message like this useful in that moment?” and “Are there times you would want this feature to stay quiet?” Follow with “What makes that situation different?” Give the participant room to define the boundary. Do not fill pauses with reasons they have not offered or present a “yes” as the preferred answer.

Ask separately about kinds of contact. A person might be open to a brief in-app suggestion while using a feature, but not a push alert that appears when the app is closed. They may want a message only after they have opted into a particular activity, or no unsolicited message at all. Apple’s notification documentation makes a related product distinction: it advises asking for notification permission in a context where the purpose is understandable, and describes notifications as potentially disruptive (Asking permission to use notifications). That platform guidance does not establish what your users prefer; interviews should uncover their own terms and situations.

Make the research invitation genuinely optional

The invitation to participate should not resemble the proactive feature being studied. State that the session is research, what the participant will be asked to do, what information you will collect, and how the findings will be used. Ask for agreement directly. Make it easy to decline without losing access to the ordinary experience. GOV.UK’s guidance on collecting personal information recommends a direct, specific choice and says refusal should not block use of the service (Collecting personal information from users).

Before taking notes or recording, explain those choices and obtain agreement for the specific collection method. A participant might agree to an interview but decline recording. Make clear they can skip a question, pause, or stop. The GOV.UK guidance recommends getting informed consent before notes or recordings and using them only for what was agreed (Taking notes and recording user research sessions).

At the end, ask whether the participant is comfortable with what was captured and remind them how to follow up if they want to revisit their choice. Keep notes focused on the design question; avoid collecting personal detail that is not needed. Explain that the research team is learning about contact preferences, rather than trying to persuade participants to accept a feature.

Test the idea with a reversible prototype

After interviews, turn the emerging situations into a small set of message concepts. Use neutral examples tied to ordinary activities, and show the trigger and delivery context along with the wording. A message is not just a sentence: participants need to know whether it arrives during active use, appears later, or reaches them outside the product. Label the concept clearly as a prototype so people do not mistake it for a live feature.

Let participants try a reversible choice such as “show me this example,” “try it for this activity,” or “no proactive messages.” If the prototype simulates a notification, show how to stop the trial and confirm that stopping works. Do not send real messages as part of a test unless people have knowingly opted into that specific trial. Keep the trial short enough that participants can assess the experience without being committed to an ongoing setting.

Observe actions as well as answers: do people choose to enable the example, dismiss it, change the proposed context, or turn it off? Ask what they expected each control to do. This is an applied research method, not evidence that any one control will suit every product. The central test is whether participants can understand the choice and reverse it without friction.

Record refusals as actionable boundaries

Saying “no” can mean different things. A participant may reject one timing, one message type, one activity, or all proactive contact. Record the boundary in their words and the conditions around it. A useful synthesis groups findings by situation and choice: welcomed in a chosen activity, only acceptable in a limited context, or explicitly unwanted. Keep “no contact” visible as its own finding rather than burying it under a broad preference for occasional messages.

Separate what people said from your interpretation. For example: “Participant asked for no messages outside an active session” is an observation; “a session-only option may be needed” is a design inference. Capture uncertainty too. One interview can identify a possible boundary, but it cannot establish how common that preference is across the audience.

Use the findings to decide whether the feature should proceed and what choices the design must expose. If people describe meaningful no-contact situations, reflect those in the concept and test them again. If participants choose no proactive contact, preserve that outcome in the prototype and research summary. The point of listening is to let users’ refusals change the design.

A practical sequence for the first research round

Describe one proposed proactive behavior, including its trigger, message, and delivery context.

Invite likely users with a clear, optional research invitation; share the session details in advance.

Ask about recent messages and specific situations where contact is welcome, limited, or unwanted.

Present a clearly labeled prototype with distinct choices, including no proactive contact.

Let participants reverse their choice, and observe whether the controls match their expectations.

Synthesize direct observations separately from design inferences; carry explicit off choices into the next concept.

This sequence helps a team learn whether proactive contact has a place in the experience before it builds around an assumption. Interviews reveal the situations people describe; reversible prototypes let them respond to a concrete choice. Together, they make “no” useful design input and give people a real way to choose quiet.

Keep exploring this topic