The whole reason.
I am not an engineer.
I went to design school. I spent 20 years inside the biggest technology companies in the world — not writing code, but fighting for the person who wasn't in the room.
Then I had kids. A four-year-old who asks how Alexa works. A baby who is going to grow up thinking all of this is completely normal. And I realized the person I'd been fighting for my whole career was right here at home.
So I stopped fighting for them inside other people's products. I started building something of my own.
Talking to Robots is built by a designer who learned to build. Not an engineer. A parent. Someone who remembers exactly what it felt like not to know — and decided that feeling should be optional.
Every post, every game, every song gets tested by a four-year-old first. If they don't get it, it goes back in the oven. If they love it, it ships. That's the bar. Not MIT. Two kids on a Saturday morning.
"The engineers in those rooms were not smarter than the people outside them. They just had more time and more exposure. The gap is access, not ability."
Over time I started getting hired to work on technology products. Not to write the code — to design the experience, to figure out how real people would actually use the thing. That work took me inside some of the largest technology companies in the world. I sat in rooms with people from MIT, Stanford, Princeton, Yale. The top of the field.
Those rooms taught me two things. How much I knew. And how much I did not know. But they also taught me something else: anybody can learn this. The gap was access, not ability.
There is an album inside someone reading this right now.
A business. A store. An idea that has been sitting in a notebook for years waiting for a technical green light that never came.
The tools that used to require a team of specialists and a six-figure budget now cost fourteen dollars a month and run from a laptop. You can start a record label this afternoon. You can build a store before dinner. You can use AI to write, design, compose, code, and launch — not someday, not in theory, right now.
What you need is someone to explain how without making you feel like you should already know.
That is this blog. I document my own experiments. I learn something, break something, figure it out, and write it down in the plainest language I can find. No jargon. No assumed knowledge.
"This is not engineering documentation. This is the thing I always wished existed instead."
When a technical term is unavoidable, I explain it the way I wish someone had explained it to me — like you are a smart person who just never had a reason to learn this yet.
Some posts are step-by-step tutorials. Some are honest reviews of tools I tried and what actually happened. Some are me running an experiment in real time, including the parts where it went sideways. No schedule. No filler. Just the real stuff.
Twenty years fighting for the user not in the room.
One of my main jobs as a UX Director was making sure that anything we designed — software for contact centers, payment flows, online pharmacies, checkout experiences — could be understood by the person actually using it. Not the person who built it. Not the person who approved the budget.
The person sitting at a counter or a kitchen table trying to get something done.
That meant writing interface copy in plain language, designing flows that did not require a manual, and fighting hard in rooms full of engineers for the user who was not in the room.
This blog is the same job, different format. The same obsession with plain language and human clarity, applied to the tools themselves — not just the interfaces on top of them.
That gap is closing fast. AI is closing it.