Large Text, Contrast, and Scaling: A Practical Guide to Mobile UI

An emulator and a flagship phone can create a false sense of quality. Many mobile app problems appear only on devices with slower processors, less memory, weaker cameras, or older operating systems.

Why it matters

Users do not experience “low FPS” or “slow cold start” as technical events. They see a freeze, tap twice, or close the app. The Josh case shows how optimizing startup across device classes improved the experience, especially for older and low-end phones.

A minimum test matrix

• One current flagship.
• One mid-range device with a common OS version.
• One affordable device with limited memory.
• Slow connectivity and Wi‑Fi-to-mobile transitions.
• Low battery and background load.

Compare more than launch time. Test scrolling, keyboard opening, image loading, rotation, resume after backgrounding, and behavior under memory pressure. Record the journey in which a defect appears, not only the defect itself.

An affordable device is not a “worse” user. It is a real environment in which the product must keep its promise. Testing there reduces drop-off, negative reviews, and expensive emergency fixes after release.

Source: Android Developers: Josh app startup case study.

A smartphone form competes with a small screen, a virtual keyboard, unstable connectivity, and interruptions. If it asks for more than is needed for the next step, errors and drop-off become predictable outcomes.

Start with the data

For every field, ask why it is needed now, whether the device can provide it, and whether it can be completed later. Split long forms into logical stages, but do not turn a simple action into many screens.

What helps

• Use the right keyboard for email, phone, or address.
• Format input while preserving the stored value.
• Show errors beside the field with a correction path.
• Preserve entered text after a failed request.
• Keep one clear primary action and a correct loading state.

Test on a small screen, with large system text, and after returning from the background. Quality UX on Android includes predictable error behavior, not only the default state.

Measure completion, repeat submissions, errors by field, and time to success. The best improvement is often deleting an unnecessary question rather than adding a new design layer.

Source: Android Developers: App quality and user experience.

Mobile accessibility is not a separate mode for a small group of people. It determines whether text can be read, controls can be tapped, messages can be understood, and a journey can be completed under different conditions.

A basic checklist

• Text and controls have sufficient contrast.
• The UI works with enlarged system text.
• Every interactive element has a meaningful label.
• Functionality does not depend on color alone.
• Focus order matches reading order.
• Errors explain both the issue and the recovery path.

Test with VoiceOver and TalkBack, a keyboard where possible, large text, and bright light. Automated checks find some problems but cannot replace real users and journeys.

Accessibility as product quality

Clear labels, large touch targets, and understandable states help everyone: people with temporary injuries, users on the move, older audiences, and people on weak connections. Android quality guidelines connect a good experience with consistency, adaptability, and usability across devices.

Build accessibility into the design system, components, and Definition of Done instead of leaving it until the end of a release. Problems are cheaper to fix, and the team gets a stable standard for every new screen.

Source: Android Developers: What a great user experience looks like.