Human Interface Guidelines
A human interface guideline (HIG) is a software-development document that gives application developers recommendations for building interfaces that are intuitive, learnable, and consistent with the rest of a platform. Most HIGs limit their scope to establishing a common look and feel for a particular desktop environment, operating system, or mobile platform, rather than for interfaces in general.
A human interface guideline (HIG) is a software-development document that gives application developers recommendations for building interfaces that are intuitive, learnable, and consistent with the rest of a platform.
Background
A HIG’s central aim is a consistent experience across an entire environment — the same visual design, and the same behavior of common elements — applied across every application built for that platform, the platform-scale version of the consistency discipline Interface Design Principles argues for within a single product (“be consistent throughout”). HIGs are recommendations, not mandates — a developer can deliberately break from a guideline where it doesn’t fit their application — but non-compliance still carries a cost: the publishing organization can withhold its endorsement from non-compliant applications, as when the GNOME project cited Firefox’s departure from the GNOME Human Interface Guidelines as one of its main reasons for shipping GNOME Web (Epiphany) instead by default.
HIGs are recommendations, not mandates — a developer can deliberately break from a guideline where it doesn’t fit their application.
Problem
Without a shared reference, independent developers building for the same platform converge on inconsistent conventions for the same interface elements — buttons, icons, dialogs, navigation — each team re-deriving its own answer. The result is a platform where every application looks and behaves slightly differently, raising the learning cost of every new application a customer tries.
The result is a platform where every application looks and behaves slightly differently, raising the learning cost of every new application a customer tries.
Solution
A platform owner — an OS vendor, a desktop-environment project, a company — publishes a HIG: a document enumerating specific policies for visual design (icon and window design/style, most commonly, including platform-specific color conventions like light/dark/increased-contrast mode support), and less frequently for interaction mechanics (how input and navigation should work) and for broader organizational or textual conventions (how to structure an application, how to write its interface text). Some of these policies trace back to usability research on human-computer interaction, but most simply reflect the platform developers’ own design preferences, formalized into a shared reference.
Weigh platform-native fit against cross-platform implementation effort
Some guidelines aren’t tied to any one platform, and instead recommend conventions meant to hold true everywhere. Since full platform-native compliance isn’t always possible for a cross-platform application, these guidelines have to weigh the payoff of matching each platform’s own conventions against the implementation effort that requires.
Examples across platforms
HIGs exist for most major desktop and mobile platforms. On Linux, macOS, and other Unix-like systems: the GNOME, KDE, Elementary OS, Xfce, and Ubuntu app-design guidelines, and Apple’s own Human Interface Guidelines (predating Google’s Material Design as an OS-level design language, and distinct from the Material Design accessibility guidance already covered in Accessibility (Material Design)). On mobile and portable devices: Android Design, and Apple’s separate iOS, iPadOS, and watchOS guidelines. On Microsoft Windows: a lineage running from 1992’s Windows Interface Design Guide through the Windows XP and Windows 7-era interaction guidelines to the current Microsoft Fluent Design System. Older and more specialized examples include IBM’s Common User Access (OS/2 and early Windows), the Java Look and Feel Design Guidelines, and the Eclipse UI Guidelines.
A design system serves this same consistency goal at a narrower scope — a single organization’s own family of products rather than an entire platform; GOV.UK Design System and Carbon Design System: Accessibility, Content, Color, Motion, and Spacing Guidelines (IBM) are both real instances of that narrower genre.
Related Concepts
Principles
Processes
Standards
Further reading
Apple’s Human Interface Guidelines — Color (developer.apple.com/design/human-interface-guidelines/color — Apple Inc. copyright, no open license) demonstrates how granular a real platform HIG document gets beneath the cross-platform generalities above. It sets concrete rules — keep a color’s meaning consistent, supply light/dark/increased-contrast variants for every custom color, and use the platform’s own semantic color APIs rather than hard-coded values — of the kind Color Theory and Design Tokens cover in more general terms.
Sources
Human Interface Guidelines (Wikipedia) (CC BY-SA 4.0) is this page’s primary source — the HIG definition, the platform-vs-cross-platform distinction, the recommendations-not-mandates framing, the GNOME/Firefox endorsement-withholding example, and the catalog of platform-specific examples under “Examples across platforms.”
Material Design (Wikipedia) (CC BY-SA 4.0) supplies the note, in that same section, that Apple’s own HIG predates Material Design as an OS-level design language.
Accessibility (Material Design) documents Material Design’s own accessibility guidance, a distinct topic from the platform-consistency scope this page covers.
GOV.UK Design System and Carbon Design System: Accessibility, Content, Color, Motion, and Spacing Guidelines (IBM) supply the government-service and software-company examples of the narrower design system genre named under “Cross-platform guidelines” above.