What feeling does your product create? (Q&A)

Today we’re digging into an article by @vadym_grin, Feelings are the new features. He argues that emotional design is no longer a nice extra. It is a core part of strategy. When basic features are easy to copy and often free, what makes products stand out is how they make people feel.

Products win when they create trust, confidence, comfort, or delight.

Here’s an example you call out: 5 Minute Journal app with a regular spinner. Stoic app, with a descriptive, reassuring loading screen.

When features no longer differentiate products, the advantage comes from intentionally designing how people feel when they use them.

You call out:

  • Features are easy to copy, so they no longer create a strong advantage
  • Functionality is becoming expected, not special
  • How a product makes people feel is what sets it apart

Let’s jump into the discussion

Products win by shaping how people feel. Emotion drives adoption, guides decisions, and builds lasting relationships beyond features. It sound straightforward, but as an experienced designer we know this is hard to do consistently.

So here’s the question I want to open up: If features no longer create advantage, what feeling should our product consistently create for people, and how do we design for that on purpose?

Looking forward to digging into this with Vadym Grin, a new Glare contributor, sharing ideas. Let’s go!

1 Like

Great to be chatting with you today @vadym_grin, you’ve got some interesting ideas for product and design teams still struggling with finding their place in this AI world that is changing in front of us, literally week by week.

My first question is about feelings. How do you go into projects thinking about how they will emerge from your work? Or do you? Is it natural?

1 Like

Hey @Bryan! Thanks for having me today and sharing my article with the community! Happy to have a chat today about this.

And I’m starting from the very first question in your opening post. If features don’t create advantage anymore, then feelings do. And there are two that matter most:

  • Delight — to win the competition. People remember what made them smile, feel proud, feel “This is for me.” Delight works best on the visceral level of design, so it’s a major step towards making your product stand out in the ocean of AI-generated stuff.

  • Trust — to win, right here, right now, and for as long as possible. If users feel safe, in control, and never punished for a misclick, they stick.

1 Like

I do! And I see this like a constraint of a project.

At the start of it, I usually name one or two feelings I want the experience to leave behind. In reality, in 90% of the cases, it’s “trust” and “delight”. The other 10% might be something else. Once, I was specifically working on some materials called to evoke disguise.

Then everything goes through a sanity-check: copy, color, motion, pacing.

And it becomes natural with reps. Most teams are trained to think in features and flows by now, so you have to practice thinking in aftertaste. The good news is that, once you start doing it, it feels obvious. Like, “How did we ever ship things without asking what people feel when they close the app?”

2 Likes

This is great. As a starting framework, it makes sense to anchor on these two.

They are not simple emotions. They emerge from many touchpoints across the experience. That is why we recommend testing them with a small stack of 4 to 5 metrics to get a clearer, more complete picture of how people actually feel. It’s why we make our metrics open and easy for others to use.

Let’s start with delight and trust. What techniques do you use to help stakeholders understand these complex emotions? Many are just trying to get things done and help their business groups.

Exactly this.

Here, I would like to note that, in the context of emotion design, we have two types of products.

The first type is usually B2B products, in which emotions have always played a very small role. It was believed that, no matter what, you would still use them at work. A good example is Jira from Atlassian. For a long time, there were no alternatives to it due to its rich functionality. However, Linear has now appeared, which simplifies functionality and adds the emotion of trust — “This app cares about me!”. And I believe there will be more stories like this in B2B from now on.

The second type is mainly B2C — products aimed at the general public. Delight and trust were important to them before (for example, the success story of Duolingo is a success story of emotional design). But now, in a world where anyone can make an app, and even one with all the best practices and a good UI, emotions are at the core.

What I’m getting at is that business owners and stakeholders themselves are becoming more interested in design, in designing emotions, because both B2B and B2C worlds need this. Whereas before, it was only us designers who sought to speak the language of business in order to be heard, now, stakeholders themselves are sometimes switching to the language of design.

