ux-ui-software-quality-simplifycpp

When UX/UI Becomes a Matter of Quality and Safety — Not Just Colors and Pretty Buttons

When I started programming in the mid-1980s, we did not talk about UX/UI in the broad professional sense we know today.

We cared about whether the program worked.

• Was the calculation correct?

• Was the file saved?

• Did the program crash?

• Was the displayed result the expected one?

Sitting down to discuss how the user feels, how their finger moves across the screen, how many steps it takes to complete a task, or whether a button inspires confidence or causes a minor heart attack was not an independent discipline the way it is today.

For many years, I thought the growing emphasis on UX/UI was something of a luxury, and that a good Frontend developer should be able to handle these matters without turning them into a separate profession.

Then the world changed.

And I admit that I changed my mind with it.

When Our Lives Moved Inside Applications

Today, we do not use software merely to write a message or perform a calculation.

We use it to transfer money, book flights, manage bank accounts, buy medicine, receive government documents, monitor our health, unlock cars, pay bills, and communicate with our workplaces.

The interface has become the door through which the human being enters the entire system.

At that point, UX stopped being decoration.

It became part of Software Quality.

It even touches security, because poorly designed sensitive operations, vague confirmation messages, unexplained permissions, and misleading choices all increase the likelihood that users will take actions they never intended.

Apple itself now emphasizes giving users control, making actions reversible where possible, and requiring clear confirmation before operations with dangerous or difficult-to-reverse consequences.

So we are no longer talking about “the color of the button.”

We are talking about the safety of the relationship between humans and software.

One Finger Movement… and the Punishment of Logging In Again

A few days ago, I was using an important application and logged in normally.

Then my finger accidentally moved from the edge of the screen and triggered the back gesture.

Suddenly, I was thrown out of the workflow I had been using and had to return and log in again.

I stopped for a moment and asked myself:

How can an application used by a huge number of people treat one accidental finger movement as an offense deserving punishment?

The user did not resign from the application.

They did not say:

Please destroy my current session, send me back to the beginning, and thank you for your cooperation.

They moved a finger.

That is where properly understanding UX becomes important.

The solution is not for the application to jump in front of you every three seconds asking:

Are you sure?
Are you sure you are sure?
Would you like to confirm that you still wish to confirm?

That is bad design too.

The goal is for the result of an action to be predictable, recoverable, and as inexpensive as possible.

Android itself is moving in this direction with Predictive Back, which allows users to preview where the back gesture will take them before completing it, specifically to reduce surprising results and make navigation clearer.

If the operating system itself is trying to tell the user, “Look where you are going before you complete this gesture,” it is rather amusing to find an application behaving as though one gesture were an official authorization to demolish the entire session.

Applications That Are Extremely Smart… Until a User Arrives

We have an amusing contradiction today.

An application may contain massive Cloud Infrastructure, Microservices, Kubernetes, AI, real-time analytics, and advanced encryption…

Then you reach the login screen and discover that the OTP field does not allow you to paste the code.

Six digits arrived in a message.

And the application is effectively telling you:

Memorize them, champion. We believe in your mental abilities.

Another application lets you spend ten minutes filling out a long form. Then you receive a phone call, return to the application, and discover that the entire form is empty.

Thank you.

The application has generously provided you with a free opportunity to improve your typing skills.

In another application, you press Submit and receive:

Something went wrong.

Wonderful.

What happened?

We do not know.

What should I do?

We do not know.

Did the operation succeed?

Maybe.

Should I try again?

Take your chances.

This is not a graphical problem.

This is a software quality problem.

The Delete Button Beside the Save Button… Because Life Needs Excitement

Another masterpiece of interface design is placing a dangerous action beside an everyday action, using almost the same color, and then relying on the precision of the human finger.

Or asking:

Are you sure?

And presenting two buttons:

Yes | No

Sure about what, exactly?

This is why Apple’s guidelines recommend that messages for important actions be clear and that buttons describe the actual action instead of using vague answers.

For example, when cancelling a subscription, buttons such as Cancel Subscription and Keep Subscription are much clearer than Yes and No.

Quality here is not about whether the dialog box looks beautiful.

Quality means allowing the user to make the correct decision without first solving a linguistic puzzle.

Even Worse: Ignoring the Operating System Itself

Some applications seem to be built by developers who have decided that Android and iOS are merely suggestions.

The operating system introduces a new navigation pattern?

Doesn’t matter.

