Human-Interface Design Best Practices

Interface design最容易掉进两个坑。

One pitfall is treating design as “making things look good”; the other is treating design as “assembling components according to platform guidelines.” The former produces beautiful but unusable products; the latter produces interfaces that feel like compliance checkboxes.

In real products, interface design isn’t a style competition—it’s about guiding users to correct outcomes under time constraints, complex conditions, and incomplete information. It concerns vision and flow; aesthetics and cost, error rates, learning curves, and maintainability.

Apple HIG and Material Design are worth studying, but if your team only learns button corner radii and shadow levels, you’ve basically learned nothing. What matters more are the judgments behind them: what should be emphasized, what should be deprioritized, where explanation is necessary, where flashiness should be avoided.

This article doesn’t reprint platform guidelines—it focuses on cross-platform, actionable human-interface design principles for product managers, designers, and frontend engineers who actually ship.

1. Interfaces Aren’t Canvases, They’re Decision Sequences

When users see an interface, they’re not “appreciating design”—they’re making rapid micro-decisions:

• Where am I?
• What can I do now?
• What’s most important?
• What happens after I click?
• Can I get back if something goes wrong?

So the core task of interface design isn’t filling space with visual elements—it’s arranging decision sequence.

If a page highlights five areas simultaneously, three buttons all look like primary actions, explanatory text competes with action links, users aren’t “having more choices”—they’re forced to do information cleanup themselves.

Good design makes users feel smooth; bad design makes users feel tired without being able to articulate why.

2. Information Hierarchy First, Visual Details Second

Most page problems aren’t wrong colors—they’re wrong hierarchy.

Information hierarchy answers three questions:

1. What’s the most important goal of this page?
2. What will users look at first, second?
3. What must be understood immediately, what can appear later?

Common Mistakes

Multiple “protagonists” on one screen Homepage wants to push new features, drive conversions, warn about risks, and tell brand stories—all at once. Result: everyone fights for center stage, nobody matters.

Translating “everything’s important” into “everything’s big” Big titles, big cards, big buttons, big numbers, big badges. Visually bustling, cognitively congested.

Explanations and decisions at the same level Like a payment page showing plan details, terminology explanations, promotion rules, comparison tables, FAQ, and customer service contact—all competing with the actual action users should take.

More Practical Approach

Design page content priority first, don’t start with component library layouts.

You can roughly divide page content into four layers:

• Primary task: What users most likely came to accomplish
• Key supporting info: Helps users make decisions about the primary task
• Secondary info: Important for some users but not first-glance critical
• Edge info: Can appear later if at all

Once hierarchy is clear, visual design becomes much easier. Much of what people call “design sense” comes from tradeoffs, not detail堆积.

3. Visual Rhythm Determines Readability

Interfaces aren’t static posters—they’re continuous reading experiences. When visual rhythm breaks down, users feel an indescribable frustration: they can see, but can’t read through; can tap, but don’t want to.

Visual rhythm mainly involves:

• Consistent spacing
• Stable alignment
• Similar elements actually looking similar
• Restrained emphasis appearance
• Page density matching the scenario

When Pages Feel “Out of Breath”

• Card spacing varies wildly
• Title and body line height chaotic
• Every area has borders, shadows, background colors
• List items packed with icons, tags, badges, buttons
• Components themselves aren’t complex, but the page fights for attention everywhere

This kind of interface commonly appears in products that “look complete in design drafts, exhausting to use.”

Rhythm’s Essence Isn’t White Space—It’s Order

This doesn’t mean pages must be empty. Trading desks, data dashboards, monitoring systems are naturally information-dense. The problem isn’t “dense”—it’s “chaotic.”

Dense interfaces especially need:

• Grouping and headers to establish block structure
• Primary/secondary relationships through position and contrast, not making everything bold
• Controlling visual noise at each layer
• Letting users glance and immediately know which areas belong together

A mature page might not be stunning, but users definitely won’t get lost.

4. Affordance: Can Users Immediately See “What This Does”?

Affordance sounds academic but is actually very straightforward: can users infer how to interact from the interface itself?

Buttons look like buttons, input fields look like inputs, drag regions look draggable, list items look expandable—these aren’t clichés, they’re basics for reducing learning costs.

Many Interfaces’ Problem: “Deliberately Sophisticated”

In pursuit of所谓的 simplicity, boundaries get flattened, buttons look like tags, clickable areas look like explanatory text, modal entrances hidden in barely-visible icons. Designers call it restraint; users call it “afraid to tap anything.”

Practical Affordance Criteria

If an element carries an action, it should satisfy at least several of:

• Position matches expectations
• Shape or style implies interactivity
• hover/focus/pressed states provide feedback
• Copy is action, not riddle
• Touch target large enough
• Clearly distinguishable from pure display info

Especially in enterprise products, complex forms, admin systems—don’t build “design sense” at the expense of affordance. Users aren’t here to solve puzzles.

5. Feedback and System Status: Trust Foundation, Not Garnish

What users fear most isn’t waiting—it’s not knowing what the system’s doing.

