交互设计原则有哪些?

有那些经典的产品设计原则
关注者
9,140
被浏览
1,008,948

153 个回答

交互设计的原则有非常多,为了讲解起来有个头绪,我将目标瞄准了 Lawsofux 罗列的 19 条 UX 原则,易于理解且应用广泛。

这些内容主要由我的学生 Young 完成,我负责校对和审核。从开始准备到全部工作的完成,断断续续花了一个多月时间,其中翻阅文献、查找资料、细化理论、挑选案例花去了我们大量的精力,现在你们看到的所有延伸出来的要点都是我们一条条经过反复思考、推敲和整理出来的。

我们将这 19 条原则分别写了一篇完整的文章,在这里合并成一篇精简的回答,大家可以点击对应的链接查看完整的原文。

还有,为了便于学生的学习,我将这 19 篇内容制作成了 PDF,会在本文底部提及,如果觉得线上浏览麻烦的同学,也可以保存该文档到本地查看。

PDF内容的截图

原则1:美即好用效应 Aesthetic Usability Effect


当界面被设计得足够美观时,用户往往会容忍一些较为轻微、影响较小的可用性问题。

—— Massaki Kurosu & Kaori Kashimura

应用案例1:Everest官方主页https://www.everest.agency

例如页面中项目列表的滚动使用了一种极其酷炫的方式,动画自然流畅不拖沓,虽然整个页面利用率和操作效率没有比直接展示列表更好,但是使用者的感觉依然非常好。

但是,如果一味强调美观性,以此作为设计的主旨,是得不偿失的,不会带来真正的进步和提升,也不是 「美即好用效应」的本意!

原文阅读


2. 多尔蒂门槛 Doherty Threshold

系统需要在 400ms 内对使用者的操作做出响应,这样才能够让使用者保持专注,并提高生产效率。

—— Walter Doherty

应用案例1:模拟延迟效果

研究结果表明[1],计算机的响应速度直接影响了使用者做出下一个决定所要花费的时间 (这个时间被称为用户响应时间) ,换句话说,计算机相应的时间越长,用户就要花费越多的时间来思考和决定下一步的操作。

这是交互动画为什么建议在 400ms 左近时长的原因,无论太快还太慢,都不利于我们操作的反馈和决策。

原文阅读


3.菲茨定律 Fitts' Law

任意一点移动到目标中心位置所需要的时间,与目标距离正相关,与目标大小负相关。
—— Paul Morris Fitts

人们做出一个移动指针的操作通常需要两步:

    1. 第一步:将指针快速移动至目标大致所在的区域;
    2. 第二步:精细调节指针的位置以达到可点击的区域;

菲茨定律所包含的两点内容:

    1. 指针当前位置与目标间的距离 D 越长,所需时间越长;
    2. 目标的宽度 W 越大,所需时间越短。

原文阅读


4. 希克定律 Hick's Law

决策所需要花费的时间随着选择的数量和复杂性增加而增加。
—— William Edmund Hick & Ray Hyman

案例1:APP Store 新旧版本对比

改版后的 APP store 减少了选项的数目,便于集中用户的注意力,更能便于我们决策,增加用户对浏览首页的欲望和动力。
尽可能缩减用户一次决策中出现的选项,且在已经有多个选项时,不要增加选项的复杂度。


原文阅读


5.雅各布定律 Jakob's Law

用户将大部分时间花在别人家的网站 (产品) 上,而不是你的。这意味他们希望你的网站 (产品) 跟别人的有相同的操作方法和使用模式。
—— Jakob Nielsen

案例1:商品详情页

在国内,不论是淘宝、造作、网易云音乐,不论是合家欢风格还是性冷淡风格,甚至不论是不是电商 APP ,只要涉及到商品的详情页面,版式都高度相似,上方是图片,中间描述,底部悬浮的操作区域,这也是用户最熟悉、最容易接受的排版。
而和这种做法相违背是会造成用户极大的抵触和厌烦的,亚马逊中国就是一个非常好的例子。


