"CPAIT is Frustrating": Revisiting Our Mission Behind the Feedback

Recently, while going through user feedback, I came across a comment: “CPAIT is frustrating.”

CPAIT is frustrating.

I have to admit, my heart sank a little when I read it. The vast majority of our early users loved CPAIT’s pronunciation feedback and found it incredibly helpful. But as our user base grew, it became inevitable that we would receive feedback like this.

We actually anticipated this during the design phase. We knew that a strict pronunciation feedback system would inevitably bring frustration. So, we put a lot of effort into our interaction design and encouragement mechanisms to balance it out. But clearly, we haven’t perfected it yet. This is an ongoing process of optimizing the user experience, and I will keep working on it.

I’m writing this today not to make excuses, but to share the story behind the product. I want people to understand that from a technical standpoint, delivering a better experience with CPAIT is extremely challenging for our product designers, because its underlying technology was built with “pronunciation obsessive” DNA from day one.

The Technical Crossroads that Defined Our DNA

In the early days of building our core speech engine, our core technologist, Arthor, drew two different paths on the whiteboard for us:

• Speech Recognition: Its core task is to understand what you are saying. It is highly tolerant of accents and, by incorporating language models, can even figure out what you meant to say if you mispronounce a word. Most language apps on the market use this engine.

• Speech Diagnosis: Its core task is to judge exactly how you are pronouncing it. It doesn’t care about understanding your intent. It cares about the physical reality of your pronunciation—diagnosing the specific issues with your initials, finals, or tones by comparing your audio to the target pronunciation.

If we chose the Recognition engine, the interaction would be incredibly smooth. As long as the user doesn’t make a completely outrageous mistake, the system will usually identify the words correctly, and everyone is happy.

If we chose the Diagnosis engine, however, the interaction challenge immediately becomes severe. Every time a user completes an exercise, they don’t get a simple score. Instead, it acts like an incredibly strict pronunciation coach, mercilessly pointing out microscopic deviations: “Your initial ’s’ sounds more like a ‘c’.” “Your final ‘a’ sounds like an ’e’.” “Your second tone sounds like a first tone.” Users have to repeatedly compare their pronunciation with the native speaker’s demonstration, adjusting over and over until it is completely accurate.

From a product design perspective, this is a highly dangerous choice. During this “correction” process, it’s incredibly hard for users to get any immediate sense of achievement. Instead, they are met with frustration and the annoyance of being constantly interrupted. We could even predict that users accustomed to “encouragement-based learning” would be confused: “Why can I chat smoothly in other apps, but here I’m riddled with problems?”

The resulting product data was likely to look grim. While user dwell time might increase, churn rate would rise significantly. After all, when facing a system that constantly nitpicks your mistakes, giving up is often easier than persisting.

Here is a real example from our Speech Diagnosis engine. The learner intended to practice “hǎo,” but the system detected that their initial “h” sounded like a “g,” pointing out the exact error in the Initial and Syllable. This is the kind of nitpicking a Recognition engine would completely miss.

Choosing the Recognition engine seemed like the easier path. But based on my intuition as a native speaker about the importance of pronunciation, and our solid user research, we deeply felt that Speech Diagnosis was the only path that could truly solve our users’ problems.

Through extensive user research, we found a painful phenomenon: many Chinese learners study for a long time, spending tremendous time and energy. They memorize countless words and sentences in their heads. But when it comes to actual communication, they stumble frequently. In severe cases, they still find themselves in a state where others can’t understand what they’re saying, and they can’t understand others either.

A huge part of the reason is that they haven’t established a standard cognitive framework for pronunciation. If the foundation is crooked from the start, stacking up more vocabulary later won’t build a truly fluent bridge for communication. If we lower the standard during practice just to “avoid frustrating people,” users will suffer a much greater setback in real-world social situations than they ever would in the app.

Choosing to Be a Pronunciation “Obsessive”

Our original intention for building CPAIT was solidified right then: We decided to prioritize efficiency.

Behind this decision is a very realistic calculation. We could absolutely cater to human nature, lower the standard, and let users get beautiful high scores every time they practice. This way, they would feel confident and might happily stay active in the app for a long time. But eventually, they would realize that the time they invested yielded returns that were completely disproportionate to their actual communication skills.

We want to help users by genuinely improving their learning efficiency and solving their real pronunciation problems, rather than just providing emotional value. If a product only makes money by making users “feel good” but fails to solve their communication struggles with real native speakers, it goes against our original intention. We would rather play the somewhat “annoying” role during the practice phase than let users face the real world with false confidence.

Of course, prioritizing efficiency absolutely does not mean we can ignore the user’s learning experience. On the contrary, precisely because our underlying engine is so strict—after it was built, its accuracy stabilized at over 95%, operating as a cold, objective, and unwavering diagnostic machine that we won’t easily change just to please users—we must invest several times more effort into interaction design.

We need to build a warm bridge between the cold, objective standards of the machine and the user’s emotional experience. Since we have to correct users repeatedly, we make the correction process more intuitive. We try to turn tones into visualized waveform charts, allowing users to directly see the gap between their pronunciation and the standard sound. We break down every correction into the smallest possible steps, making the process of being “nitpicked” feel more like slowly conquering levels in a game, rather than just getting scolded. Even today, we are still exploring this balance; it is far from perfect.

Final Thoughts

An app with “obsessive” DNA at its technical core is destined not to take a path that makes everyone happy and relaxed. What we do well right now is helping many users build a standard cognitive framework for pronunciation. What we haven’t done well enough is how to soothe those users who feel frustrated.

This is a long optimization process. We adjust the product every day based on feedback, and we are still far from perfection.

When you usually use learning tools, do you value a “smooth, encouragement-based experience” more, or are you willing to accept feedback that is “a bit frustrating, but points out real problems and genuinely improves your efficiency”?