You tap save, nothing happens; you submit a form, unsure if it succeeded; you delete content, the list just flickers; you trigger an async task, unsure how long until completion. Systems like this make users repeatedly tap,怀疑 data loss, question reliability.

Systems Should Clarify at Least Three Things

1. I received your action Button state changes, loading indicators, skeleton screens, progress bars—all tell users “don’t repeat tap, I’m processing.”

2. What step am I at now Especially for time-consuming tasks like upload, import, payment, publish, training, sync—give status, not just spinners.

3. What was the result Distinguish success, failure, partial success, pending retry, needs manual intervention. Don’t dump all outcomes into one toast.

Two Common Feedback Misconceptions

Misconception 1: Toast everything Toast suits lightweight notifications, not critical results. Payment failures, insufficient permissions, partial import failures, sensitive action confirmations—all deserve more than a flash.

Misconception 2: Loading looks busy but has no info Spinners aren’t feedback themselves, just placeholders. Over several seconds, better explain what’s being processed, estimated time, whether users can leave the page.

Good feedback makes users trust the system; bad feedback undermines even the prettiest visuals.

6. Error Design’s Focus: Not Error Messages, But Avoiding Dead Ends

The worst error experience isn’t popping “an error occurred”—it’s making users re-do several minutes of input because one field was wrong.

Error handling has at least three layers:

Layer 1: Prevent Errors

Don’t educate users after errors if you can prevent them:

• Use selectors over free-form input
• Show format examples
• Validate before submission
• Require confirmation for dangerous actions
• Stronger warnings for irreversible actions
• Use defaults to reduce configuration cost

Preventing errors matters more than writing a hundred error messages.

Layer 2: Speak Human When Errors Happen

“Invalid parameter,” “submission failed,” “system exception”—none of these help users. Error messages should answer:

• What went wrong
• Why it went wrong
• How to fix it now
• Whether they can continue

Examples:

• Bad: Invalid phone number format

• Better: Please enter an 11-digit mainland phone number without spaces or dashes

• Bad: Insufficient permissions

• Better: You don’t have permission to delete this project. Contact your project administrator to grant “project deletion” access.

Layer 3: Allow Recovery

What users need isn’t an apology—it’s a recovery path.

Common recovery approaches:

• Preserve entered content
• Support undo
• Provide retry
• Auto-save drafts
• Mark failed items and allow fixing just those
• Enable returning to previous steps

If systems kick users back to start on error, that’s not “strict”—it’s lazy.

7. Empty States and Loading States Expose Basic Competence

Many teams only seriously design interfaces with lots of data, ignoring two more common moments: when there’s no data, and when data hasn’t loaded yet.

Empty States Aren’t for Cuteness

Empty state core mission: explain the current situation and provide next actions.

Common empty states:

• New user first visit, hasn’t created anything yet
• No results under current filter conditions
• Search no matches
• Permission insufficient to see data
• Temporarily unable to load due to exception

These scenarios can’t share one “nothing here” illustration. Users’ required actions are completely different.

Good empty states typically explain:

• Why it’s currently empty
• Whether this is normal or an issue
• What the next step should be
• Whether there are recommended actions

Don’t Be Lazy With Loading States Either

Skeleton screens suit content with expected layouts: lists, card streams, article details.

Spinners suit short waits, unpredictable layouts, or indeterminate results.

Progress bars suit longer, quantifiable processes.

Most dreaded: situations needing seconds or tens of seconds with neither skeleton, nor progress, nor explanation. Users can only怀疑 the page crashed.

8. Input Experience Determines Whether Products Feel “Tedious”

Many products’ problems aren’t missing features—it’s excessive input cost.

Input experience is underestimated because design reviews see static mockups; real pain points only surface when users fill field by field.

At Minimum, Check These for Input Flow Design

1. Can you reduce input? Don’t let users fill what can be inferred, don’t ask repeatedly what can be remembered, don’t force typing when selection works.

2. Does input sequence match human thinking? Don’t arrange fields according to database structure. Interface sequence should match users’ mental model for completing tasks.

3. Do keyboard, mouse, and touchscreen all work smoothly? Desktop suits batch editing, shortcuts, Tab flow; mobile considers one-handed operation, keyboard coverage, control size, input type switching.

4. Is real-time validation restrained? Seeing red while still typing feels terrible. Validation should help without interrupting input whenever possible.

5. Does it support resuming after interruption? Complex forms, tickets, publishing flows, configuration pages—without draft and recovery support, abandonment rates directly increase.

Mobile Especially Prone to Problems

• Touch targets too small
• Primary actions squeezed by system gesture areas
• Main action invisible after keyboard pops up
• Long copy causes wrapping occlusion
• Date, time, location pickers unsuitable for one-handed operation

When designing input interfaces, don’t just look in Figma—fill out a form on actual phone.

9. Accessibility Isn’t Just “Compliance”—It’s Basic Usability

Many hear accessibility and think it’s a special feature for minorities. Actually, many accessibility basics directly improve everyone’s experience.

Minimum Bottom Lines

Sufficient contrast Light gray text on white backgrounds, indistinguishable disabled vs normal states—very common problems. Looks light, actually exhausting to read.