原文阅读


6.简洁法则 Law of Prägnanz

为了更方便的理解这个世界,人类会将接受到的大量信息进行过滤和简化!
—— Max Wertheimer

几何形的识别难度

在简洁法则的影响之下,我们所看到的几乎所有界面都呈现出一定的几何规律,绝大多数界面中的组件/控件,不论它到底是不是真正的几何,在大脑中都会呈现出它是几何形的印象。
所有几何形中,识别负荷大致为圆形≈矩形≤凸多边形<凹多边形。
正因如此,在较为界面较为复杂的场景下应用更易识别的几何形作为基础视觉形状,这是简洁法则最简单直接得应用。


原文阅读


7.邻近性原则 Law of Proximity

彼此靠近的元素倾向于被视为一个组。
—— Max Wertheimer

应用案例1:起点、闲鱼、虾米音乐

邻近性原则是格式塔组织律中的一个部分,是简洁法则的一种具体的表现场景。
在《写给大家看的设计书》中,Robin Williams 将邻近性原则变称为「亲密性」,称呼不一样,但表达的是同一个意思。
如果我们对这些页面中的元素进行划分,可以得到 n 多不同的组,每一组内又由不同的元素构成。仔细观察我们可以发现元素与元素之间的间距永远要比组与组之间的更小,因为它们接近,所以它们成组,这就是邻近性原则的应用。


原文阅读


8.相似性原则 Law of Similarity

相似的元素倾向于被视为一个组。
—— Max Wertheimer

反面案例1. 蒸汽帮所有文章类条目只有一种样式

相似性原则是格式塔组织律中的一个部分,是简洁法则的一种具体的表现场景。
上一篇邻近性表达得是元素空间位置上的接近,而相似性则表达的是元素形式和内容上的接近,包括形状、颜色、大小、运动状态等等。如果在一堆元素中有一些具有某种相同的特征,那么在我们的认知中这些元素具有更强的相关性。
如果一个页面从上到下看起来全是一模一样的,页面呆板沉闷不说还全是字,这样就会对用户造成阅读的压力。所以我们常用的做法就是在大量 feed 中每隔3-5个就插入一种不太一样的条目,这种“不一样”的 feed、模块穿插在正常的 feed 中间能够活跃页面、控制用户的阅读节奏,避免枯燥。


原文阅读


9.连通性原则 Law of Uniform Connectedness

视觉上相连的元素倾向于被感知为具有更强的相关性 (相较于不相连的元素)。 —— Max Wertheimer

案例1:twitter

连通性原则是格式塔组织律中的一个部分,是简洁法则的一种具体的表现场景。对比之前的邻近性原则和相似性原则,连通性的作用和影响都要更强。
Twitter 的评论区设计是一个非常典型的案例,评论的回复与评论主体之间用连线来表达他们之间的相关性,不仅清晰易懂,而且与其余应用做出了足够的差异化,也算是具备了比较高的识别度了。


原文阅读


10. 同域原则 Law of Common Region

如果元素处在一个具有明确边界的区域内,那么在用户的感知中,这些元素倾向于成组。
—— Stephen E Palmer & Irvin Rock

案例1:系统级组件

同域原则是从格式塔知觉律和组织律中发展而来的一条亚原则,在少数文章中也属于连通性原理的某种细分应用场景,但这里将两者分开解释。
同域原则在 UI 设计中的应用极其广泛,从 iOS/Android 系统级的组件,到各种各样 APP 的设计,都在频繁得应用同域原则,将相关联的元素包括进同一片区域/卡片,来使它们的联系更加紧密,不相关元素间的区分更加明显,同时页面内容的划分也更加规整。


原文阅读


11. 米勒定律 Miller‘s Law

在短时记忆中,人平均只能记忆7 (±2) 个项目;即:人们最多只能够记住 7(±2) 个项目组成的一组。
—— George Armitage Miller

