Eric Yim: Why the product experience matters to me

I think the way a product feels and looks matters because it reflects how much thought went into the experience. With all the new technology and all the slop coming out, I believe products built with real care will stand out. I want there to be real life experiences and thoughts and fights as to why a product was built that way.

By Eric Yim, Protocol Text

The details should have a reason behind them

When I talk about product experience, I mean the way someone interacts with the product: what they see, what it asks them to do, and how they know what happened. Appearance is part of that. So are the words, the order of the steps, and the moments when someone needs help.

A product can look polished and still leave you doing a lot of figuring out. For a service business owner, that might mean wondering whether a marketing draft has been saved, approved, or published. Those are different states. The experience should make the difference clear.

That's the kind of detail I care about. I want the decisions behind a product to come from paying attention, rather than just telling AI to do it and accepting whatever comes back.

AI can be part of building something. My concern is how much thought happens around it. Someone still has to decide what makes sense for the person using the product, question the first version, and notice what's confusing.

Why I’m trying to make marketing happen through text

At Protocol Text, I'm trying to make the entire thing through text. Design, experience, and the way people interact with my software are small details that I feel really opinionated about. I want to make that a really good experience.

Text sounds simple, but choosing text doesn't settle the design questions. What should a message ask for? How much context does someone need? What happens when their reply is incomplete? A conversation can become confusing if those decisions haven't been worked through.

For example, a request to “approve this” should make clear what “this” is and what approval will do. That's an illustrative design choice, not a description of a finished Protocol Text feature. It's a useful way to think about the level of care an interaction needs.

I believe those small decisions matter, especially when they're informed by relationships, going out in person, and the care of telling the stories. Some details are hard to copy because you have to pay close attention to notice why they're there.

Try one real task instead of judging the demo

If you're evaluating marketing software for your service business, I'd use a practical exercise: bring one task you actually need to do and ask to walk through it. A polished demo shows the intended path. Your task helps you see whether that path fits your work.

Here's an illustrative example. Suppose you want to turn a few job photos and a short explanation into a marketing post. Before the demo, write down what you'd have available: the photos, what the work involved, and anything that shouldn't be shared publicly.

1. Start with that material. Ask the person demonstrating the tool to show what you'd submit and what else you'd need to provide. Notice whether the prompts help you explain the work.
2. Ask for a correction. Suppose the draft misstates one detail. Walk through changing it, then check whether you can tell which version is current.
3. Follow the approval. Ask what happens next, who is responsible, and how you'd know whether the post is waiting or live.
4. Try an interruption. Stop partway through and ask how you'd return later. Service work doesn't always leave room to finish marketing in one sitting.

During the walkthrough, ask why a step works the way it does. A useful answer connects the decision to a specific need or tradeoff. You don't have to agree with every choice. You do need to understand whether the choices fit how you'll use the product.

Care also means knowing when to stop polishing

I think the solution comes from the conflict between thinking in the macro and thinking in the micro: the big vision and the nitty-gritty stuff that needs to get done. There's a balance between when to move fast and when to slow down.

For a business owner comparing tools, I'd slow down around decisions that affect accuracy, approval, privacy, or who has to do the work. A cosmetic preference may matter less than knowing whether something will publish without your review.

My belief that thoughtful products will stand out isn't a promise of marketing results. A good experience can make work clearer, but it doesn't establish whether a marketing approach will bring you customers. Evaluate the experience and the marketing plan separately.

Frequently asked questions

What if a tool needs training before it feels easy?

Training alone doesn't mean the design is bad. Ask what you'll need to learn for your regular tasks and what help is available afterward. Then try a task yourself. The useful distinction is between learning an unfamiliar process and repeatedly needing help because the product leaves something unclear.

Should I rule out a tool if it’s missing a feature?

Look at the work that feature would handle. If it's essential, ask how you'd complete it without the feature and who would own that extra work. A clear workaround may be acceptable. A promised future feature shouldn't be treated as something you can use today.

How can I compare tools when both demos look good?

Give both providers the same task and the same correction to handle. Write down what you had to supply, where you needed help, and what remained your responsibility. That gives you a comparison based on the work you'd actually do, alongside price and service terms.