> I'm really afraid we can't solve a "mediocre diction" problem.
So you're not asking "How can I present my work-in-progress to potential customers so that they focus on the potential & not the missing features?".
Instead your asking "How can I present a product that has (and always will have) limitations?" and so will never have a "fully satisfactory experience". Is that right?
I think this is an important distinction (that I didn't get from reading your original post).
But if you sell me something as an electric screwdriver and then I need to use it manually, you've set me up for disappointment.
Feedback, in the UI sense: one of the biggest annoyances for me is using Google Auto. I issue a voice command and it says "Sorry, I don't understand 'navigate home'". Clearly, the audio process was fine, clearly the voice-to-text interpretation was fine, 'navigate home' is a command it recognises, so I deduce there was some back-end error but it's not specified in the applications feedback. It seems it would be super easy to check if the phrase they're telling the user that they don't understand was in a list of common phrases that the application handles. "Our app works best in a brightly lit environment, with microphone noise filtering turned on, and a clutter-free high-contrast background".
Like, I wish computer games came with (free before you buy!) simple benchmarks; "if you score above 100 on $benchmark you should be able to run at 60fps on default settings; above 200 75fps on max". Then it's really easy to know things are working or if you need to monkey around with drivers and settings and such.
IMO if you're struggling to get good input then you should score the input against the characteristics you want to improve, like "30% for audio quality, 80% for recognised commands, 50% for gesture quality;" change the score on the fly so users can easily tell if they're doing it right?
/ranty-mc-rantface