Human Interface Guidelines: How to Use Them Across Your Mobile App Design Process

Human interface guidelines define how apps should look, behave, and interact with users across platforms. Apple’s Human Interface Guidelines, Google’s Material Design, and Microsoft’s Fluent cover layout, typography, accessibility, and interaction patterns.

Platform guidance helps teams build familiar, accessible experiences. Store review requirements are separate: an app can face review issues for substandard UI or insufficient functionality, but a visual deviation from the HIG does not automatically mean rejection. Use both design guidance and the applicable review requirements throughout the workflow.

This guide explains why these guidelines matter, how to apply them throughout the design process, and what founders and product leaders should expect from app design timelines, deliverables, and design partners.

Human interface guidelines describe platform-specific recommendations for how software presents content and behaves. Apple also uses Human Interface Guidelines as the proper name of its design documentation. Other ecosystems publish their own guidance or broader design systems.

The major published resources include the following. Their scope differs: some are guidelines, while others also provide component libraries, tools and design systems.

Start with Apple’s Human Interface Guidelines, Google’s Material Design and Microsoft’s Fluent 2.

Desktop-specific references include the GNOME HIG and KDE HIG.

Apple’s HIG organizes its guidance into these broad categories:

• Foundations — accessibility, layout, typography, color, icons, materials, motion, writing. The rules that apply to everything.
• Patterns — onboarding, search, feedback, loading, settings, notifications, data entry. How common jobs should be handled.
• Components — buttons, tab bars, navigation bars, sheets, pickers, alerts. The actual building blocks.
• Inputs — touch, keyboard, pointer, Digital Crown, gyroscope, voice.
• Technologies — Apple Pay, Sign in with Apple, widgets, Live Activities, App Clips, HealthKit.

What they are not

Three clarifications save a lot of wasted argument in design reviews.

Platform guidance and your product design system are related, but not identical. Apple’s HIG provides recommendations; Material Design and Fluent also include system-level components and resources. Your product system adds brand tokens, reusable components, behavior documentation and implementation decisions for your own app.

Usability principles are broader reasoning tools. Platform guidance adds specific conventions and implementation expectations. Use both: reason about why an interaction is difficult, then consider the patterns available on the platform you support.

They are not permanent. Apple introduced a substantially new visual language across its platforms at WWDC 2025, and Google has refreshed Material more than once. Any team treating the guidelines as a document they read once has already drifted. Always design against the current published documentation for the OS version you are targeting, not against a screenshot from two years ago.

For the 2025 example, see Apple’s introduction to Liquid Glass at WWDC25. Consult the current HIG for your supported versions.

The three layers to keep separate

Thinking in layers prevents the most common strategic mistake treating brand and platform as competitors.

• Platform layer — expected navigation behavior, system gestures, safe areas, accessibility scaling and permission experiences.
• Brand layer — color, typography, writing voice, illustration, tone, motion personality and icon style.
• Product layer — your unique flows, data models, and screens that no guideline anticipates.

Keep your brand expressive while respecting the behaviors users rely on. Document and test deliberate exceptions.

Guidelines affect learnability, implementation choices, accessibility and release readiness. Treat these as practical product considerations rather than promises of a particular commercial return.

Store review is a separate gate. Apple’s App Review Guidelines include a design section and minimum functionality requirements, and its review guidance flags substandard user interfaces. Check those requirements before submission; HIG alignment alone does not guarantee approval.

Review Apple’s App Review Guidelines and its common review issues.

Familiar patterns can reduce the amount users need to learn. Standard navigation and dismissal behavior provide a starting point, while unfamiliar custom patterns may need more explanation and testing. Exact behavior depends on the component, platform and context.

Accessibility expands who can use your app. Review contrast, text scaling, meaningful labels, focus order and motion settings from the beginning. Test the implementation with assistive technologies and larger text; checking the visual design alone is not enough.

Use Apple’s accessibility design guidance and Android’s app accessibility guidance for the platform you are building on.

System components can reduce custom implementation and provide useful accessibility and localization behavior. They still require correct configuration and testing in your app. Replacing them creates additional code and behavior your team must maintain.

Trust is formed before evaluation. Users make fast judgments about whether an app feels legitimate. Mismatched iconography, inconsistent spacing, and controls that behave unexpectedly read as carelessness, and users generalize carelessness in the interface to carelessness with their money or data.

Here is the app design workflow we would recommend to any team building a serious product, with the guideline checkpoint that belongs at each stage. The value is not in the stage names most teams already know them but in the checkpoints, which are what actually prevent late-stage rework.

The seven app design process steps

Step 1 — Discovery and definition. Clarify the job the product does, who does it, and what success looks like. Audit competitors on the platform, not in a spreadsheet install them, use them, note which platform conventions they follow and where they break. Guideline checkpoint: decide your target OS versions and device range now. This determines which components and APIs are available to you and constrains everything downstream.