But, talking about metrics. I translate “delight” and “trust” into business-shaped language and observable behaviors, and then I make it concrete.

  • Name the emotion, then define it in plain terms.

    Trust = “users feel safe pressing the button.”

    Delight = “users feel rewarded for the effort.”

  • Show a before/after story.

    One short flow that feels stressful vs the same flow with clarity, recovery, and a satisfying success moment.

  • Tie it to metrics they already care about.

    Trust shows up in fewer drop-offs, fewer support tickets, higher retention.

    Delight shows up in higher sharing, stronger activation, better brand preference.

  • Use a “moment map.”

    Pick 3 moments: first use, first success, first failure. Ask: “What should the user feel here?” It keeps it practical.

  • Prototype it.

    Stakeholders don’t debate feelings when they can experience the difference in 30 seconds.

And obviously I avoid abstract emotional talk and anchor it in what the user does next — because that’s where business people lean in.

1 Like

Tell me more about these aliens you speak about. :slight_smile:

I love the idea of prototyping. Stakeholders can feel what you are trying to build in the experience almost immediately (often in under 30 seconds as you highlight)

What I see, though, is that many teams get stuck when it is time to turn that feeling into a clear business decision. Things stay fuzzy. Day-to-day operational pressure takes over, and the original vision gets lost or watered down. Many people also struggle to express how the experience feels in business conversations.

Do you have any recommendations for how to hold that tension and carry these ideas through an organization without losing them?

1 Like

Okay, this one is going to be quite a long one. Ready? :smiley:

But you’re right. Emotions in business meetings sometimes land like: *“*OK! Cool… So which ticket is that?” :smiley:

In that classic drop-off, teams can feel the intent in a prototype, but they can’t carry it through delivery pressure. The fix is to turn feelings into mechanisms, that are hard to “forget.”

Here are a few that actually survive contact with reality:

1) Turn the feeling into a decision rule

Make it usable in trade-offs:

  • Trust rule: “When in doubt, we choose clarity and reversibility over cleverness.”

  • Delight rule: “We invest in 1–2 moments per flow where the user should feel rewarded.”

Now you can use it in meetings: “This change adds friction. Does it increase trust enough to justify it?”

2) Attach the feeling to specific moments, not the whole product

Teams fail when “delight” becomes a foggy mandate.

Pick 3–5 signature moments and name them:

  • first-time setup

  • first success

  • first error

  • payment/commit moment

  • sharing/result moment

For each: desired feeling → design principle → acceptance check.

That becomes a tiny “experience spec” people can execute against.

3) Add a one-line “feeling requirement” to tickets

Literally one line in Linear/Jira/Asana whatever:

After this step, the user should feel: confident / rewarded / safe / in control

It’s annoying in the best way, because it forces alignment before pixels! Works amazingly great, I promise :slight_smile:

4) Create an “emotional regression test”

Like QA, but for vibe.

  • Where could this create anxiety?

  • Where did we remove clarity?

  • Where did we take away recovery?

  • Did we weaken the success moment?

If you do nothing else, do this. It prevents “trust erosion by a thousand tiny cuts.”

5) Give stakeholders a business-friendly vocabulary

Most people can’t say “delight,” but they can say:

  • reduces hesitation

  • increases confidence

  • speeds decision-making

  • lowers perceived risk

  • creates a sense of progress

  • makes success feel earned

You’re basically giving them “emotion translators” so it doesn’t sound like a therapy session.

6) Measure proxies that map to the feeling

  • Trust proxies: drop-off at commit steps, support tickets, undo usage, time-to-recover, complaint keywords.

  • Delight proxies: shares, saves, voluntary re-use, unsolicited positive comments, completion with no nudges.

If it’s measured, it doesn’t get “politely ignored.”

7) Assign a single owner for the experience thread

One person whose job is to protect the intended feeling through compromises. Design lead, head of design, VP of design (this one, however, is still rare to see).