案例1:各种案例

无论是 iOS 的应用文件夹一页最多只能展示 9 个应用 (缩略图也是) ,还是 behance 分页组件一次最多出现 7 个分页,还是微信读书书架页每一屏最多 9 本书,设计师在进行设计时都在时刻注意着米勒定律的影响。


原文阅读


12.奥卡姆剃刀 OCCam’s Razor

如无必要,勿增实体。
—— William of Ockham

案例2:twitter、Behance、Instagram tabbar

奥卡姆剃刀本身是一种哲学思想,由中世纪 (十三到十四世纪) 英国学者、逻辑学家 William of Ockham 提出,如他在《箴言书注》中所写:「切勿浪费较多的东西去做用较少的东西同样可以做好的事情」。
上方 APP 都具有相当简洁明了的 Tabbar ,你可能已经注意到了,它们没有「首页」、「通知」、「发现」这一类描述性词汇,仅仅用最简单的图标就表达了对应页面的功能。因为在图标本身已经表达得足够清晰的情况下,这些词汇显然没必要再加上去,所以就被剃掉了。


原文阅读


13.伯斯塔尔法则 Postel‘s Law

接受多变,输出保守。
—— Jonathan Bruce Postel

案例1:淘宝搜索的各种自纠正

该原理也被称为鲁棒性原理 (Robustness Principle)。广泛应用于计算机协议以及系统控制理论中。虽然最近几年计算机界中出现了一些质疑伯斯塔尔法则的声音,单这并不妨碍其核心思想被应用于 UI/UX 的领域。
该原理表达的最核心思想是:系统/产品应保有一定程度的容错能力
法则中的容错性在搜索的结果中的体现,用户输入的是错误的信息没错,系统没有崩溃也没错,但是还不够。我们还需要在一定程度上智能修正用户可能输入错误的信息并预测他们的真实意图。帮助用户修正信息和操作,是今后发展的必然趋势。


原文阅读


14.系列位置效应 Serial Position Effect

用户更容易记住系列中的出现的第一项 (首因效应) 和最后一项 (近因效应)。
—— Hermann Ebbinghaus

案例1:web 版 behance、dribbble、花瓣、pinterest 界面

系列中最开始的几个项目能够更有效、更长久地储存在长期记忆之中,并能够快速回忆出来。系列中最近出现的几项(多数情况下是最后几项) 更容易储存在我们的短期记忆中。
多年使用 Web 的经验 (以及记忆) 会告诉我们这里大概率会是一个 logo,并且这个 logo 还能回首页。这种固定的设计和操作模式每次都是首先出现在我们的视野里,并已经储存在了长期记忆之中,我们能在第一时间反应出来这里是什么东西,有什么作用。


原文阅读


15.冯·雷斯托夫效应 Von Restorff Effect

当存在多个相似的物体时,与众不同的那个更容易被记住。
—— Hedwig Von Restorff

案例2:起点、大众点评

冯·雷斯托夫效应 (Von Restorff Effect) ,也称为隔离效应 (Isolation Effect) 。1933 年,德国精神病学家、儿科医生 Hedwig Von Restorff 在研究中发现,对被测试者提供一系列相似的项,而只有一项显得特别、孤立、与众不同的时候,这一项往往更容易被记住。
比如起点希望用户在个人页时去点击「版本测试」按钮,比如大众点评希望强化「订单」按钮的视觉特征以便用户能够更快速地找到,所以在列表中这两者都会长得不太一样。这种区别于环境中的其余功能按钮,为了吸引或暗示用户点击的按钮有一个专门的名字,叫做“Call-to-Action 按钮” (CTA 按钮/行为召唤按钮)。一般来说,CTA 按钮大多会利用冯·雷斯托夫效应的环境差异来达到 Call to action 的目的。


原文阅读


16.蔡格尼克记忆效应 Zeigarnik Effect

人们对未完成任务的记忆比已完成的更深刻。
—— Bluma Wulfovna Zeigarnik

