BigKidWords. Voice-activated literacy for kids.

The thesis

BigKidWords started as a personal project. A colleague’s four-year-old daughter was asking what words meant faster than the adults around her could answer. The dictionaries did not work. She could not read the definitions, and the kid-friendly ones substituted other words she also did not know. The voice assistants did not work either. They were tuned for adult speech and adult questions, and they treated a four-year-old asking “what does enormous mean” the way they treated her mother asking the same thing in a hurry. Neither side of the market spoke kid.

The thesis was that this was a software problem, not an education problem. A kid who could not yet spell, type, or read fluently was a user at the edges of typical UX. Build for that user, and the result would not look like a dictionary or like a voice assistant. It would be one button. Press it, speak any word, get back an explanation the kid could understand, in the kid’s tempo, with the right voice. No accounts, no menus, no decisions to make. Adults could already help themselves. The design budget belonged to the kid.

What we shipped

Live on iOS with public beta on Androidp in the spring of 2024. The single-screen experience held to the original brief: one big button, press and hold to speak, release and listen. The app returned an audio explanation tuned to a young listener, plus a written version for kids who were starting to read along. Three product principles got picked up and held.

1. Safety by default. The app refused to explain inappropriate words. Parents did not have to configure that, and a kid testing limits did not get past it.
2. Privacy as a posture, not a checkbox.A kid’s voice was never stored. That was a non-negotiable, and it shaped a lot of downstream choices.
3. Single-touch simplicity. No login, no profile, no settings page in the kid-facing experience. The grown-up controls were tucked behind a long-press that small fingers did not stumble into.

The app reached families in the our network, then a handful of classrooms through a private-school pilot conversation in California. Feedback ran through an in-app emoji panel and a dedicated email address that parents and teachers actually used.

Capabilities the work demonstrated

BigKidWords was a study in designing for users at the edges of typical UX. The disciplines transferred cleanly into the client work the studio does now.

• Voice-first interfaces for non-typical speakers. A four-year-old does not say “enormous.” She says “ee-norm-iss” with the emphasis in the wrong place, and the system has to land on the right word anyway. Tuning a voice surface for users who do not speak the way the underlying systems expect is now a recurring theme in our enterprise work. The people on the receiving end of internal tools rarely speak the way the tool was trained on either.
• Safety, privacy, and compliance for sensitive audiences. Child-privacy posture, and content guardrails for a product used by minors translated one-for-one to the regulated industries that hire us now. Different acronyms, same instinct. Assume the user is the population least able to protect themselves, and design from there.
• Founder-as-first-user rigor. The product was usable, daily, by a real child whose feedback was non-negotiable. That kept the team honest in ways a synthetic persona never would have. We push the same discipline into client engagements: get the system in the hands of the person who will actually use it, before the team gets clever.

What we learned

BigKidWords did not become the company. The retrospective is more valuable than the product was.

The first lesson was about distribution into children’s education. Selling a kid product means selling to parents, and selling at scale means selling to schools. Both audiences are slow, cautious, and rightly skeptical of new software around children. A small studio shipping nights and weekends could not move the institutional flywheel fast enough to compete with platforms that already had teachers’ attention. Distribution beat product, and we underweighted distribution.

The second lesson was about scope. Halfway through the beta the team had to choose between going deep on the kid experience (illustrations, sentence examples, repeat and rephrase) or going wide across subjects (BigKid Math, BigKid Science). We sketched both. We finished neither. The version of the product that would have won was the deep one, and the version that felt most exciting on the roadmap was the wide one. Founder excitement is not a good prioritization signal in a category this slow to adopt.

The third lesson was about the second audience. Adult learners with low literacy started asking, unprompted, whether the app was for them. The instinct was correct. The UX that worked for a six-year-old also worked for an adult who had been embarrassed out of asking what a word meant for thirty years. We began designing an adult mode. With hindsight, the better move was to pick one audience and earn the right to the other, rather than build for both before the first was sticky.

The fourth lesson was about who we are. BigKidWords confirmed what Tadah had already suggested. This team is better at shipping the agent inside someone else’s organization than at acquiring consumer users to one we own. The product taste, the safety instincts, and the comfort with users who do not look like the engineer building for them all carried over. The consumer go-to-market did not need to.