If I had to pick the smallest “starter kit” that works: signature moments + one-line ticket requirement + emotional regression check. That combo is light enough to survive operations, but strong enough to prevent the vision from evaporating.

1 Like

Amazing.

Love these as well:

  • reduces hesitation
  • increases confidence
  • speeds decision-making
  • lowers perceived risk
  • creates a sense of progress
  • makes success feel earned

What kind of feedback loop do you create after launch? When the business comes back with numbers and analytics, there is another layer of translation to decide whether to stay the course or adjust the flows.

Design often moves on to other initiatives.

How do you stay proactive in these moments, when feelings are easy to lose in the next round of decisions and stakeholders can get cold feet quickly?

1 Like

They won’t be scared if you promise them benefits. If not an increase in conversion or retention, then at least a reduction in drop-offs :smiley:

That’s why it’s just so important to make sure that all these conversations about emotions, feelings, and trust are not abstract notions, but can be reflected in numbers. Map emotion to a metric before launch — that’s the way to keep it up through every next round of development.

Trust: commit-step, drop-off, backtracks, support tickets, refunds/cancels. It’s a bit, variety of options depends on the context and problems you’re solving.

Delight: completion without nudges, repeats, shares/saves, positive feedback.

And, of course: test, test, test. Adjusting things via micro-experiments can be copy, recovery/undo, errors, success moments, so stakeholders don’t get cold feet, instead see the power of every pixel and every word.

1 Like

Agreed. We are very aligned with this idea.

Thanks Vadym for sharing your thinking and for dropping such useful techniques. We will keep the thread open so others can jump in and add their perspectives!

2 Likes

My pleasure! Happy to contribute to this community! And for everyone who is interested to uncover emotional design deeper, I also invite you to my small digital space — Eidos Design. Will be happy to see you guys there :hugs:

1 Like

Really loved this Q&A @vadym_grin , thank you!

I’m curious how you approach gathering user feedback and sentiment through flows and how you think about them in the context of a flow. Are you focused on gathering at those ‘success’ moments for delight and looking at points of drop-off for trust? How do you think about user effort and fatigue in flows?

Happy to hear you find it useful!

We have 4 major categories: commitment, friction, recovery, and success. These you will find across all the flows in any app. Then, you analyze the data you have (can be direct feedback, but also can be more quantitative data) and categorize it accordingly.

  1. Commit moments (payment, permissions, irreversible actions)
    Goal: trust
    Signal: “Was anything unclear?” / “Did you feel confident continuing?”

  2. Friction moments (forms, waiting, loading, complex choices)
    Goal: reduce fatigue
    Signal: “This took longer than expected” or a simple thumbs up/down on helpfulness

  3. Recovery moments (errors, corrections, undo)
    Goal: trust + relief
    Signal: “Was it easy to fix?”

  4. Success moments (completion, reward, first win)
    Goal: delight
    Signal: “How did this feel?” or “What made this good/bad?”

Delight lives at success, trust shows up in drop-offs, but fatigue lives more in the middle.

And in terms of efforts… I also have some kind of a system here :smiley:

  • Cognitive load: “I have to think too much.”

  • Interaction cost: “So many taps/fields.”

  • Emotional strain: “I’m worried I’ll mess up / get scammed / waste time.”

If you have spots in your flows where you’re asking for multiple things at once (e.g., a long form + unclear benefits + fear of commitment). That’s where fatigue spikes.

The main issue in all this — is getting data. Then it’s relatively easy to analyze it, come up with hypotheses and design options, test those. And thrive! :smiley:

Loooove that framework, it breaks things down in a way I think is intuitive but can be communicated internally.

I think design reviews often get stuck on still screens, and project teams can miss the forest for the trees. Designers are often carrying an intuition of the weight of effort and emotion through a flow that’s difficult to quantify and communicate. This really helps!

1 Like