案例1:多邻国

蔡格尼克效应被用于证明格式塔现象不仅在感知中普遍存在,在认知中也是如此。勒温的场论给出了一种解释:一项任务被启动之后人会形成一种处于紧张状态的场,这会增强对所有与该任务相关信息的认知;任务完成后紧张的状态就会得到缓解。
如果一个任务存在多个步骤,那么在任务结束之前应该用某种形式 (比如进度条) 提醒用户任务还没完成,这能够激发用户完成任务的欲望。


原文阅读


17.特斯勒定律 Tesler’s Law

任何系统都存在固有的复杂性,无法减少;唯一的问题是谁来处理它。
—— Larry Tesler

案例1:B 站一键三连

特斯勒定律 (Tesler’s Law) ,又称复杂性守恒定律 (Law of Conservation of Complexity) ,是人机交互领域的一句格言。上世纪八十年代中期,Larry Tesler 在 Xerox PARC 工作时意识到用户与应用交互的方式与应用本身一样重要。后来 Larry 加入了苹果并致力于 MacApp 面向对象的框架的开发,在那里他正式得阐述了复杂性守恒这条定律。
特斯勒认为产品的复杂度应该交由代码,开发人员应该多花一周时间用代码来简化应用的复杂度,而不是让成千上万的用户在应用里为交互多花哪怕一分钟。
B 站的一键三连小细节就是一个很好的例子,这个操作是这样的:用户长按点赞按钮,就能同时触发点赞、投币和收藏的操作,这就省去了用户挨个儿点的操作成本和时间成本。


原文阅读


18.帕累托原则 Pareto‘s Law

对于许多事件,大约80%的影响来自20%的原因。
—— Joseph Moses Juran

案例1:网易云音乐的 UI 迭代

上世纪 40 年代,美国一位管理顾问 Joseph M Juran 观察到一个在商业以及生活中普遍存在的现象:在某一过程中,80% 的影响来自于 20% 的投入。他将这一现象以帕累托为名,称为“帕累托原则”。
80/20 虽然只是一个相当不精确的数字,在很多具体情况之下,这个数字会有细微的波动,但这个数字背后所蕴含的思想或是规律却是不变的:更集中的投入将产出大于预期的结果。
最近网易云音乐和虾米音乐都迎来了大版本更新,UI 设计也几乎重新设计了一遍,但我们所看到的重设计,只局限在那些关键的页面上,一些次要的页面基本没改。因为用户基本只在一占据 80% 使用场景的地方,而不太在一剩下的 20%。


原文阅读 (待发布)


19.帕金森定律 Parkinson’s Law

任何任务都会拖延,直到所有可用时间都用完为止。 —— Cyril Parkinson

案例1:mimo 课时分解

例如 Code 学习软件 Mimo 会将一个大的学习任务分解成几个小的任务,小的任务中分别还有不多的几项课时,此时每完成一项小任务都会有相应的成就奖励。相比起直接给一个「学习 iOS 开发」这样宏大的目标,下分几十个密密麻麻的课时,并定下一个「3个月」这样宽泛的时间而让用户不断拖延直到放弃,这样细分的任务能够更加有效地控制每个任务所要花费的时间,不仅能把帕金森定律的负面影响降到最低,也能激励用户完成最终的目标。


原文阅读(待发布)

产品设计的原则有点太泛哈,这里想结合自己的工作心得来小结一下手机无线设计8原则:

1:用界面应该是基于用的心里模型,而不是基于工程实现模型

就是把后台本来很复杂的事情通过设计符合用户日常生活中常用的浏览方式或操作方式。其实这一点是设计师把生活中的细节和数据结合的凝聚点,用户的心理模型抓的越准,界面就会越优秀。

#左边界面#:大众点评新版的价格的搜索就比之前改得更符合用户心里模型;#右边界面#:食神摇摇的摇动手机找餐厅更加符合大众用户的心里,大家应该都有那种中午不知道去哪家餐厅就餐,那么就摇一摇来随机抽出一个附近的餐厅。

