I want to give very specific feedback about the decision to move Read Aloud behind the three-dot menu on iOS.
For me, this is not a rarely used secondary feature. I use Read Aloud on virtually every single ChatGPT response. Moving it therefore hasn’t added one extra tap occasionally - it has added friction to almost every interaction I have with ChatGPT.
My normal workflow is:
- I speak into the standard microphone/dictation input.
- My speech is transcribed into a normal text message.
- ChatGPT processes that as a full written prompt and gives me a normal, comprehensive written response.
- I immediately press Read Aloud and listen to that response.
That workflow is deliberate. Voice Mode is not an equivalent substitute.
When I’m thinking out loud, I can speak for a long time, pause, reformulate things, add context and get everything out before submitting it. Once submitted, there is a clear boundary: my input is finished, ChatGPT generates the complete response, and then I choose to listen to it.
In live Voice Mode, that boundary is much less reliable. Background noise or another person speaking can be interpreted as me talking and interrupt the response. The conversational format can also behave differently from submitting a long transcribed text prompt and receiving the full normal written answer. I specifically use dictation + normal chat + Read Aloud because it gives me the advantages of speech without sacrificing the normal text-chat experience.
The old interface supported this extremely well.
Speak → submit → response → one tap → listen.
The new interface is:
Speak → submit → response → tap ••• → move my thumb to a different part of the screen → find Read Aloud → tap again → listen.
That distinction sounds tiny when described as “one extra tap”, but UX friction has to be evaluated by frequency, not merely by the size of an individual action.
If I used Read Aloud once a week, this change would barely matter.
I use it on essentially every response.
So you have taken an action I perform hundreds or potentially thousands of times and made every repetition less efficient.
The physical placement makes it worse on iPhone. The original control was directly accessible near the bottom of the response. Now I press the three-dot button near the bottom, the menu opens above it, and I have to move my thumb back upward to select Read Aloud. So this is not even simply “tap twice”; it introduces an unnecessary bottom → menu → upward thumb movement into a previously automatic one-tap action.
After enough use, the old interaction becomes muscle memory. Breaking that muscle memory for no apparent functional benefit is surprisingly disruptive.
I understand the desire to reduce toolbar clutter. But hiding a feature based only on how many users use it would miss an important distinction:
How many users use Read Aloud?
is not the same question as:
For users who use Read Aloud, what percentage of their responses do they use it on?
A feature can be used by a minority of users while still being absolutely central to those users’ experience.
The obvious solution does not even require forcing Read Aloud back onto everyone’s toolbar:
Please allow users to customise or pin their preferred response actions.
Let users who never use Read Aloud hide it. Let users like me, who use it on almost every response, keep it permanently one tap away.
That would preserve a cleaner default interface without degrading high-frequency workflows.
This change took something that was working exceptionally well and added repeated friction to it. Please either restore Read Aloud to the primary response controls or, preferably, let us customise which actions appear there.