“It feels a bit slow on my phone” — how should we deal with that sense of discomfort?

Introduction: That “3‑second delay” might be someone’s important signal

“Our site shows a little loading screen when you view it on a smartphone. It’s only about 3 seconds, but it kind of bothers me.”

An offhand comment from an executive.
It was by no means a complaint, let alone anger.
Still, I felt that this “slight sense of discomfort” carried with it expectations for product trustworthiness and user experience.

When we dug into this discomfort, we found that even within the development team it had been something like, “Yeah, I’ve kind of noticed it,” or “But maybe it’s not urgent,” and had slipped by without being put into words.

In this column, using this kind of "slow‑burn discomfort" as an entry point, we'll try to organize:

• Why is this problem so easy to overlook?
• Who on the team felt what, from which position?
• How can we go beyond a purely technical discussion and create a state where this can actually be “handled”?

“I had noticed it, but couldn’t put it into words.”
“I understand the realities on the ground, but it still bothers me.”

If this can become even a small opportunity for those two sides to move closer together, I’ll be glad.

“It feels kind of slow on my phone” — a story that started from one observation

Near the end of a meeting, an executive casually said:

“Our site shows a loading screen every time I view it on my phone. It’s only about 3 seconds, but it feels a bit long.”

It wasn’t a precise criticism, just a sharing of a “vague concern.”
But precisely because they care about the business and brand impression, that discomfort couldn’t be ignored.

In reality, the situation looked like this:

• A mobile site that had been released with no issues in terms of appearance or content
• No user complaints or critical bugs
• But recently, a few seconds of loading had started appearing on first access, leaving the impression of “Isn’t this a bit slower than before?”
• Internally, the consensus was “That much is inevitable” and “There’s no technical problem,” but—

Just a few seconds of experience can create a feeling of “Is this really okay?” and lead to wavering over whether “it’s acceptable to ship with this behavior.”

A “perceptual gap” that doesn’t show up in metrics, yet influences business decisions. That might be where the seeds of small misunderstandings are hiding.

Who felt what? Roles, positions, and thoughts

This phenomenon involves several roles and responsibilities intertwined in a complex way.
Here, we'll organize why it's "hard to notice, yet hard to leave alone" from each perspective.

👨‍💻 Frontend engineer

• Role
  • Responsible for implementing the UI and optimizing performance
• What they’re thinking
  • Basic optimizations like SSR (server‑side rendering) and lazy‑loading images are already in place
  • With new development and bug fixes taking priority, there’s no bandwidth to address subtle display delays on existing pages
  • They also feel that “this level of loading is common in SPAs (single‑page applications)”
  • There’s no major delay in the numbers, so they didn’t see it as serious

“We’ve already optimized it properly; anything more would require changing the architecture…”

🧑‍💼 Engineering manager

• Role
  • Sets priorities while looking at both technical decisions and business impact
• What they’re thinking
  • They understand that the team is fully occupied with delivering new features and fixing bugs
  • At the same time, they sense that “this discomfort might be a sign of something”
  • They understand SPA‑specific loading and structural constraints, yet feel uneasy about just writing it off as “inevitable”
  • Technically it’s improvable, but the cost is high, so they’ve been postponing the decision

“Given our current resources, there’s only so much we can do. But is it really okay to just ignore this…?”

👔 Executive (CEO)

• Role
  • Responsible for overall service value, brand experience, and growth strategy
• What they’re thinking
  • They don’t grasp the technical details, but intuitively feel that their own sense of discomfort is probably close to what users feel
  • They felt that the moment they thought “This got slower,” their trust in the service as a whole dipped a little
  • It doesn’t look like a serious problem right now, but it might be an early sign that the “quality” of the experience is gradually eroding
  • Still, they’re unsure how far to push in asking for improvements

“It’s only 3 seconds, but compared to how smooth it used to be, something catches now…”

📈 Marketing

• Role
  • Designs user flows after site entry and plans improvement measures while watching KPIs like CVR and bounce rate
• What they’re thinking
  • They understand that perceived speed affects CVR (conversion rate) and bounce rate
  • But this kind of “subtle slowness” is hard to detect because it doesn’t easily show up in numbers
  • They’d like to verify it with A/B tests or user tests, but don’t have the capacity to jump on it right away

“The numbers haven’t worsened that much. But if someone’s bothered by it… maybe there are invisible drop‑offs.”

“By the time we noticed, it had gotten slow” — common patterns of UX degradation

This kind of “not a clear failure, but somehow bothersome discomfort” is far from rare.

At first glance, it’s a small change.
But as it accumulates, it can gradually cast a shadow over users’ impressions and the overall experience.

Here are some examples of “slow‑burn UX degradation” we’ve seen in real‑world projects. Many are cases where, “Looking back, that might have been the first sign.”

