The UI looks good to me, but the client says it's not quite right—what usually goes wrong?

UI designs often look "cheap" not because the colors aren't vivid enough, but because three things happen at once: collapsed information hierarchy, chaotic spacing rhythm, and missing interaction states. Following typical project delivery habits in 2026, running through this five-item checklist during interface review can cover most rework reasons that are hard to pinpoint.

Why do interfaces look cheap? The key isn't color

Many designers' first reaction to "looking cheap" is to change the color scheme, but in real projects, the cheapness often comes from structural issues: information lacks hierarchy, element spacing is arbitrary, and state illustrations are missing. Fixing with color only temporarily hides the problem, and it resurfaces during user interaction.

From a design output perspective, an interface is an information container. If the container doesn't even make clear which statement is most important, no matter how sophisticated the palette is, it will be seen as a half-finished product.

• Information hierarchy: A page usually has 3–4 levels; only when titles, body text, and auxiliary information are clearly layered does the eye have a focal point.
• Spacing rhythm: A common practice is to increment on a base of 8px or 4px, e.g., 8, 16, 24, 32, 48, rather than dragging elements at random.
• Complete states: Buttons need normal, hover, pressed, and disabled states; forms need default, focus, error, and success states. When these are missing, the interface looks half-dressed.

Five-step verification method: self-check from hierarchy to consistency

This framework breaks UI acceptance into five actionable dimensions, each with clear inspection actions. Following enterprise project delivery habits, going through each item before handing the design mockup to development can save later revision communication.

1. Hierarchy: Use the "squint test" — squint your eyes and see if the first focal point is the core action; then check whether the font sizes of titles and body text are clearly differentiated.
2. Rhythm: Check whether spacing falls on the base grid; whether the same set of spacing is reused across similar modules.
3. States: Check whether key components cover states such as normal/hover/disabled; whether forms have error indication states.
4. Details: Check whether 1px divider lines and corner radii are consistent, whether icon stroke weights are uniform, and whether text overflows without truncation.
5. Consistency: Zoom out to 25% to see the whole page; check if all dialogs, navigation, and cards follow the same rules.

This five-step method works because it breaks down subjective words like "premium feel" into verifiable objective items. For example, "hierarchy" looks at type size contrast, "rhythm" looks at spacing sequences, and "states" looks at component enumeration. If any item loses points, the overall quality is pulled down.

Common pitfalls: counterexamples and criteria

Based on where clients often get stuck in projects, a few counterexamples deserve special attention.

• Spacing based purely on feeling: If the same type of elements has spacing of 12, then 16, then 20, the visuals will look scattered. The passing criterion is that spacing within the same module uses at most two consecutive base sizes.
• Shadows more prominent than content: If card shadows are too heavy, the page looks dirty. The common practice in 2026 is to use no more than two shadow layers, with gray or low-opacity colors from the same hue.
• Mixed icon systems: Mixing line icons and filled icons, or inconsistent stroke weights, immediately lowers professionalism. It is recommended to use only one icon style in a given interface.
• No text truncation rules: Long Chinese titles without ellipsis or line wrapping will break the layout. You need to define the maximum number of lines for titles and summaries in advance.

The standard for "passing" is simple: convert the design mockup from color to grayscale. If the information hierarchy remains clear, the basics are fine; if it becomes a muddled mess, you need to go back and improve the hierarchy.

Two self-check approaches: scanning by experience vs. checking against a checklist

Two common self-check habits in projects yield very different results.

• Scanning by experience: Fast, suitable for senior designers to judge the overall feel; the downside is it has no boundaries, easily misses abnormal states, and each person's criteria differ.
• Checking against a checklist: Seems less efficient, but it is repeatable; ticking off hierarchy, rhythm, states, details, and consistency one by one is especially suitable for team collaboration and onboarding newcomers. Based on the experience range, a checklist review for a medium-complexity page takes about 15–30 minutes, while a typical revision averages 1–2 hours.

This doesn't mean the checklist is always better. In the exploration phase, scanning by experience allows faster divergence; but when entering the delivery phase, you should check against a list to avoid bringing issues into development.

Applicable scenarios and boundaries

This five-step verification method is suitable for checking completed static interface designs, including web pages, 2C application backends, and mobile interfaces. It is not suitable for verifying smooth interaction flows or natural motion effects, nor for judging whether the "premium feel" at the aesthetic level matches brand identity—that is a matter of taste, not standards.

Specifically:

• Suitable for: unifying style before redesign, new page walkthroughs, self-checks before handing off to development, and team reviews.
• Not suitable for: prototype drafts in user research, because prototypes need to retain a rough feel to encourage feedback; motion demos require checking motion curves, so static verification is not applicable.

If you are working on high-fidelity motion mockups or special display environments like subway large screens, you should establish separate check items for motion and reading distance, rather than applying generic static rules.

Delivery scene: a rework retrospective

Take a corporate backend redesign as an example (anonymized). The budget was tight and the timeline was only two weeks. The client provided icons from two different asset sets with clearly inconsistent styles. We used the five-step verification method to review the interface and found chaotic spacing sequences and buttons lacking disabled states. So we unified the spacing base, completed the missing states, and applied a similar color palette to icons that could not be replaced.

As a result, completing the states avoided large-scale rework in the development phase; however, two icon differences were still requested for revision during final review, costing an extra half day to redraw. The cost shows that "roughly unified" often fails acceptance at delivery; you must confirm in advance the client's minimum acceptable standard for consistency.

Frequently Asked Questions

Where should I check first if an interface isn't refined enough?

Check spacing rhythm first, then states. Messy spacing is the main cause of visual dirtiness, and missing states are a hard flaw that only surfaces after use. Both are more easily overlooked than colors.

Can bad colors also make it look cheap?

Yes, but in most cases hierarchy and spacing fail first. It is recommended to check hierarchy in grayscale first, then adjust hue and saturation; merely adjusting colors tends to cover up the problem, which resurfaces during interaction.

Is the five-step verification method suitable for all interfaces?

It is suitable for static interface checks; 3D, motion, or audio-visual scenarios require additional specialized standards such as motion curves, contrast, and gaze points.

How much detail should a UI design mockup be checked to be considered qualified?

The passing line is: any element at 100% zoom has no blur, no overflow, no misalignment; breakpoints do not break layouts at common resolutions; states cover the usable states of critical paths.

Action guide: If you are facing the feedback that it "doesn't look refined enough," don't adjust colors first. Run your mockup through the five-step verification method; missing states are easy to overlook and often become the focal point of development rework. If you are already in the development phase, consider converting the checklist into an acceptance form, with product, design, and development jointly confirming boundary conditions. If your project involves motion, 3D, or non-standard screens, please add specialized standards separately.