Readable font size and line height Body text too small, line height too tight, mobile long-form text without hierarchy—all reading resistance.

Clear semantics Icon buttons without clear labels disadvantage screen readers and new users. Relying solely on graphics for functionality is high risk.

Visible focus states Keyboard navigation users most fear “can’t see where current focus is.” If components only have hover without focus, some users are essentially ignored.

Operations not relying solely on color Can’t distinguish status by red/green alone. Color vision differences and screen environments amplify problems.

Accessibility Isn’t Adding Plugins and Done

If you get hierarchy, copy, control size, and semantic structure right from the start, much accessibility comes naturally. Conversely, if the foundation is chaotic, retrofitting accessibility is usually painful.

10. Consistency Isn’t Every Page Looking the Same—It’s Stable Rules

Consistency is often misunderstood as “all pages look identical.” What’s really important isn’t visual repetition—it’s rule stability.

Once users learn a set of interaction patterns, they shouldn’t have to retest in every new page.

Things That Should Stay Consistent

• Component behavior
• Terminology naming
• Button priority
• Feedback methods
• Icon meanings
• Spacing systems
• Form validation rules
• List-to-detail navigation logic

Things That Shouldn’t Be Forced Consistent

• Information density across scenarios
• Layout methods across platforms
• Primary action positions for different tasks
• Interaction differences required for platform adaptation

If teams interpret consistency as “all platforms look exactly the same,” end results often resemble neither Web, nor iOS, nor Android—just a compromised cross-platform monstrosity.

11. Cross-Platform Design’s Key Isn’t Replication—It’s Adaptation

The most common mistake in cross-platform products: taking one design and forcing it onto all platforms.

Seems convenient, actually problematic: desktop looks like enlarged mobile, mobile like compressed admin panel, native user habits ignored, ultimately nothing feels native on any platform.

What Should Truly Stay Consistent: Brand and Task Logic

• Core information architecture
• Key terminology
• Main flows
• Brand character
• Data results

What Should Truly Adapt: Interaction Methods and Carrying Forms

• Desktop can more emphasize efficiency, batch operations, shortcuts, multi-column layouts
• Mobile emphasizes focus, single column, step-by-step, thumb reachability
• iOS users have certain navigation and gesture expectations
• Android users have different return and hierarchy expectations
• Web users more accept tables, hover tooltips, complex filtering

Apple and Material are valuable not because you should blindly copy them, but because they long accumulated platform user behavior expectations. You don’t have to look like them, but you’d better not fight their users’ habits.

12. Don’t Blindly Chase Novelty—Innovate Where Users Genuinely Feel It

Interface design has a perpetual temptation: do something “never seen before.”

Novelty has value, but only if it genuinely improves experience—not just enriches portfolio covers.

Where Unstructured Innovation Is Least Appropriate

• Basic navigation
• Return paths
• Form interactions
• Payment confirmations
• Critical actions like delete, exit, publish
• System-level gestures and conventions

These are where users depend on familiarity, not surprise. Making infrastructure into concept design usually costs users.

Where Innovation Really Pays Off

• Reducing understanding barriers for complex tasks
• Compressing lengthy flows more naturally
• Organizing data-intensive interfaces more clearly
• Making error recovery smoother
• Making cross-device collaboration more coherent
• Making state changes more visible and trustworthy

Don’t be different just to be different. Many good product interfaces look understated at first glance, but feel natural to use—this smoothness is the hardest design capability.

13. Practical Advice for Product Teams

If you’re responsible for a real product, not a competition poster, you can condense interface review questions into these.

Page Level

• When users enter, do they immediately know where they are?
• Is the page’s most important task clear enough?
• Are multiple areas simultaneously fighting for primary/secondary status?
• Ignoring details, just looking at layout—is eye sequence reasonable?

Interaction Level

• Does every action have clear feedback?
• When errors occur, do users know how to recover?
• Are loading, empty, and error states handled separately?
• Is the primary action prominent enough, dangerous action cautious enough?

Input Level

• Any unnecessary input fields?
• Does form sequence match human task sequence?
• Do keyboard, touchscreen, mouse all work smoothly?
• Support drafts, undo, retry?

System Consistency Level

• Is component behavior stable?
• Is terminology unified?
• Are different platforms reasonably adapted or crudely copied?
• Does the new design genuinely improve experience or just look more distinctive?

If teams can persistently ask these questions, interface quality usually doesn’t deteriorate.

Closing Thoughts

Good interfaces aren’t “heavily designed” interfaces—they’re interfaces that make users expend less mental effort, make fewer mistakes, and hesitate less.

It might not look flashy, but it naturally guides users to complete tasks; might not wow in every corner, but won’t fail at critical moments; doesn’t rely on design jargon to impress—it builds trust through information hierarchy, feedback, error tolerance, input experience, and consistency fundamentals.

At the end of the day, human-computer interface design isn’t arranging things on screens—it’s arranging the smoothest possible path for users.

When the path is clear, style has meaning. When the path is unclear, more design means more disruption.