Buttons don’t respond immediately when tapped

The UI is visible, but internal processing causes a slight delay in response.
This can lead to “No response, so I’ll tap again → double submission.”

Search and filter results have gotten sluggish

They used to appear instantly, but now take a few seconds.
Since it’s not a spec violation, it’s hard to raise the priority.

A brief white screen appears during page transitions

The visual smoothness is lost, leaving an impression of “somehow sloppy.”

The dashboard freezes for a moment after login

The “moment you start using it” is heavy, hurting the user’s first impression.

Input forms don’t handle IME conversion well / focus jumps away

Minor issues, but they create significant input stress and can become a cause of user drop‑off.

These “seeds of discomfort” tend to get buried in day‑to‑day development.
But once someone notices them, how do we create a state where they can be handled? That can be a turning point that determines the flexibility of the product and the team.

Why is this discomfort so easy to overlook?

This “somehow it got slower” perceptual gap is hard to deal with precisely because it’s not a clear bug.
Even when noticed, it tends to get pushed back in the daily flow of development and decision‑making.

Here, we'll organize some hypothesis‑based reasons why this phenomenon is often overlooked.

Hypothesis 1: Because there were no issues right after release, we assume it’s still fine

At initial release, it was fast and comfortable.
That memory makes it easy to judge that “it’s probably fine” even when some delay appears.

A psychological bias of “Once something has been approved, it’s safe” may be at work.

Hypothesis 2: It gradually got heavier as new features were added

As page structure and rendering logic grow more complex and more images and libraries are loaded,
performance gradually degrades — but the change is hard to notice day‑to‑day.

Because there’s an assumption that “Of course it gets heavier as features increase,” people may unconsciously accept it as a “side effect of evolution” rather than “degradation.”

Hypothesis 3: Performance monitoring is “installed but not watched”

Tools like APM (Application Performance Monitoring) and Lighthouse are in place.
But the focus is mainly on error rates and incident detection, not UX‑oriented performance changes.

Unless someone is explicitly assigned to “check regularly” within the development cycle, gradual performance degradation tends to get buried in the logs.

Hypothesis 4: Things that “don’t break immediately” are easy to postpone

Users aren’t obviously dropping off, and there are no critical errors.
So it’s easy to decide, “We don’t have to fix this right now.”

Given that urgent tasks will always push others aside, it’s natural that “slow‑burn experience quality” is hard to keep in view.

Hypothesis 5: Perceptual gaps vary by person and rarely become shared understanding

One person might feel, “Hasn’t this gotten a bit slow lately?” while another responds, “I don’t really notice anything.”
In this way, the discomfort may never become shared and just gets brushed aside.

Because performance is sometimes hard to evaluate quantitatively, there are many cases of “We noticed it, but couldn’t treat it as a basis for decisions.”

Multiple small structures like these overlap, and discomfort gets overlooked as mere discomfort.
That may be the background behind the gradual impact on the product’s “overall impression.”

What we can do to make discomfort something we can “handle”

This kind of “slow‑burn” performance degradation is:
hard to notice, hard to quantify, and low in urgency.
That’s why the key is how to build a structure within the team that can actually handle it.

Based on the earlier hypotheses, here are some ideas for dealing with it.

Solution 1: Explicitly state within the team that “the first impression becomes the baseline”

Related to Hypothesis 1: the structure where we get complacent because there were no issues right after release.

Simply sharing the premise that “the initial comfort level continues to be the unconscious baseline” can significantly change awareness of perceptual degradation.

In team meetings or retrospectives, casually sharing things like “Doesn’t it feel a bit slower to render lately?” can also help build a culture where gut feelings are treated as valid input.

Solution 2: Gradually weave a “performance prevention” mindset into the development process

Related to Hypothesis 2: the structure where degradation that comes with feature additions is written off as “inevitable.”

Just taking a brief moment after releasing a new feature to ask, “Is there anything here that might affect performance going forward?” can help reduce unconscious heaviness.

It’s also effective to add “not worsening performance” as a criterion in technical choices.

Solution 3: Assume “if no one owns it, no one will look” and assign it to someone

Related to Hypothesis 3: the problem of tools being installed but not watched.

If you already have APM or Lighthouse, simply clarifying “who looks at it” is a big step forward.

You can also build in reminders for regular checks into sprint reviews or meetings.

It doesn’t have to be real‑time — even “check once a month” is enough to start.

Solution 4: Actively verbalize and record “it’s not broken, but it bothers me”

Related to Hypothesis 4: the structure where things tend to be judged as “not urgent.”

For example, you can manage a list in Notion or GitHub of “Things we noticed but aren’t addressing yet.”

If you also record user‑perspective notes and observations about the experience, they become useful material when you revisit the issue later.