Screen sizes change?

The user can adapt.

Foldable phone?

Open it at your own risk.

The user enlarges the font because of poor eyesight?

Why must the user ruin our beautiful design?

Dark mode?

Not in this century’s budget.

Google has become very explicit about this. Current Android guidance treats adherence to standard interaction patterns as part of the baseline for application quality and expects applications to adapt to different screen sizes, foldable devices, and window configurations.

That makes perfect sense.

The user has already learned the language of the operating system.

Do not force them to learn an entirely new language inside your application just because a designer wanted to be “creative.”

Creativity that requires the user to take a training course is not always creativity.

Sometimes it is simply a problem.

UX Is Not the Artist You Call After Programming Is Finished

One of the biggest organizational mistakes is this scenario:

The team finishes the application.

The database is ready.

The APIs are ready.

The features are ready.

Then the manager says:

Now bring in a UX person to make it look nicer.

As though UX were the person who arrives after the house has been built to choose the curtains.

No.

Real UX begins much earlier.

• How does the user reach the task?

• What happens if they make a mistake?

• What happens if the Internet connection drops?

• What happens if they close the application?

• What if they receive a phone call?

• What if they go back?

• What if they have poor eyesight?

• What if they press a button twice?

• What if the server takes five seconds to respond?

• What if payment fails after the money has been deducted?

• What if they do not understand the error message?

These are software engineering questions just as much as they are UX questions.

Will App Stores Eventually Force Developers to Care About Quality?

The good news is that this direction has already begun, although it has not yet reached the level I would like to see.

Google Play no longer considers quality to mean merely the absence of crashes. Its quality model includes the value an application provides, user experience, technical quality, privacy, and security.

Google explicitly states that a good application should be easy to use, and that applications with poor functionality or bad user experiences may violate store policies.

More interestingly, Google already uses signals such as user loss, activity, usability, stability, and performance when evaluating application quality and, in some cases, determining opportunities for visibility within Google Play.

In other words, the idea is beginning to move from:

We recommend that you design a good application.

to:

The quality of your user experience may affect your position within the platform.

That is a good start.

But I hope we go further.

We Need a Quality Experience Revolution

I hope a day comes when passing Security, Crash, and API Compatibility tests is no longer enough.

I would like to see a strict set of Human Interaction Quality tests as well.

• Does the application preserve the user’s state logically?

• Can dangerous actions be reversed or clearly confirmed?

• Does it support standard navigation patterns?

• Are error messages understandable?

• Can the user determine what actually happened after an operation fails?

• Does it respect Accessibility?

• Does it work properly with Gesture Navigation?

• Does it adapt well to screen resizing?

• Does it prevent data loss caused by simple mistakes?

• Has it actually been tested on real people, rather than only on the developer who knows where every button is because they are the one who placed it there?

It makes little sense to reject an application because its icon fails to comply with some store requirement while tolerating a user experience that makes a million people curse the application every morning.

The Real Test: Give It to Someone Who Knows Nothing About It

There is a test I like to imagine.

After the team finishes the application, do not give it to the developer.

Do not give it to the project manager.

Do not give it to the interface designer.

Bring in someone who has never seen it before and tell them:

Complete this task.

Then remain silent.

Do not say:

No, click there.

Do not say:

That icon means…

Do not say:

We all know that gesture here.

If the user needs the application engineer standing behind them explaining how the application works, then a Bug has already been discovered.

Its name is:

Design.

Finally: Code That Does Not Respect the Human Being Is Not High-Quality Code

It took me decades of programming to reach this conclusion.

I once saw software quality mainly as something internal:

• Algorithms

• Architecture

• Performance

• Memory management

• Stability

• Security

Today I believe there is another layer that is no less important:

The moment when that entire system meets a human being.

Behind the screen may be one of the finest software systems ever built.

But if the user needs five minutes to discover how to return to the previous page, loses ten minutes of work because of a Swipe, or is afraid to press a button because they do not know what it will do…

then an important part of that system’s quality has failed.

UX/UI has become a genuine discipline because software no longer lives only inside computers.

We are the ones who now live a significant part of our lives inside software.

Perhaps it is time to stop treating usability as a “nice feature.”

It should become a quality standard.

And in some sensitive applications, perhaps it should become a requirement for publication itself.

After all, the user did not buy a modern phone with an extraordinary processor, a brilliant display, and a high-speed connection…

only to be defeated by the Back button.