UI/UX Non-Negotiables
for Web Applications

Pain point: Users cannot tell where to start, where they are, or where to find a feature.

Required standard: Give every screen a clear purpose. Organise navigation around users' goals, use familiar labels, show the active location, and make important destinations easy to find. Keep information architecture shallow.

Pain point: Simple tasks take too many clicks, ask for repeated information, or force irrelevant decisions.

Required standard: Map the main tasks from start to finish. Remove redundant steps, reuse known information, set sensible defaults, and reveal advanced options only when needed. Optimise frequent journeys first.

Pain point: A click produces no visible response, or users cannot tell whether work is pending, complete, or failed.

Required standard: Explicitly design the relevant idle, loading, success, error, empty, disabled, pending, and offline states. Use progress indicators when useful and make outcomes persistent when users navigate away.

Pain point: Users make avoidable mistakes, lose input, or cannot recover from failures.

Required standard: Validate fields at useful moments, explain constraints, preserve valid input, and provide corrective guidance. Add confirmations for consequential actions; support undo or cancellation where practical. Never rely on generic error banners alone.

Pain point: Everything competes for attention, obscuring the screen's purpose and next action.

Required standard: Use consistent typography, spacing, contrast, alignment, grouping, and restrained colour to show importance. Make the primary action distinguishable and eliminate decorative clutter that competes with task completion.

Pain point: Controls look or behave differently between screens, forcing users to relearn patterns.

Required standard: Create a shared design system for colour and spacing tokens, typography, buttons, inputs, tables, dialogs, icons, alerts, focus states, and responsive behavior. Reuse components and document exceptions.

Pain point: Desktop layouts are merely compressed on smaller screens, causing horizontal overflow and un-tappable controls.

Required standard: Design for available space and input method. Reflow content, adapt navigation, keep key actions reachable, and make complex tables or dialogs usable on supported devices. Test on real viewport sizes, not just browser resize previews.

Pain point: Low contrast, missing labels, keyboard traps, or inaccessible custom controls prevent users from operating the app.

Required standard: Use WCAG 2.2 Level AA as a practical baseline. Provide semantic HTML structure, meaningful labels, visible focus rings, keyboard-operable controls, sufficient contrast (4.5:1 minimum), understandable errors, and text alternatives. Never rely on colour alone.

Pain point: The app is slow, content shifts unpredictably while loading, or becomes unresponsive during interactions.

Required standard: Optimise images, fonts, JavaScript, API payloads, and rendering. Target LCP ≤ 2.5s, INP ≤ 200ms, and CLS ≤ 0.1 at the 75th percentile. Use skeleton loaders or progress feedback where they help rather than disguise long waits.

Pain point: Form labels, instructions, requirements, or consequences are vague or written in internal company jargon.

Required standard: Use plain language and descriptive action buttons ("Confirm Transfer of ₦25,000" instead of "OK"). Mark required fields clearly, ask only for essential data, associate errors with fields, and assign appropriate mobile virtual keyboard types (email, numeric, tel).

Pain point: Users cannot tell whether financial data is safe, an action is reversible, or a displayed status is actually confirmed.

Required standard: Communicate transaction fees, terms, permissions, and status with complete honesty. Minimise sensitive data exposure (mask card PANs). For consequential actions, show the essential facts before commitment.

Pain point: The product works for the engineers who built it, but breaks down for unfamiliar end users.

Required standard: Test realistic tasks with representative users. Observe hesitation, wrong turns, errors, and drop-off points. Combine quantitative analytics with qualitative user feedback to diagnose friction causes.