Even if you don’t solve it on the spot, “preserving the discomfort itself” has value.

Solution 5: Create mechanisms that make it easy to share qualitative discomfort within the team

Related to Hypothesis 5: the structure where individual differences prevent shared understanding.

It’s important to consciously create an atmosphere where “I notice it, even if others don’t” is something you’re allowed to share.

For example, you could create a Slack channel like “slightly‑bothersome‑UX,” or casually ask at the start of a regular meeting, “Noticed anything lately while using the product?” Even that can help cultivate an environment where people feel comfortable sharing what they notice.

Summary: Don’t fight the structure — make it something you can handle

The discomfort of “It feels kind of slow” is structurally easy to overlook.
So instead of trying to eliminate it completely, focus on:

• Making it catchable
• Making it easy to share
• Leaving a record so it’s not forgotten

Building this kind of “manageable system” may ultimately help protect user experience and trust.

Starting points: Small steps toward a team that can notice and talk about issues

After reading this far, you might be thinking:

“I get why it’s easy to miss, but realistically we just don’t have the bandwidth…”

That’s understandable. Because performance discomfort is “not a critical bug,” it tends to get pushed down the priority list.

That’s why, instead of trying to overhaul big structures all at once, it’s more realistic to build things up gradually in manageable units. Here are some initiatives that were relatively easy to try and helped teams move forward when started small.

1. Leave “things that bothered you” somewhere

• Create a #bothersome‑UX channel in Slack
• Put a scratch file like perf-notes.md in a GitHub repo
• Create a “log of experiences that felt off” section in Notion

Even just recording “things we don’t want to ignore, even if we won’t fix them right now” provides material for future decisions.

2. Periodically ask, “Has anything changed around display speed?”

• Casually ask after sprint reviews
• Bring it up during small talk in regular meetings

What matters more than “aligning on which metrics to watch” is “bringing together what people feel.” It pokes a small hole in the structure where “no one notices until someone speaks up.”

3. Build a habit of looking at APM and Lighthouse data

• Even once a month, look at graphs like “First Contentful Paint” in your APM
• Foster a culture where developers voluntarily check Lighthouse scores after releasing new features

Numbers aren’t everything, but being able to look at “feelings and indicators together” improves the accuracy of decisions.

4. Look not only from a technical angle, but also alongside user behavior

• Check heatmaps or session replays
• See whether users stop interacting during loading
• Use A/B tests to try different perceived speeds

These tools help you imagine “what it feels like” for users more concretely.

5. Also record the reasons for “not doing it”

• Log decisions like “We wanted to improve this, but postponed it this time”
• When there’s a trail of decisions, it creates an atmosphere where “we noticed but couldn’t act” isn’t something to be blamed for

This kind of transparency lowers the barrier to tackling it next time and makes discussion easier.

Even small steps make a difference once it’s “something we can handle”

Perceptual performance degradation is hard to judge, and no one can definitively say “this is the right answer.”
But whether the team has room for “picking up small concerns” can make a real difference in product impression and trust.

Instead of aiming for a perfect experience from the start, gradually increase the states of “we can notice,” “we can say it,” and “we can record it.”
Even that can change how the team relates to the product.

In closing: Teams that can notice experience quality are strong teams

A 3‑second loading screen.
At first glance, it might seem “within acceptable range.”
But behind that “somehow bothers me” discomfort, there may be a feeling of “I care because I trust this product,” whether as a user or as an executive.

Even if it’s hard to build a perfect experience from the outset, a “stance of steadily building trust” is something that matters at any product stage.

On‑the‑ground development teams work under many constraints and priorities every day.
How can we improve things further without breaking what already works?
Within that struggle, the space to face “small discomforts” tends to disappear unless we consciously protect it.

That’s why we need:

“A culture where people can say when something bothers them”

“A mechanism where what’s said is properly preserved”

“A state where things we can’t do now are still treated as material for ‘doing them later’”

Gradually cultivating this kind of foundation may be what leads to long‑lived products and resilient teams.

This column is not meant to present a definitive answer, but rather to serve as “one piece of material you might remember if something similar happens in your team someday.”

May your team’s “slight slowness” become a starting point for constructive conversations.

By the way…
In our team, we support challenges like this one:

• Diagnosis and improvement support for page display speed and UX performance
• Designing how to introduce and leverage tools like APM and Lighthouse
• Building architectures and review processes that prevent technical debt from piling up
• Supporting in‑house engineering practices that foster a “culture that picks up on signals”

We work alongside teams on these themes, staying close to the realities on the ground.

“If feel there’s a problem, but don’t know where to start.”
“We want to keep improving without increasing the team’s burden.”

If that resonates with you, we’d be happy to start by simply listening to your story.