Pattern 24
Listening is not microphone consent
Make playback, capture and AI conversation different states.
Concrete takeaway
Identify the current role and microphone state.
Choose an approach
These are editorial decision conditions to validate. Some alternatives are successive states or can be combined; they are not always exclusive choices.
| Alternative | Use when | Tradeoff or requirement |
|---|---|---|
| A · Audio playback | The person only wants playback | No microphone permission is needed |
| B · Voice input | The person deliberately supplies spoken input | Capture needs separate consent and a stop action |
| C · Spoken AI conversation | The person chooses a spoken AI exchange | Role, processing and recording state need stronger clarity |
The problem
Users may assume they are only hearing a devotional while the product also listens, stores speech or enters a dialogue.
The pattern
Identify the current role and microphone state. Starting voice input is separate from starting playback. Provide clear stop and text alternatives, explain processing and retention, and avoid human or spiritual authority claims.
Compare the alternatives
Make playback, capture and AI conversation different states.
A · Audio playback
No recording is implied by listening.
B · Voice input
Capture starts through an explicit action.
C · Spoken AI conversation
Role and data behaviour are stated clearly.
Original wireframe proposals · No live controls · Grey rows represent schematic text, not loading states · Labelled placeholders are not Scripture quotations
Download this wireframe as SVGFailure modes
Always-on recording disguised as reflection; ambiguous listening animations; a stop action that is available only by voice.
What to validate
Can people tell whether they are being recorded without looking at the screen? Test interruption, permission denial and switching to text.
Research-informed design proposal. These visual alternatives have not been tested with users in this atlas. Source findings, documented behaviour and this proposed adaptation are different kinds of evidence.
Sources and adaptation
This card is an original design synthesis. The following sources inform its content distinctions, interaction approach or review requirements; they do not validate the whole pattern.
- 8 voice AI UX patternsArticle reviewed · A design analysis rather than a clinical or Bible-app validation study. The original short link leads through another Friedman post.
- Voice of AIPublic module overview reviewed · Not every linked learning module was read. The overview does not validate a specific conversation script.
- Designing Audio AI People Actually TrustArticle reviewed · The author scopes this to responsible audio AI, not a complete conversational-agent guideline.
- The Shape of AICatalogue and named entries reviewed · The site states CC BY NC SA. This atlas uses original text and original wireframes; it does not reproduce the source illustrations.
Common scenarios and flows
- Receive prayer support without hidden profiling — Choose useful words or silence while retaining ownership of intentions.
Design principles in this decision
Editorial application of Missional by Design. These values frame review questions; they do not validate a pattern’s effectiveness.
- Reverence — What does this interaction ask of the person, and can they understand, decline, correct or leave it without penalty?
Compare alternatives using the task and evidence above. Record competing needs instead of treating a principle as an automatic verdict.
Regional applicability
Design review questions · 5 October 2026. These prompts identify possible triggers; they do not classify this pattern or every faith app as a regulated service.
Where do prayer, religious, health and audio data actually go? Review memory, model-provider access, logs, analytics, training and exports as separate data flows; a private-looking screen is not a data policy.
Start with EU and Germany, then review the relevant market:
- US · Utah: mental-health chatbots — Enacted AI-specific law
- US · Federal health software and data — Existing law; regulator implementation guidance
- United Kingdom — Existing law + regulator guidance; policy statement
- Australia — Existing law + regulator guidance; national policy
- Canada — Existing privacy law + joint regulator principles
Use the jurisdiction decision guide to record the trigger, source version and resulting product requirement.