2:培养用使用情景的思方式做设计

要做到这个原则其实是很难的,需要长期的实战经验才能做到这点。

那我们都知道米聊出的比微信早,但后来被微信反超,个人认为不光是QQ帮了微信很大忙,比如用户登录门槛低,用户来源,广告打得响之类的,其实在用户使用情景方面米聊研究的没有微信透彻。

对于一个社交即时通讯产品,添加好友的功能是好友汇聚的来源,虽然米聊微信都绑定手机通讯录,但话又说回来,用户找手机通讯录联系人语音聊天的还是比较少。添加好友是引导用户去发现好友,找好友, 碰好友的一扇门。所以对于这么重要的功能放置在应用程序的哪个位置,在产品前期就会让用户明显的去选择用哪个应用,因为聊天工具的前提是要有人和你聊天。再回到现实的界面中来,看看下面的对比:

微信1.0的时候(我这里只截了4.0的图)把添加好友放置主Tab上,方便用户很快的添加好友

米聊2.0时还是把添加好友放置在好友列表的第一排,用户很难发现


3:尽量少的户输入,尽量多出参考

移动端的虚拟键盘一直是科技界无法解决的一个难题,虚拟键盘的主要缺点:1.输入定位无法反馈,所以无法形成高效的盲打;2.虚拟键盘的空间限制,手指的点击经常造成误按。光是上面这两点就让虚拟键盘在输入上大打折扣,所以我们在设计应用程序时,只要遇到Input Box的控件时,首先就要想到尽量让用户少输入,或者智能的给出参考。

百度音乐的搜索先是把近期最热门的歌曲依次排列在列表中,当有字输入时,会出现歌手的候选词,这里值得称赞的是百度音乐的搜索能根据用户输入的字来判断用户是搜索歌手还是歌名。

百度地图也是我用得比较顺手的一个地图导航应用,在减少输入方面也做的比较出色,百度地图拥有cookies功能, 另外就是百度搜索的技术应用在地名的匹配中也很让人欣喜,在用户输入到一半的时候,下面的候选列表就出现了目标地址,用户直接停止输入点击列表即可。

4全局航需要一直存在,最好还能预览其他模动态

全局导航在Web交互设计中比较容易做到,在手机移动端全局导航要看产品设计的需求,什么功能需要全局导航,社交应用通常是:消息,通知,请求;音乐视频应用通常是:下载,搜索;工具类产品经常是核心工具条(tool bar) 比如浏览器,语音助理,音乐识别应用等等。

全局导航的价值在于可以让用户在使用过程中不会丢失信息,减少主页面和次级页面之间的跳转次数,当然全局导航中的info-task要能在当前页面完成,如果需要跳转到新界面,就会失去全局导航的意义,因为当出现多个info-task的时候,就需要用户不停的进入全局导航页面来完成。

Facebook 的朋友请求,消息,通知都是采用全局导航的方式,就是面板设计的丑了些~

米聊的通知中心,里面包含的通知类型蛮多的,显得有点凌乱,希望下面的版本会筛选归类


原则5:提供非模的反不打断任务流
模态弹出框的书面名称在iphone OS中称作:Alert-box,在Android OS中称:Pop-up box, 我们都知道弹框会打断任务流,所以在有限的屏幕上怎样让这些弹框弱化,或者说优雅、绅士的提醒用户,这个需要设计师来定义。

模态是指界面中只有提醒弹框才具有可交互行为,其他一切都不可操作;非模态不会把提醒做成弹框,可能会处理成List Notification, Toast list等方式来提醒用户。

Gmail是第一个把删除的模态弹框设计成List Notification这种方式的,提醒用户撤销刚才的删除操作,这种非模态的处理,让删除的流程更加顺畅和轻松自如。