Step 2 — Information architecture and user flows. Map the content model and the primary journeys before drawing a single screen. Decide your top-level navigation structure tabs versus a hierarchy versus a single focused surface. Guideline checkpoint: choose a navigation model the platform supports natively. This is the single most consequential decision in the entire process, and the most expensive to reverse.

Step 3 — Wireframes. Low-fidelity structure: what is on each screen, in what priority, and what happens when you tap it. Resist styling. Wireframes exist to argue about hierarchy and flow while arguing is still cheap. Guideline checkpoint: wireframe on real device dimensions with safe areas marked, and include the empty, loading, and error state of every screen, not just the happy path.

Step 4 — Visual design and UI. Apply the brand layer. Build a type scale, color system, spacing scale, iconography, and elevation model, then compose real screens from them. Guideline checkpoint: validate contrast ratios, minimum tap targets, and dynamic type behavior as you design rather than after. Confirm your color system survives both light and dark appearance.

Step 5 — Prototyping and validation. Turn static screens into something a real person can attempt to use. Test with users who match your audience. Guideline checkpoint: test on the device, in the hand, not in a browser window on a laptop.

Step 6 — Handoff and design system documentation. Deliver specifications, components, tokens, and behavior notes that an engineer can build from without guessing. Guideline checkpoint: document which elements are native components and which are custom, and justify every custom one.

Step 7 — Build support, design QA, and launch. Design does not end at handoff. Review builds on real hardware, catch drift, and refine. Guideline checkpoint: run a pre-submission review against store design requirements, accessibility settings, and every device size you claim to support.

Stage-by-stage summary

For the broader workflow, see our step-by-step mobile app design guide.

Timelines are where expectations break. The ranges below are planning heuristics for the design track specifically not engineering, and not research-backed benchmarks. Treat them as a way to structure a conversation with a design partner, then let scope adjust them.

What actually drives the number

Estimate states as well as screens. Loading, empty, error, offline, permission-denied and success conditions add design and implementation work. Scope, research, review cadence and engineering constraints also affect duration.

Other genuine drivers:

• Number of platforms. A second platform is not a second project, but it is not free either. Navigation, back behavior, system components, and typography all differ.
• Decision latency. Clear ownership and scheduled reviews help teams resolve decisions without unnecessary waiting.
• Research depth. Recruitment, usability testing and analysis add time; include them explicitly in the plan.
• Brand maturity. If foundational brand work does not exist, the design process either absorbs it or proceeds on sand.
• Content readiness. Real copy, real data, real imagery. Placeholder content hides layout failures until it is too late to fix them cheaply.

A sensible phasing model

Here is an illustrative 12-week phasing model for a scoped design engagement. It is not a launch guarantee, and engineering can extend beyond it:

• Weeks 1–2: Discovery, IA, navigation decision locked.
• Weeks 2–4: Wireframes for the primary flow, including all states.
• Weeks 4–6: Visual foundations and two or three key screens designed to final quality.
• Weeks 6–10: Screen production across remaining flows, prototype built in parallel.
• Weeks 10–12: Testing, refinement, handoff documentation.
• Ongoing: Design QA during build, pre-submission review before launch.

Resolve navigation decisions early enough to test them before engineering commits to the structure. Revisit them when user evidence shows the model is not working.

A prototype is not a deliverable you make because it looks impressive on a board deck. It is an instrument for reducing the cost of being wrong. The mobile app prototyping process works best when fidelity is matched deliberately to the question being asked.

The fidelity ladder

Match prototype fidelity to the question. Structure and comprehension can often be tested with a simple prototype, while gestures, visual feedback and technical behavior may require a more realistic or coded version.

What to test, specifically

Vague testing produces vague findings. Give each session concrete tasks and watch behavior, not opinions.

• First-run comprehension. Hand over the device with no explanation. Can they state what the app does within a few seconds?
• Primary task completion. Can they do the one thing the product exists for, unaided?
• Navigation recovery. After going three levels deep, can they get back to where they started?
• Gesture conflicts. Does any custom gesture fight the system's back swipe, notification pull, or control center?
• Failure states. Break something deliberately. Do users understand what happened and what to do next?
• Accessibility conditions. Run with the largest dynamic type setting, with a screen reader, with reduce-motion enabled.

Test on the device

Prototypes reviewed on a desktop monitor systematically flatter themselves. Thumb reach, one-handed use, glare, notification interruptions, and the actual physical size of a tap target only reveal themselves on hardware. Every prototype that will ship to phones should be tested on phones — including at least one small screen and one large one.

A prototyping rhythm that works

Use iterative qualitative rounds where practical: test important tasks, analyze observations, revise the prototype and test again. Choose recruitment and sample size for the question and relevant user groups. A small round is a way to learn, not a guarantee of complete issue coverage.

If you are commissioning design work, this section is your checklist. The single most common cause of disappointment is not poor design ability it is an undefined deliverable list, where both sides assumed different things were included.

The deliverables list

How to evaluate design work as a non-designer

You do not need craft expertise to assess quality. You need the right questions.

