Quality UI Is Cheap. Quality UX Takes Work.
A polished screen is easier to obtain than a dependable experience. That is the distinction I care about when people say UI has become cheap. Templates and generated layouts can provide a useful starting point; the hard work is making the product hold together when the user, data or device does something inconvenient.
Key Takeaways
- A screenshot proves appearance in one state.
- UX quality includes errors, interruptions and real device conditions.
- Templates can help, but the resulting behavior still needs ownership.
- Review the task before judging the polish.
The screenshot does not show the failure
An onboarding screen can look balanced while a page indicator covers the Continue button on a different device. That happened in our TrackCold work: the indicator was positioned from one edge while separate spacing tried to keep the content clear. The measurements agreed on iPhone and disagreed in iPad compatibility mode.
The fix was to let the layout reserve the space with a safe-area inset. The lesson is concrete: one system should own the relationship. Another round of visual polish would not have solved it. The example is discussed in five mobile-app redesign flags.
Craft is the work between the attractive states
Inspect a save action while the network is slow. Return after the app has been interrupted. Open a form with large text. Try the task without the permission the designer's account had.
The user needs to know what happened and how to recover. Those are design decisions, even when implementing them requires engineering.
The microinteraction guide walks through that work for a save action. WCAG understanding documents provide independent criteria for accessible behavior.
Templates are a beginning, not an excuse
Reusing a good component can be responsible craft. Rebuilding everything is not inherently better. The problem begins when nobody checks whether the component fits the actual task or assumes that attractive defaults establish usability.
Ask what the template leaves undecided: permissions, error language, content extremes, responsive behavior, persistence and integration states. Assign those decisions rather than hoping they will emerge during implementation.
Review the product in the order users experience it
Use one realistic task:
- Can the person understand why they are here?
- Can they start without information they do not have?
- Can they tell whether the action worked?
- Can they recover from an ordinary mistake?
- Can they leave and return without losing necessary context?
Record failures, then judge the visuals in that context. A beautiful screen can pass all five; an ugly one can fail all five. Appearance alone does not decide.
Give someone ownership of the whole experience
That person might be a founder, an internal designer or an external partner. A dedicated team is not automatically required; clear responsibility is.
Use UX measurement to check whether the work helped. The evidence may be a completed task, a reproducible repaired bug or a well-designed experiment. It should be more than “the new version looks premium.”
This is an argument for dependable behavior, not a claim that the industry's UX quality has been measured and found to be declining.
Have a product idea?
Designed, built, and shipped in about 5 days.