K歌达人第二版的弹框就是模态处理,界面很不友好,用户在K歌过程中要被打断三次才能发表一首自己唱的歌曲,所以降低了用户的参与度。

原则6:不要让用户等待任务完成,用户还要发现更多有意思的地方

移动互联的核心就是给用户带来移动体验的方便和高效,这是 移动互联网Apps需要考虑的,用户在使用你产品在很多情况下都是碎片时间, 所以在设计上尽量让用户在短时间内熟悉我们的产品,知道这个产品的诚意,特别是某些等待界面需要设计,不能把一个很枯燥的等待界面呈现在用户的面前,那用户很快就会换其他apps。

在Instagram 拍完照片后,点击上传后,它的处理方式是回到首页的位置,告诉你的照片正在提交,并不是显示一个上传进度的界面,让用户看那上传百分比。因此,我们在设计米吧上传歌曲文件时也只是告知用户后台正在帮你上传,叫用户放心,用户自然就会去玩其他的功能,没有让用户焦虑的等待,等上传完毕时,我们再用Toast list通知用户已经上传成功,这样把查看上传结果的主动权交给用户。

原则7:自动保存用户的输入成果

在移动端,由于输入面板的复杂性,而且触摸输入没有物理按键的反馈自然,特别是手机上去输入一段文字或者信息,对用户而言本身就是一件很痛苦的事情;对产品而言,用户的在你的产品中输入是一个很值得庆幸的事情,所以设计人员需要让你的apps自动保存用户的输入成果。

微博官方的手机客户端在用户输入信息后,点击左上角的叉时会弹出Action sheet来询问,确认是否要放弃,或者保存为草稿;path的处理则更为人性化,在处于断网的情景下,用户依然可以发布照片和文字,当然后面联网成功后,系统会自动上传,只是发表时间是连网后发布的时间点;Instagram的评论也很友好,在断网或者网络情况不稳定的情景,用户输入的评论依然可以发布,后面会有一个叹号提醒用户稍后发布或者重试,提升了用户参与的积极行,同时活跃了社区。

原则8:为了程序响应的速度,设计有时候需要担任掩护的作用

科技并不是万能的, 技术依然是移动互联网应用程序最需要优化和完善的,作为技术的盟友我们设计人员也需要辅佐他们,让用户觉得程序原本就应该是这么运行的。特别是程序响应的速度很多时候不光是技术的问题,与网络环境也有很大的关系,这时候设计人员需要考虑这些客观存在的情况,帮助程序来掩护这些瑕疵,让用户感觉到在使用时是流畅的。

#随后实现# Instagram帖子“赞” 不管对参与者还是帖子作者都是激发其积极性活跃社区氛围的重要功能,所以在程序的响应方面一定要具有可用,易用的特性,我们看左图中,“赞”的按钮已经现实“已赞”,同时我们看红色框内的“菊花瓣”就知道后台在loading赞的数据,所以这就是设计的巧妙之处,先让用户感知到程序是非常快速的,而不是等loading完之后再显示“已赞”;

#提前传输# Instagram中发布帖子的时候,用户处理完照片点击“上传”按钮就看到中间的界面,这时候界面是让用户去为自己的帖子输入一个主题,或者去设置分享等功能,同时我们可以看到红色框中的“菊花瓣”,很明显后台已经开始传输刚才上传的照片了,所以当用户在点击“完成”时,数据只需要上传剩下的一部分,让用户感知上传很迅速;

#边唱边完成# 把伴奏和用户的歌声合成为一首音乐时需要后台处理大量的数据,如果分步做就要让用户等待比较长的合成时间,为了让用户不用枯燥的等待合成,我们需要后台在用户唱歌的同时,后台就已经开始把唱过的伴奏和歌声合成。

以上八项原则是我在工作中体会比较深刻的交互设计原则,希望能对观看到这篇博文的朋友有所帮助。当然设计原则是随着时间的变化而不断变化的,所以也请各位朋友完善和补充,谢谢!