Ask to see the states. Request the error state, the empty state, and the loading state of the main screen. A portfolio of perfect happy-path screens with full data is a portfolio of screenshots, not a product design. This one question separates decorative work from production work faster than any other.

Ask why each custom component exists. Every deviation from a native component should have a stated reason. "It looked better" is not a reason. "The native picker cannot support our two-axis selection, so we built a custom control that preserves the same gestures and accessibility labels" is.

Ask what happens at the largest text size. If the answer involves hesitation, accessibility was not designed in.

Ask to see it on a device. Not a mockup image on a laptop. The actual prototype, on actual hardware, in your hand.

Ask how the design will be maintained. A design that cannot be extended by your team after the engagement ends is a liability with a nice cover.

Look at process artifacts, not just outcomes. Ask to see wireframes, iteration history, and test findings from a past project. Teams with genuine depth have messy middles they are proud of. Teams selling visuals have only finals.

Review Wolfpixel’s product design portfolio and ask about the research, states and implementation decisions behind each project.

At some point every team decides whether to build design capability internally, hire an agency or studio, or run a hybrid. There is no universally correct answer, but there are predictable trade-offs.

Engagement models compared

What actually drives investment

Rather than fixating on a headline figure, understand the levers, because these are what you can negotiate.

• Number of unique screens and, more importantly, states.
• Number of platforms and form factors.
• Whether brand foundations already exist. Naming, logo, voice, and visual identity work is a separate discipline; if it does not exist, someone will do it, formally or informally.
• Depth of research included. Moderated testing costs real time and removes real risk.
• Whether a documented design system is in scope. Screens are cheaper than systems, but systems are what make the next twenty screens cheap.
• Length of build-phase support. Design QA during engineering is the most frequently cut and most frequently regretted line item.

Framing the return honestly

Avoid the temptation to justify design spend with borrowed statistics. The defensible argument is more concrete and easier to hold up in a board meeting:

• Less custom control code to implement and maintain, with testing still required in the product.
• Release-readiness issues identified before submission, without a guarantee of store approval.
• Accessibility built rather than retrofitted, avoiding component-level rework.
• Interface confusion measured through user research and support data.
• Reusable components and documented decisions that can reduce duplicated design work.

A maintained design system makes it easier to reuse decisions across features. Its value depends on adoption, coverage and ongoing maintenance rather than a guaranteed delivery-speed increase.

When to bring design in

Bring design into the navigation and information-architecture discussion before implementation hardens the structure. Later design work can still improve a product, but structural changes may become more costly.

Explore our mobile app design services, read our UI/UX design cost guide, or discuss your app design scope.

These are the failure patterns that recur most often. Most are cheap to avoid at the start and expensive to correct later.

Mistake 1 — Designing one app and shipping it to two platforms

A single visual design pushed unchanged to iOS and Android breaks conventions on at least one of them. Back behavior, navigation placement, system typography, share sheets, date pickers, and permission dialogs all differ. Share your brand, your content model, and your flows across platforms. Adapt the platform layer.

Mistake 2 — Treating brand and platform as a zero-sum fight

The instruction "make it look nothing like a standard app" almost always produces a product that is harder to use and no more memorable. Distinctiveness lives in color, typography, illustration, copy voice, and motion personality — all of which are fully available to you inside platform alignment. Distinctiveness does not live in relocating the back button.

Mistake 3 — Designing only the happy path

The most common gap in design handoffs. Real users have no network, empty accounts, expired sessions, denied permissions, and failed payments. If those states are not designed, engineering will invent them under deadline pressure, and they will be the states your least happy users see most often.

Mistake 4 — Copying visual output without reading the reasoning

Guidelines explain why a pattern exists. Teams that copy a competitor's screens inherit the appearance without the logic, and then cannot reason about edge cases the screenshot never showed. Read the foundations sections. They are shorter than they look and they pay for themselves.

Mistake 5 — Deferring accessibility to a post-launch phase

Accessibility decisions belong in the workflow. Contrast, text scaling, focus order, target areas and screen reader labels can require structural changes, so review them before and during implementation.

Mistake 6 — Skipping design QA during the build

Designs drift during implementation — not from carelessness, but from a thousand small judgment calls no specification anticipated. Without a designer reviewing real builds on real devices, the shipped product is a rough approximation of the approved design, and nobody notices until a user does.

Mistake 7 — Designing against outdated documentation

Guidelines change with OS releases. Design against the current published documentation for the version you are targeting, and schedule a guideline review after each major platform announcement.

Mistake 8 — Custom components without a stated justification

A custom control adds implementation, maintenance and accessibility work. System controls can evolve with platform updates, but their behavior in your app still needs review. Keep a record of each custom control and its reason, and reconsider it when a suitable platform option becomes available.

The underlying risk

Nearly all of these share one root cause: platform alignment treated as a review event rather than a process property. Something checked once, late, by one person. The fix is structural — checkpoints inside each stage of the app design workflow, as set out in Section 3, so that no single review carries the weight of the whole product.