UI design looks fine on screen but falls apart on real devices—what should you check?

It's not just bad luck when your UI design looks fine on screen but breaks on a real device. Usually, variables like canvas size, safe areas, system fonts, and color modes haven't been cross-checked before finalizing the design. Following typical 2026 project delivery practices, focus on five areas: layout spacing, typography hierarchy, color contrast, touch targets, and annotation completeness. This covers most causes of rework.

Why does UI design need a "pre-device check"?

The canvas in design software is an idealized state. Real devices have notches, bottom navigation bars, status bars, and system font rendering differences. Many designs look neat on a computer but get cropped or washed out on a device, often because edge cases weren't considered during the design phase.

It's common in projects to only provide the ideal empty state, leaving loading and offline states undefined. Developers then make ad-hoc decisions that conflict with the visual intent, leading to rework. Following typical 2026 delivery practices, creating a "pre-device check" list saves more time than fixing issues later.

• Myth 1: Focusing only on the overall look while ignoring local margins and control sizes.
• Myth 2: Assuming developers will adjust safe areas and font compatibility on their own; in reality, they prefer to implement exactly as designed.
• Myth 3: Treating annotation as optional rather than a deliverable.

Four-step self-check: verify layer by layer from layout to interaction

Why four steps? Because moving from layout to typography, color, and state covers four layers: visual structure, information hierarchy, readability, and operability. Checking in this order prevents you from getting lost in details.

1. Layout and spacing: Check whether all pages follow a consistent spacing base. A common base is 8px (8, 16, 24, 32), or 4px per platform guidelines. Mixed spacing values within a screen create visual chaos.
2. Typography and hierarchy: Ensure headings, body text, and auxiliary text form a clear scale. Typical type sizes range from 14px, 16px, 20px, to 24px, with weight differentiation. Ensure the minimum size is readable on target devices.
3. Color and contrast: Check contrast between foreground and background. Per common readability standards, body text should have a contrast ratio of at least 4.5:1; large text can be slightly relaxed. In dark mode, also verify that bright text isn't too glaring.
4. States and touch: Check that buttons and links have hover, pressed, disabled, and loading states; touch targets should be at least 44×44pt or 48×48px. If you only design the normal state, interactions will reveal gaps.

What should you pay attention to in each step? For layout, align to the grid. For typography, focus on hierarchy contrast rather than mere size. For color, note the difference between white and dark backgrounds. For states, ensure icons and text remain distinguishable in disabled states. In tight-budget, short-cycle projects, we used to only annotate key pages, only to have developers repeatedly ask how to handle undefined empty states, slowing progress. Later, we developed the habit of at least providing loading, empty, and error state mockups even when time is tight. That's the value of the four-step check: the fixed sequence forces the team to surface unknown issues early.

Which details tend to fail on real devices?

Even after passing all four steps, some details that "look fine" still tend to cause problems on real devices. Here are the common issues based on 2026 common devices, along with standard workarounds.

• Bottom safe area: iPhone's Home Indicator can overlap buttons or tab labels. Add extra safe spacing and extend the background behind it.
• System font differences: Android and iOS use different fonts, causing subtle line-height variations. Using platform default fonts with fixed line heights helps mitigate this.
• Color gamut: The same color may appear differently on wide-gamut versus standard displays. Specify the color mode in deliverables and verify key swatches on real devices.
• Shadows and frosted glass: Low-end devices may lag with complex blur effects. Provide fallback options, such as using semi-transparent color blocks instead of heavy frosted glass.
• Asset naming: If assets are named in Chinese or with garbled characters, it affects implementation efficiency. Use a naming convention like "module_state_size" to reduce communication overhead.

What kind of design specifications are worth your time?

Thicker specifications aren't necessarily better. A common practice in 2026 is to start with a minimal usable specification, then decide whether to expand based on project complexity and iteration frequency.

• Full design specification: Suitable for admin systems, multi-platform products, and long-term iterative projects. It includes colors, fonts, spacing, components, and state templates. Initial investment is typically a few person-days, but future changes are easier to unify.
• Lean design specification: Suitable for small campaign pages and short-lived products. Define only three core variables—color, type size, and spacing—can be completed in half a day, and solves most collaboration issues.

In projects, teams often spend a lot of time creating dozens of pages of specifications, but with rapid iteration, the specs quickly become outdated. Switching to "fixed core variables + supplement details as needed" proved more practical. Start with a lean spec, and add recurring components back into it to keep the document alive.

Applicable scenarios and boundaries

The four-step check and lean specifications suit projects that require real-device testing, developer collaboration, and ongoing iteration. For such projects, investing in one round of checks and half a day of spec work reduces back-and-forth communication.

On the other hand, if your pages are purely presentational, one-off campaign pages, or generated from templates, you don't need to apply this approach.

• Appropriate for: Interfaces present on both mobile and desktop that need consistent experiences.
• Appropriate for: Scenarios involving multiple designers collaborating or handovers to new team members.
• Appropriate for: App interfaces that need regular acceptance reviews with the development team.
• Not appropriate for: One-off marketing pages that can be quickly built from templates.
• Not appropriate for: Static display pages with minimal interaction requirements.
• Not appropriate for: Temporary projects with no subsequent iterations; don't waste effort on specs.

If your project has only three to five pages that won't change for three months, you can deliver without specs. If you have more than twenty screens with ongoing updates, skipping specs will significantly raise maintenance costs later. Use this boundary to decide whether to invest in self-checks and specification documentation.

Frequently asked questions

What should be checked first before going to a real device?

Start with layout spacing, because it determines overall stability and information hierarchy. Once spacing is off, no amount of typography or color adjustment will make it feel right.

Design looks different on real device—what's the cause?

Usually, the color mode isn't consistent, or colors aren't calibrated on a real device. Check primary colors against common P3 vs. sRGB differences, then adjust brightness.

What's the minimum touch target size?

The typical experience range is 44×44pt to 48×48px, depending on platform guidelines. Below this, the mis-tap rate increases in dense pages.

Do small projects need design specifications?

If you have fewer than ten screens and no long-term iteration, a single page listing colors, type sizes, and spacing is enough. Conversely, if you have more than twenty screens or ongoing iteration, a full specification is recommended.

Action guide: Run your current design through the four-step check, prioritizing empty states, loading states, and button pressed states. If the schedule is tight, at least ensure spacing, type size, and color are consistent. This approach suits standard app interfaces. For immersive game UIs or data visualization dashboards, consider dynamic scenarios and specialized interactions—don't force it.