关于「撤销」有很多设计细节可以讲，所以我花了两周时间，将其浓缩成 3000 字，帮助各位产品设计师更好理解撤销的设计细节。

撤销的目的是帮助用户取消当前的操作行为。

撤销可以对用户使用产品起到一种安全保障作用，让用户在界面中自由地探索而无需担心操作所可能导致的严重后果。

或者用户删除了一个视频，撤销可以帮助用户恢复他所删除的内容；以及用户进行了一步操作，觉得不太好，就通过撤销来回退到上一步操作。

与之对应的叫「重做」，就是当用户撤销了当前的操作，但是想了想，还是行进到刚才已经操作的步骤好了。既给了用户安全感，还给了用户反悔的余地。

类似于下象棋的时候，你觉得这一步走得不好，所以悔棋了，虽然对家没说什么，但是你心里又觉得过意不去，毕竟落子无悔真君子，所以你又把棋子放回去了（真是不怎么恰当的比喻呢）。

这样做的目的是提升用户使用产品的信心，增强对产品的控制感；鼓励用户放心地探索，快速建立起自己熟悉的操作路径。

所以关于撤销，我们可以从下面几点来聊聊：

• 依次序撤销
• 选择性撤销
• 撤销在界面中的运用
• 与撤销冲突的元素

依次序撤销

它的意思是，依次撤销之前的操作。

在尼尔森可用性原则里，就有一条类似的原则存在，即 User control and freedom（允许用户自由操控）。

很多人把这条原则解读为「撤销原则」，本质上是没什么问题的，因为撤销确实需要让用户自由操控。但是早期的撤销，并不「自由」，而仅仅只是让用户在一定范围内「可操控」。

比如早期在一些产品里，执行多步操作，但往往只能撤销一次，要想继续撤销是不被允许的，所以它的操控自由度就很低。那时候如果把这条原则解读为「撤销原则」，显然是不合理的。

于是，后来逐渐延伸出多次撤销的功能。

我记得最早使用 PS 的时候，在 PS 里面就有关于撤销次数的范围设定，但是我忘了具体范围的上限与下限是多少了。

使用的方式是，比如我设置参数为 10，那么之后我的撤销也只能操作 10 次，要想继续撤销，就会告知无法继续了。

现在的很多工具产品应该是没有这些限制了，比如 Sketch，Word 都是可以无限次撤销直至最初始状态或刚打开文件的状态。

相对早期撤销的使用逻辑，后来可多次撤销的操作在自由度上，确实是好了那么一些。

它就是在「单次撤销」的基础上，给了用户「多次撤销」的机会，并让用户回到自己满意的位置。

但是这里的撤销，它还不够自由，因为它是「依次撤销」—— 每一步撤销用户都得经历。

选择性撤销

当撤销随着用户场景的变化而进化之后，才真正具备了比较自由的操控方式。

让撤销具备「选择属性」，必须与另一个元素做一个结合，那就是「历史记录」。

继续拿 PS 举例。

大家看到上面这张图，当你在 PS 的画板里完成了一系列操作之后，发现后面有一些东西做得不是很好，想回去重做，但是依次撤销又觉得不好把控，于是就通过操作历史，来选择具体回退到哪一步。

相比于依次序撤销，选择性撤销的自由度更高，也更符合其对尼尔森可用性第三条原则的解读。

或者再通俗一点的例子，浏览器。

假设这时候你打开了 5 个网页，关掉了其中 3 个，但是突然想起第 1 个关掉的网页还有值得收藏的内容，于是依次撤销 3 次，才打开第 1 个关掉的页面。

而现在有网页历史记录，就可以直接帮你打开之前关闭掉的所有网页中的其中一个。

解决了用户每一步都要经历的问题。

当「撤销」与「历史记录」结合之后，「选择性撤销」的出现还能解决掉「依次序撤销」的一个关键问题：撤销重做之后，无法复原。

通俗点讲，就是当用户撤销到之前的操作，进行了新的操作行为，那么原来旧的那条线路就被废弃了。看图：

当用户操作到第 5 步，然后撤销至第 3 步，再执行一次新的操作，那么步骤 4 与步骤 5 就会被废弃。

大家知道很多设计师都会做版本记录，因为 PS 的历史记录虽然在撤销操作上方便了很多，但无法复原之前的操作逻辑依旧不能满足一些设计师的诉求。

毕竟不废弃的话，撤销操作的逻辑就会很复杂；且通常「选择性撤销」伴随解释，说明用户清楚知道自己当前行为会造成何种后果。但它并不能解决用户操作过程中实际存在的这类问题。

而「选择性撤销」的「版本记录」可以解决这个问题，来看下面这个例子。

结合历史/版本记录，比如用 Notion 或石墨写了一篇文章，它们都会有版本记录，过程中会根据时间维度与内容变更维度来判断是否进行保存，那么当用户想回滚到之前的那段内容，只要对这些版本进行点击查看，然后选择具体撤回到哪一步即可。

比如我今天（2019.11.05）早上花了半小时最后对文章做了一次整理，添加了图片，它就会记录其中的操作变化，且可进行选择。这里无论如何撤至哪一步，其它内容都会有留存，不会消失。

也许这已经不是通常意义上的撤销，但它确实是撤销的升级版。

这样看起来是不是自由操控度要高很多呢？

到这里，我只是讲了「撤销」的特性，下面来聊下它在界面设计中是如何应用的。

撤销在界面中的运用

我们现在在很多产品里都能看到撤销，在网页里与移动 App 中，它的使用形式虽然多样，但本质上并没什么区别。

大多就是单次撤销，因为用不到多次撤销，多次撤销更多是在工具里被使用。

比如油管的撤销使用：

当用户对一个视频进行「不感兴趣」的操作时，视频内容会变成右边这样，可撤销。这个内容会一直存在直到用户刷新页面时才会消失。

类似的还有淘宝网页端的购物车，当删除添加的任一商品后，其也会在附近位置出现可撤销的操作。

在网页产品中，撤销的运用大多是这样的。

我们再来看移动端产品对于撤销的应用。

在 iOS 中比较常见的是微信的摇一摇手机撤销正在键入的内容：

这类撤销较为被动，经常是在无意间触发，所以不是我们主要要聊的。

而有一类产品，撤销会以 Snackbars 的形式出现，如图：

当这类邮箱产品，删除了某封邮件后，在底部就会出现这样的提示，告知用户可撤销上一步行为。

更多的还是工具类产品，比如修图类产品 Snapseed：

它有单次撤销，也可以重做，还能多次撤销，多次撤销就是点击「查看修改内容」之后，右图出现的样子，它会把所有步骤都呈现出来，给予用户选择具体撤销至哪一步。

其实更多的也就是这样了，但是，为什么呢？为什么在非工具类产品里撤销很少见呢？难道用户从来不会误操作或操作之后反悔？

下面一节来解答。

与撤销冲突的元素

先放结论：当某个功能具备撤销属性时，切勿再使用二次确认对话框，反之同样成立。

撤销与二次确认，是两种东西，虽然有时候解决的是同一个问题，但是它们的属性是完全不同的。

举个例子：

上面这张图，左边是在执行操作前弹出的确认框，右边是执行操作后弹出的提示框。

二者的区别很明显，二次确认的删除提示框更具警示效果，后者作为提示，较为弱化，且通常是在用户操作完成后弹出。对于用户来说，在非工具类产品中，前者更好的抑制了用户的冲动行为或误操作行为。后者作为提示类控件，不具备警示效果。

所以它们不应该同时出现，且它们虽然是解决同一个问题，但是是完全不同的情况。

于是，在大多数产品中我们很少看到撤销的使用，因为大部分需严谨的操作都会有二次确认，并不严重的操作也就不需要任何提示。即使是上述提到的邮箱删除，没有二次确认也是因为它有撤销作为提示且还有回收站允许用户检查确认。

所以，除非是场景与之密切相关的，比如社交产品内容发送后的撤回功能。

微信早期的撤回，只是撤销，它并不具备「重做」属性，现在撤回，内容会重新出现在输入框让用户重新编辑。

它们之间的差异是：它并不会产生严重后果，但确实会产生小问题。比如误操作发出信息，或发出后发现话术并不严谨。

所以这一段内容只是想告诉各位：二次确认操作与撤销操作是两种不同的东西，虽然看起来是解决同一个问题，但它们的差异也是非常明显的。必须谨记。

另外还有个提示：心细的同学会注意到文章里或其他产品里出现的「撤销」通常也会写成「撤消」。在别的领域里这是两种不同的内容，但在产品设计领域里，目前并没有对这两者做明确的区分，所以暂时不用过于纠结。

总结

这篇文章讲了很多内容，我在这里梳理下：

• 撤销分为依次序撤销与选择性撤销；
• 依次序撤销有单次撤销与多次撤销，以 PS 为例；
• 选择性撤销大多在工具类产品里被使用，它与历史记录结合，解决了依次序多次撤销部分内容被覆盖的问题；
• 在非工具类产品里，被使用更多的是单次撤销，是因为场景限制；
• 撤销与二次确认不可同时出现，它们看起来是解决同个问题，但之间存在较大差异。

所以当你设计的产品要用到撤销时，也要注意这些细节问题。

这就是本篇文章的所有内容了。其实这篇文章里包含的内容有很多，而且有很多争议点我都没放出来，直接一笔带过给出正确结论了。写这种大部头文章太累，要思考的点很多，需要帮助读者从多视角排雷，很可能导致初学者在读文章过程中出现阅读吃力的问题。所以之后还是会挑一个点来写吧。

文章来源：优设

我们通过门铃声儿得知门外有人来访，也能通过电话铃声得知正被人呼叫。短信通知也有着类似的作用，包括各类产品的消息推送。

但不同的是，消息推送的重要性随着「通知」被滥用而变得不那么重要了。它们变得不像门铃或电话铃声起到的作用性那么大，包括短信现在也大多是垃圾信息。

而且，通知越来越多地通过各种方式去触达用户。比如消息未读的红点提示，或者显示消息的数字统计，以及手机使用过程中的顶部提示与声音或震动的提醒，等等。

但我们还是无法抑制点击图标的冲动，这仅仅是因为它具有未读的计数或红点提示，即使我们已经知道当中的内容并不重要。

而我要说的是，当通知内容变得次要且被滥用之后，它仿佛成了一种违背设计原则的功能 —— 中断用户当前行为。因为它打破了用户与产品之间的层级关系，破局至产品之外来吸引用户的注意力，这是一个非常打扰的行为。如果我在看书，突然收到一条并不重要的消息，那我一定会非常反感。

所以，为了不被「红点」支配，以及不让通知所打扰，我会把手机里所有产品的消息推送都给关了。

但是，以上内容并不能说明通知的无用论。同样有许多用户还是沉迷于通知的使用上，它所控制的是用户对于某个产品的控制欲，担心错过某条消息，就好像我在豆瓣写了篇随笔，就想看别人给我点赞评论的消息，但我又不可能一直盯着，所以通知这时候就起到了一个很好的作用。

以至于对于优秀的产品人或设计师，包括运营来说，利用好通知，就能掌握用户心理，巧妙的将用户留在产品中。它们甚至有助于与打算放弃产品的用户建立联系并促进互动。

那么，我们应该如何更合理的设计通知呢？下面我们通过「通知的组成部分」以及「通知的使用类型与规则」来详细做一次拆解。

通知的组成部分

关于通知的简单定义：它是一种吸引用户注意的功能模式，让用户获悉新事件的信息动态。产品将其发送给用户并与用户产生交流。

因此从这个定义中我们可以知道，通知有两种形式，分别是被动只读型和操作反馈型。

被动只读型，是指该信息可读，但不可进行操作；操作反馈型，是指用户可对该通知进行操作，如某宝订单支付成功后的地址信息确认通知。

所以在梳理组件的时候也要注意掉这个差异。

1. 消息中心

这里的消息中心，是一个信息汇总中心，但并不一定是信息来源。意思是，信息来源可能是有很多用户在你的文章下面点赞了，而这个点赞行为被汇总到了消息中心，再用消息中心指引作者去到文章页面查看具体详情。

所以它是一个汇总表。但也有可能它就是信息来源点，比如一些系统通知，告知要升级，因为它没有其他功能可承载，所以只会在消息中心里出现。

或者类比 iOS 系统的通知中心，如果通知是 App 推送的，那么它会指引用户进入某个 App；如果通知是系统行为，如勿扰模式，「6:00 前来电和通知将会静音」这个通知，是只可在通知中心进行操作的。想要更改，就需要手动打开设置。

2. 通知指示符

它可以是点，也可以是计数器，只要表明目前消息中心有新的信息就可以。我个人一直觉得这就是让我们多数人养成强迫症的罪魁祸首。

3. 信息标题

它主要是指该信息来自于谁或属于什么子类型，比如用户互动点赞消息，评论消息，系统消息等等。用户可以通过标题来获悉该信息类型，再通过内容摘要来判断内容是否重要。

当然，这里的摘要如果过长，就需要省略处理，引导用户进入消息源或消息中心。

4. 推送时间

推送时间是一个看起来简单，实际上也好像不是很复杂的逻辑。只要说明该通知的发送时间即可，但是需要注意的是时间段问题。比如几分钟前，几小时前，几天前，这里的逻辑是按照时间推进规则持续增加来告知用户该消息的推送时间节点的。也就是过得越久，时间概念就越大。

5. 通知图标

上面讲到消息类型，我们也经常会在各类产品中发现不同通知的类型会汇总在各自的类型下。包括用户所接收到的信息，通常也会告知用户该信息属于什么类型。有时候，标题可能会更细，但是用户通过图标可以判断该信息属于什么类型，甚至都不需要仔细查看标题与内容。

但是，并不是所有产品的信息都可以通过图标来判断，有时候图标只是一个大方向，如果手机锁屏，相对于用户来说，这条通知只是告诉用户该信息是由什么产品推送，而并不能指向至该产品的什么类型的信息。所以在使用的过程中，同样需要根据业务的场景，谨慎地选择图标。

6. 阅读指示器

它就像是上面提到的红点，这里指的是进入 App 的消息中心之后，所显示的内容。

7. 操作行为

这里的操作行为分两种，分别是 App 外与 App 内，它们之间的操作逻辑是不同的。iOS 系统通知的清除操作，只是在系统的通知中心将该信息清除，进入具体 App 后，这条消息还是会存在。而在 App 内删除该条信息，则该信息才会真正消失。

所以从上面可以看到，通知推送，是有两大类别的，分别是 App 外与 App 内，它们之间的逻辑关系与展示形式会有所差异，需要根据具体情况进行设计分析。

8. 小结

对上面的内容进行总结，可以得到这样一幅画像：

大部分系统或产品的通知组成，都可以通过此图概括，唯一不同的是，它们会随着不同的业务而发生变化。

比如豆瓣的推送消息告知用户近期有新的电影上映，那么通知来源要么是电影模块的功能详情页，要么是通知中心的系统消息；而通知类型就是内容更新；详情则根据具体内容来组合排列；最后送达至用户。

而其中的差别就是，如果是通知中心推送的，用户点击之后则是进入通知中心列表。如果是具体功能推送的，那么用户点击进入的就是具体功能页面。如下图所示：

从这里可以看出，通知是有具体模式的。

一旦确定了通知的主要目标，以及想要解决的问题，包括它们如何对业务产生作用以及对用户形成吸引力，就可以确定通知的具体样式了。

在这一节里只要知道通知的组成部分与通知模式如何指引用户进入 App 即可。后面我来带大家理一遍逻辑，以及在设计通知时要注意哪些问题。

通知的使用方法

聊完上面的内容之后，我相信大家对通知的组成与使用模式已经有了全新的认识，但也仅此而已，我们还是不知道一个优秀的通知功能应该从哪些方面去提升用户体验。这里面所包含的不止是表象，还有内在的规则逻辑。所以从这一节开始，我们仔细来梳理一遍。

从我们平时使用到的，以及上文提到的，可以大概先梳理出几类常见的通知类型。

1. 用户信息类通知

这种类型的通知有很多，比如微信消息发送，知乎私信，手机短信等等，它们主要由用户主动生成发送至其他用户被动接收，作用就是促进用户与用户之间的互动关系，以提升用户使用产品的频率与时长。

这种通知，可给予用户操作也可不给予操作，不操作就是读取，并回复；操作就是可对该用户的信息进行屏蔽、已读、删除等设置。

这是最常见的通知类型，在多数社交产品与有社交特性的产品里都能看到。

说明

之所以给予用户信息的操作行为，是因为用户信息可分为感兴趣的与不感兴趣的，它主要取决于人。不感兴趣的人，频繁的发送信息，会影响用户对产品的好感度，毕竟有很多用户消息并不是用户想要接收的，所以在社交产品里，用户可删除好友，或拉黑好友；在有社交属性的产品里，用户可拉黑账户，以达到不被骚扰的诉求。

如果没有到达删除好友的程度，也可对该好友的信息进行屏蔽，甚至对该好友信息做已读而实际上未读的处理；或者对重要信息做未读而实际上已读的处理。

当然，用户还能对群消息做更复杂的设置。这就是产品对这类通知的一种优化方式。

2. 系统推送类通知

我们经常会在手机上收到一种系统类通知，或者在 App 中也会收到类似的系统通知。大多是关于系统升级，密码更新等。

这类通知多数是用户被动接收，且对于系统与用户来说是较为重要的。当然也有不重要的，比如 App 更新说明的通知，告知用户新功能有什么变化，或系统更新了什么等等。

对于这类通知，用户大多无法进行设置，因为它们比较强制，没有可以商量的余地，类似于告知用户：我们有新的消息，比较重要，你来看看，即使你不打算更新或执行也来看下。

说明

系统类通知，通常来说较为被动，要么强制用户执行操作，要么就是提醒用户系统近期做了更新，或者是一些并不重要的信息提示，比如勿扰模式。

强制类系统通知不能频繁，否则会给用户造成控制欲反制的副作用。类似于本身用户使用产品需要对产品享有控制权，现在反而被产品控制了。这是不行的。

3. 通用推送类通知

这类通知就是第一节中提到的那些，比如点赞/评论，内容更新等等，这类通知如果是忠实用户，那么或许不会反感它的频率，当然还是需要适当。但如果是普通用户，那么造成的影响就是直接关闭该 App 的所有通知。

我们现在的很多人，之所以开始反感通知的主要原因，就是这类通知所造成的。内容不断更新，随着时间的推移，每天推送多条对于该用户来说无用的通知。包括只适合一些符合条件的用户参与的活动通知也推送给所有人，那么用户就会逐渐对这类产品的通知失去兴趣，造成无法弥补的损失。

即便像某团一样，经常弹出开启通知的弹框，也依然无法召唤回用户。这就是很典型的下场。

说明

通用型通知，如果是业务很复杂的产品，就必须建立通知推送的功能模块，给予用户进行选择接受哪类信息的权力。允许用户进行相应的设置，如活动类推送可拒绝接收。

在很多产品中都已经置入这样的推送模块设置，如下图。

这类内容就是针对于产品的具体业务进行细分。

比如兴趣精选，私信消息等做好类别划分。用户可对自己感兴趣的通知做选择性的推送接收。

另外就是，在相同账户的不同设备之间，推送应该同步推送与被处理。不能这边推送了，那边没推送，或者这边处理了，那边没被处理。

4. 智能推送类通知

不知道大家是否有印象，在使用如大众点评等产品时，只要你切换了城市，产品就会推送通知告知用户该城市有哪些值得游玩的景点与品尝的美食。

虽然这类通知还算不上多少智能，但至少在用户群体中是存在这类诉求的。而这类诉求有时候并不能主动感知，因为用户可能会想不起来通过哪类产品来查找附近美食。当这么一条通知出现的时候，正好解决了用户的问题，反而提升了用户对于产品的好感度。

现在很多产品的通知都逐渐智能化，不会像以前那样，三更半夜发来一条无关紧要的通知。而出现这类问题的主要原因还是在于产品、设计、运营，在这方面没有下过功夫，只将通知作为一种普通的工具来使用。导致用户开始排斥通知，将其强制关闭。之后，就很难再让用户开启了。同理心效应，当做这类功能的时候，可以回想一下自己是如何被其他产品打扰的。

随着大数据的发展，我相信未来的通知系统会更加全面，且能做到千人千面的模式，不过在此之前，各位产品设计师，还需要对通知下一番功夫才是。

5. 小结

我们还可以继续举例说明，但是基本大同小异，所以到这里为止，我再对上面的内容做一次总结，梳理出一个好的通知应该是如何设计的。

干扰最小化：通知本身具有强制性和干扰性。它的目的是把用户的注意力吸引到产品上来，所以要认真思考发送通知的内容、时间、频率；不要提醒用户当前屏幕上已经处于展示状态的内容；也不要推送与用户无关的系统信息。

跨设备：当用户读过了某条信息，这条信息应该不再做展示。同理，用户也应该能够在其它更适合接收消息的设备上找到已读信息。用户通知应该在所有设备上进行同步。

允许设置：允许用户在「设置」中禁止或调整通知的形式。如案例一，通过选择推送内容，来影响接收推送的频率。案例二，可选消息提醒的形式是红点+数字，或仅是红点。

时效性：良好的通知应尽可能实时推送。而不是等这件事情都过去很久了，才推送给用户知道。

支持汇总：把同类型的通知合并为一条，并显示信息未读数量。也可以考虑一键展开通知，显示信息详情。

可操作性：把通知和操作结合在一起，让用户不需要打开首页就能对特定通知进行常规操作。操作应该清晰明了，且仅在未重复默认操作时提供。同时操作应该是有意义、实时、和内容对应的，并且能让用户完成某个任务。如案例一，可以在不打开邮件的情况下，直接对通知进行管理、查看和清除。案例二中的操作针对的是未读邮件，可便捷地在通知板面进行回复、删除、标为已读或垃圾邮件。

总结

对本篇文章的拓展总结：

• 通知具有召唤属性，但是频率过多就会变成打扰，所以要注意通知的频率与内容重要性；
• 设计师或产品经理应该将通知的内容分类梳理出来，以便维护或新增必要需求可能需要用到的推送信息。
• 通知一般为两种类型，一类是推送只读型，一类是操作反馈型；设计师需根据不同类型的通知做好对应的设计，针对具体问题具体分析；
• 想要利用好「通知」，也需要对业务有详细的了解，再代入本文所列举的注意点，就可以设计出一个体验更佳的通知模式。
• 通知规则不会脱离本篇文章的范围，所以只要详细研读，必会有所收获。

文章来源：站酷

先问一个问题：怎么样衡量一个设计好与不好？工作中实践越多次，越会发现华丽的设计稿并不是体现设计师专业能力的唯一标准。普通设计师和高级设计师区别在于，设计方案是否具备完整设计思路；设计对于业务有没有真正的价值体现；以及设计方案的推动落地的完整性到底有多少。设计越往后走，越考验产品思维，设计思维，以及设计推动能力。这是产品设计师需要关注的核心三要素。

设计师在工作中接到设计需求会不自觉的第一时间想着如何去进行视觉表达，视觉表达确实非常重要，也是公司对于设计师的核心价值的定位之一，但视觉表达只是其中设计专业本职工作中的一个环节。设计师还要应该能够站在产品、设计、技术等不同维度去思考设计方案的可行性。产品打磨-视觉呈现-落地执行，在这三个核心点里面设计师分别有不同的定位和价值所在。 

  一. 产品“双标”满足   

产品打磨包含产品规划，内容组成，界面布局，交互梳理等等…所有环节的工作是为了符合产品最终的目标。产品所有的能力会核心围绕两个点：1商业变现 2用户需求满足。这两个目标在产品执行的环节有时候会有一些冲突，在产品打磨阶段设计师通过怎样的方式，做到既满足产品商业目标又满足用户体验需求？可以按照以下几个步骤进行分析寻求切入点： 

这里用腾讯动漫付费模块举例说明： 项目背景是腾讯动漫产品要做付费体系升级设计，接到需求先有由产品源头一步步深入，逐步展开设计方案的规划。 

 01 产品目标确认  

通过对项目背景的解读和产品方案的深入了解，以及总结当前存在的一些问题，可以明确得到项目中产品核心目是什么。付费升级核心原因是付费转化低，用户付费意愿不够强烈。此次升级的核心目标是促进内容消费，提升付费率。 

 02 分析用户路径  

确认目标之后从哪个模块儿开始进行首要需要考虑的。对于现有现有功能的升级，建议核心从产品本身着手，可以根据用户行为分析，获取用户常规使用路径，找到用户使用场景下的核心目的，从而去挖掘用户在付费路径下的诉求点，根据诉求点找到付费升级的触点。这里我们罗列了用户阅读产品的路径。 

 03 观察用户核心需求是否被满足 

 用户在每个场景下都会有“痛点”和“痒点”。比如在阅读前，核心目是想快点看到漫画内容；阅读过程中，想要及时宣泄对漫画的故事情节的感受；阅读后，希望找到更多相关内容或者能够和内容有更多的互动。目前产品在这三个关键的路径节点都存在一些问题，阅读前对于付费缺乏正向引导，阅读过程中互相行为较少，阅读后没有更多延展内容可供消费等。 

 04 洞察设计切入点  

根据用户在阅读 “前 中 后” 关键路径的节点的不同情绪反馈，我们可以做出找到相应情感满足切入点，并且制定解决方案 

 05 制定设计方案  

将之前找到的设计情感切入点用交互和视觉的形式呈现出来，尽可能完整的表达清晰。下面展示是关于付费升级优化的完整视频DEMO。整个方案采用趣味情感化形式为核心设计思路，逐步去引导用户付费。让用户在趣味互动中完成产品的商业转化目标。 

https://v.youku.com/v_show/id_XNDM0NDg1MzY2MA==.html

 二. 设计呈现的“差异化”   

视觉呈现是设计师们都比较擅长的工作，但不同专业高度要求下方案最终呈现出的效果是完全不一样的。好的设计方案，需要在设计上做出明显的“差异化”，这里的差异化是指要区别于常规输出一般的水平。差异化的可以从多个点入手：

优质的设计美感：

美感是作为设计师首先需要培养的技能之一，也是在后续职业生涯的一直需要用到的技能。设计师被神职化的很大一个原因就是因为设计师的美感比一般人要好，有懂得欣赏美、鉴别美、以及创造美的能力。单一从视觉层面，设计作品是合格品还是精品，最终取决于画面的精美程度。项目不分大小，再小的一个项目都可以做出精致品质，这也是体现设计师专业度的核心衡量之一。

完整设计思路：

设计方案的完整性也能够很好的设计师专业度的差异化，几张图的设计稿和一个有完整设计思路的设计方案在品质上自然是明显差别的。设计师不光需要将设计呈现出来，更需要有严谨的设计思路并且表达出来让受众到你的设计想法。设计前期分析、中期执行、后期落地以及迭代优化，能够让设计师有意识的锻炼和提升自己的设计思维，对于设计师能力提升有必然的帮助。 

独特创意：

设计差异化呈现上，创意是一个非常好的切入点。行业大趋势的前提下，现在同类产品越来越趋于同质化，受众使用产品的时候都会有一些常规认知，关于功能的、交互操作的、内容组成的等等，淘宝和京东、大众和美团、甚至QQ音乐和网易音乐在产品使用体验上都有高度重合的地方，这些已经在用户心智中形成习以为常的认知感受。如果能够在用户的常规认知里，用创意手法呈现出超出他们预期的内容使其惊喜，产品设计就会有明显差异化体现。 

善用情感化：

具备美感的设计能让作品看起来有高级感，但更为高级且有效的是能够引起用户情感共鸣的设计。设计是主观的，对于设计每个人都有自己的想法，也正是因为主观的设计感受，能让设计在情感化打造方面可以有很多的尝试方向。能够引起受众主观情感上的共鸣和认同的设计，会形成产品的核心记忆点之一。设计师对于情感化设计往往会有一些误区，认为图形可爱，色彩羡慕，动效流畅且能够形成一套视觉体系，就能够算情感设计。真正的情感设计是需要从用户角度出发，挖掘用户的认知领域和喜欢，从而去进行符合用户情感诉求的呈现。 

三. 方案推动的效能管理 

设计方案输出只是整个产品生产流程中的一个核心环节，产品上线后体验如何最终取决于落地实现的程度。在方案落地支持过程中，效率协调和实现能力是保证设计方案贯彻一致执行的关键因素：

 协作  

产品设计师工作协调分为内部协作和外部协作。内部协作即设计师之间的沟通协同，主要内容是如何保持设计语言一致性，除了制定设计规范，还可以建立公共控件库，线上调用。控件库能够使设计师协作无学习成本，设计师输出设计稿效率也能够大大提升，同时保一致性。

外部协作主要是和下游的技术同事直接的工作对接，设计方案的交接方式以及开发获取信息的效率很关键。在开发接收设计方案的时候，尽能力降低获取成本以及理解成本。比如设计稿的标注，在标注上设计师一般会花很长时间，开发也需要逐步查看，偶尔还会有标注遗漏的地方。我们团队会直接采用插件，设计稿及时同步，并且开发可以自己随时查看每个元素的标注信息，便捷。

这里推荐两款协调软件：一款是InVision可以在sketch里进行控件协同调用，所有想用的元素直接源文件调用，不需要再问同事要源文件！另一款是Zeplin技术同学可以直接查看元素属性以及间距等，设计师解放双手不再需要标注！

官网链接： 

https://login.invisionapp.com/auth/sign-in   

https://zeplin.io/

实现能力   

专业技术之间的壁垒，也会成为设计方案实现的阻力。同样的界面，设计人员用设计软件实现，技术人员用逻辑代码实现，实现的方式和成本存在很大的差异性，所以往往设计师认为很简单的需求在开发层面的确非常难实现。当然，不是所有需求都是无解的，设计师在技术实现层面还是可以做一些事情：

01 方案前置沟通

设计一个新的功能的时候，如果有非常规的设计方案，可以提前和技术人员沟通实现的难易程度，让技术人员有前期预判和预演的时间。并且，可以将设计做成简易DEMO方便技术人员快速理解，避免双方存在信息不对等的情况。

02 搭建开发控件库

开发控件库和设计规范一样，是最基础但应用最为频繁的模块儿。开发控件库可以将最基础的元素形成固有规范，所有开发实现都用同一套规范，以确保实现的高度一致性，同时也能够提升实现效率和设计还原。设计可以辅助开发一起制定开发控件库，确保控件库和设计规格的一致性。

03 寻求技术语言共通性

尽量将设计方案转化为技术能够理解和复用的形式进行对接。除了静态设计稿的标注，设计和技术实现最大的难点在于动态交互的实现上，对于动态设计，将设计方案转换为代码文件交付给技术实现，这样能确保功能的正常实现同时减少后期设计还原性的偏差。

以上初步总结的关于产品设计师在设计过程中从前期产品规划到中期设计执行再到后期开发落地应该注意的一些核心点：

第一条，设计方案既要满足产品目标又同时要兼顾用户体验；

第二条，优秀的设计师，会保持设计方案的“差异化”；

第三条，设计师职责除了确保设计方案完整性，更重要的是推动设计方案的完整落地。

在产品设计过程中，设计师需要关注还有很多关键点，这里也欢迎大家一起补充交流，正是这些关键点，将设计师的思维逐步打开，使其成为一个具有全链路思维的设计人才。 

文章来源：UI中国

交互手势是用户操作的重要部分，交互手势的设计好坏非常影响用户体验，那么，交互手势的设计上对于容错性和逻辑性需要注意什么？

随着用户体验被愈发的重视，更多的 APP 偏向于使用多手势优化用户的操作流程，降低使用阻力。

点击某个确定的按钮的手势操作虽然被普遍使用并被用户熟知，但是增加更快捷的手势操作可以大大增大操作热区，提高操作效率，如下图。

然而，我们可以发现由于不同产品的设计师对于用户体验的理解不同、交互层面的思考不同，导致设计的交互手势也不同。

有时同一种操作在不同的 APP 中交互手势也是不统一的，这无疑增加了用户的学习成本和记忆成本。

举个例子，iOS 端的得到和有书的播放页的打开和关闭方式。

得到有两种方式打开和关闭页面，用户可以通过点击控件或上滑控件打开播放页，通过点击收起按钮或下拉页面关闭播放页。但是有书只有一种方式打开和关闭，用户只能通过点击控件打开播放页，通过点击返回图标关闭播放页。

这让习惯了使用得到的我去使用有书时，感觉非常别扭，每次都尝试用得到的手势去操作但是都失败了，失败后我下一次并没有记住仍然用手势去操作，如此反复令我相当沮丧。

容错性

容错性是一个很大的话题，今天我们仅仅在交互手势层面上讨论。

上面的例子中，有书并没有设计滑动手势去打开和关闭播放页，那么我以我的经验去进行的滑动滑操作在有书这个产品中就是错误的和不被产品识别的。但是这种手势又广泛存在于大量的音频播放 APP 中，如喜马拉雅、荔枝 FM 等。

一旦用户从这些 APP 迁移到了有书，本来养成的操作习惯在有书就失效了，用户就会感觉“这个 APP 很难用，用起来很不舒服”，进而可能放弃有书转而投向其他产品怀抱。

与手势设计类似，这也是为什么现在的同种类型的 APP 的信息架构设计越来越同质化，当我们打开淘宝、天猫、京东时我们有时感觉就像是同一个 APP ，本质上也是为了降低用户的迁移、记忆和学习成本。

如下图所示，提高手势的容错性对用户的意义。

很多优秀的产品考虑到了上述问题，设计了多手势来优化用户体验。

举个例子，在 APP Store 的首页点击一个推荐卡片后进入详情页，由于详情页是直接由卡片放大转场的，不同于传统的新页面右侧进入和从底部弹出。

在用户的使用习惯和认知中新页面如果从右侧进入就可以通过右滑返回，从底部弹出的话就可以下拉返回。因此，当用户面对卡片放大进入新页面这种全新交互时可能会疑惑如何返回，对此理解不同的用户可能会尝试右滑，也可能尝试下拉。

APP Store 的设计在此就有很好的容错性，用户可以通过三种方式返回首页，分别是、右滑返回、下拉返回和点击叉号返回，这不但降低了用户的记忆和学习成本，也便于不同习惯的用户使用。

针对不同的场景，手势的使用也会有不同。

一个很好的案例是知乎的评论：知乎的评论的关闭方式有三种，分别是下拉、右滑和点击叉号。

用户观看评论的场景有两种，第一种是只想看一下精选评论然后关闭，第二种是被评论吸引后一直往下看。当用户单手操作不方便点击叉号时，下拉对应的是第一种用户；右滑对应的是第二种用户，不管用户看了多少屏的评论，随时可以通过右滑关闭评论（因为用户翻阅了很多屏评论后需要下拉到第一条评论时，下拉关闭评论手势才会生效，所以第二种用户一般不使用下拉去关闭评论）。

可能你会心生疑惑：“第一种用户也可以使用右滑来关闭评论呀”，确实可以，但是对于人的操作习惯来说，上下滑动会比左右滑动更方便。

还值得讨论的是苹果自 iPhone 6s 开始加入的新交互方式 3D Touch，它允许用户通过更大力度的重按呼出情景菜单快捷地使用高频功能而不用先打开 APP，对于追求效率的用户来说简直不要更方便，但是对于不支持 3D Touch 的机型则无法使用情景菜单。

因此，在生活中我发现这样的现象，很多使用惯了3D Touch 的用户换到无 3D Touch 的苹果机型后很不习惯，总是尝试去重按但是是无效的。

其实在很多安卓手机上也有情景菜单这一功能，它巧妙地将卸载也加到了情景菜单中，因此用户只需要通过长按就可以获得所有需要的功能，而不是像苹果那样长按是卸载而重按是情景菜单。

我猜测苹果为了适配所有机型，提高容错性，从今年的发布会的 iPhone 11 和iPhone 11 pro 开始，取消了 3D Touch，转而使用 Haptic Touch （有震动反馈的长按）代替。当你长按某个图标时，感受到震动后松开，即可呼出二级菜单；如果震动后仍不松开，则进入到卸载 APP 时的抖动状态，使得之后的即使不支持 3D Touch的机型可以使用便捷的情景菜单了。

对于不支持 3D Touch 的老款机型会不会在 iOS 13 更新后也可以使用 Haptic Touch 呢？

如果一致统一的话，容错性将大大提高，我们将拭目以待。

不仅仅是 iOS ，Android 的版本 Android 10经历了 6 个测试版迭代后正式发布，我们发现交互手势是 Android 10 的一个巨大亮点。Android 10 在第三版内测系统开始引入全局手势操作，用户启用后，屏幕底部便不会再出现虚拟按键和导航栏，只会剩下一个指示条，上滑返回主屏、侧滑返回上一层的操作逻辑也均和 iOS 保持一致。

这可能标志着安卓手机一直以来在国内各家厂商的各种创新手势的割裂生态中即将重归统一，并和 iOS 保持一致。

这种妥协将大大提高在用户使用一款新安卓手机时的容错性，同时降低了今后用户在两大系统之间的迁移成本。

逻辑性

再谈谈逻辑性，在交互手势的层面上，如果用户能够通过某个手势进行某个操作后，按照逻辑，用户也可以通过反向的手势或对应的手势进行逆向操作。

比如，在微信首页下拉调出小程序页面，之后可以通过上拉返回首页。点击加号呼出更多操作，再次点击加号收起更多操作。

如果违背了用户的心理模型和逻辑性，用户就会感觉到混乱和不适。

这里举一个反例， Uki 的个人主页可以通过点击或下拉底部的固定底板收起更多信息，但是收起后只能通过点击展开更多个人信息而不能上拉，不符合逻辑与用户的心理模型。

如下图所示，逻辑性对用户的意义。

有的时候，我们会发现为了提高容错性，我们会牺牲一部分逻辑性。

就像上文提到的知乎关闭评论弹出框，逻辑上它是从底部弹出的，但是不但能够下拉关闭还可以右滑关闭。尽管右滑关闭有些违背用户的心理模型，但是确实给用户带来了很多操作上的便捷。

如何设计

1. 是否需要加入多手势操作的考虑因素

我们需要考虑的因素包括使用频率、危险程度和特殊体验。

1. 使用频率：当一个功能的使用频率足够高时，我们加入多手势操作去提高用户操作效率才是有意义的。一个低频的功能的特殊手势操作很容易被用户遗忘。
2. 危险程度：如果一个操作不可撤销且存在危险性质，我们最好不要加入多手势操作。此时我们需要用户更加专注，如果加入多手势操作可能会增加误操作的概率。
3. 特殊体验：当我们需要加入特殊的模拟体验时，此时我们可以加入多手势操作。如探探左滑无感右滑喜欢，给用户带来的“翻牌子”感觉是点击操作无法替代的。QQ 阅读下拉拟物绳灯进行日间和夜间模式切换，这种存在我们记忆中的交互方式能够唤起我们的情感。

2. 评估所选手势的考虑因素

1）考虑不同平台的硬件系统和操作系统特性

由于硬件与操作系统差异，iOS 系统支持很多手势，但是安卓系统在手势支持方面就不如 iOS 丰富。

安卓硬件设备的差异比较大，不同安卓手机厂商会在安卓系统的基础上自定义系统的手势操作，因此对于手势的支持也有较大的差异。对于这种情况我们需要熟悉相应平台的规范，做到心中有数。

2）考虑所选的手势的学习成本和记忆成本，用户是否已经被教育

如下图所示，尽管设备支持的手势数量多不胜数，但是日常使用 APP 时，大部分用户习惯使用的手势很少，比如单击、双击、滑动、上拉、下拉、双指扩张和收缩等。除此之外的手势教育成本和学习成本很高。

一般比较通用的功能是没有必要在此处创新的，但是如果一些特殊的操作确实需要加入时，我们就需要考虑下面的问题。

a. 如果没有教育成熟，考虑加入教学或搭配简易的操作方式

对于我们需要加入的手势操作当前用户并未被教育成熟时，我们需要考虑加入手势教学，具体的手势教学类型下一部分会详细讨论。

然而，大部分情况下用户的记忆是短期的，教学内容可能会被快速遗忘，下次用户使用 APP 时仍然不会使用特殊手势。此时我们应该将一些比较难以记忆的手势操作搭配一个简单的手势操作。

比如 QQ 阅读的下拉拟物绳灯切换夜间模式的手势操作设计，其考虑到了有些用户在现实生活中并未见过拟物绳灯，并不知道是要进行下拉才能触发操作。因此，QQ 阅读贴心地搭配了一个简单的点击操作，用户通过点击绳灯也可以切换夜间模式，如下图。

b. 考虑所选手势是否可能导致冲突和误操作，如果导致了，考虑如何避免和折中

最常见的手势冲突情况就是 APP 的手势与操作系统的全局手势冲突。

解决方案有两个，一是避免设计与全局手势一致的手势操作，例如 iOS 的在屏幕边缘右滑返回、全面屏机型的底部上滑退出应用等全局手势操作；二是仍然设计与全局手势冲突的操作，但是将全局手势部分禁用或以其他的方式区分开。

如下图有书播放页的案例，由于进度条滑动控件过于靠左，导致使用 iOS 全局右滑返回手势时有时会产生误操作，即本来想要右滑返回却不小心滑动了进度条。

这种情况下我们可以标注一个右滑手势禁用区域给开发工程师说明情况，将此情况避免掉即可。

误操作指的是，我们设计的手势操作与 APP 内的其他操作或系统全局手势操作接近导致用户触发了非预期的操作。比如 iOS 端的知乎被吐槽的一个右滑返回手势操作，经过研究发现，由于 iOS 端的知乎在浏览回答的页面设计的右滑返回的热区过大，导致用户上滑浏览的时候如果手指的滑动角度变化幅度过大一不小心就触发了右滑返回，再次进入回答后又需要翻页很久才能找到之前离开的地方，很影响体验。

我觉得知乎可以减少热区，将热区调整为 iOS 全局的右滑返回区域即可，如下图所示。

当然，产品设计需要平衡与取舍，如果减少了热区是否会影响其他用户的体验还需要考虑和调研，两者并无绝对的对错

3. 让用户了解并使用新手势

当新手势无法直接让用户感知时，我们需要加入一些手势教学帮助用户快速上手使用。

1）手势教学方式

a. 浮层和动画引导使用静态或动态的手势图片或气泡示例告诉用户使用哪种手势进行操作

相比于静态，动态比静态更为直观和易学。

b. 内容隐喻通过微妙的视觉线索暗示用户此处可以通过某种手势进行操作

由于教学内容难免具有干扰性，对于高级用户来说是不必要的，但是对于初级用户又是必要的，因此以这种内容暗示的方式使教学极为轻量化，在低干扰的情况下使得用户学习了手势操作。

如下图，哔哩哔哩在打开第一篇文章时会平移显示下一篇文章的框架，暗示用户可以通过左右滑动切换文章。

再比如陌陌在打开点点功能时，会在用户进入页面的时候播放一个动画，暗示有很多卡片叠加在了一起，用户可以通过滑动切换卡片。

2）教学的出现时机

a. 操作前当产品中设计了不容易感知的新手势，在用户操作前，通过教学让用户了解和学习新的手势。

b. 错误操作后对于一些与用户的心理模型和习惯不一致的手势，提前预测用户可能输入的错误手势，在用户错误操作后进行提示，规范用户的操作方式。

如下图，由于知乎旧版本是通过左右滑动切换回答的，新版本调整为上下滑动后，需要纠正用户使用习惯。因此，当用户仍然使用左右滑动时，会出现浮层提示用户正确的手势进行教学。

结语

以上是日常思考和总结，有不恰当之处欢迎指出。希望本文在大家进行手势设计的过程中能够帮助做出合理的决策。

文章来源：人人都是产品经理 

Sandy现任阿里影业—淘票票体验设计专家，2015年加入阿里巴巴，深耕B端行业产品，服务于电影产业链中的投资、宣发等角色。2017年起接触C端用户产品，推行价值导向和问题导向。2019年开始实践线上线下全链路设计。

活动笔记：

阿里影业的服务涉及的面很广，涉及到b端与c端全流程的体验服务，包括面对片方的制作和宣发、发行、乃至面向用户的售卖与放映，在每个节点都有涉及。而淘票票，经历了四年的产品迭代，以一年一个版本的速度的进行优化。15年的理念是做一个好用的购票工具，16年新增了营销，17年加强营销，18年新赛道探索。到了2019年，改版应该进行新的思考：怎样做？做什么？怎么做？做对了吗？

此次淘票票9.0版本是根据用户现有的习惯与市场的变化，由设计师发起的一次自下而上推进的改版。以下是淘票票9.0的设计策略与设计目标：

1. 内容设计赋能
   新服务，扩展观影决策节点，帮助用户发现好电影。
2. 购票流程体验打磨
   新体验，解读用户行为，体验走查，打磨核心购票链路体验。
3. 年轻化
   新用户，关注用户群体的变化，搜索年轻用户群的品牌认知，提升年轻用户满意度。

接下来将对三点设计策略进行逐一的讲解。

1. 新服务—内容的赋能

根据内容类型和场景进行划分，结合内容特点和用户喜好，打造全场景运营，例如提供影讯、通稿、片单、榜单、热点、解读、文章和活动等等多元化内容。通过提供不同的内容展现给用户，将内容进行解构、把触达的场景进行细化、优化设计的表达，从而达到帮助用户可以更好的理解电影的目的。

2. 新体验—打磨购票流程的体验设计

设计前，首先应当熟知两种设计思维导向：

• A.当设计目标是帮助企业完成商业目标时，是以价值为导向。
• B.当设计目标是为了提升用户体验，则是以思维为导向、问题为导向。

而这次9.0淘票票改版采用的是以问题为导向，期间经历了五个流程：

2.1 找问题

首先出去找问题，找问题的方法有很多，如：用户研究、定性、定量、业务数据和体验走查，收集业务、用户、客满不同视角的疑似问题。

• 会通过支付宝、淘宝、百度糯米来比较价格高低，对比价格需要反复推出
• 进入不同的影院和场次，不太方便
• 希望看过的电影能够产生一些纪念价值
• 不清楚80元和40元的座位有什么区别
• 不明确片尾是否有彩蛋
• 购票平台的评分对自己没有参考价值
• 电影院的地址、停车场是否免费等信息不够准确
• 买完票到取票之间，需要反复确认订单信息、分享订单信息，但是订单入口
• 藏得有些深
• …

2.2 看现象

找完问题之后，基于数据的支撑，去看用户有哪些习惯的变化，看到目前的现象后再进行数据解读。

• 影院页和选座页返回率高
• 越来越多的用户购买当日的电影票
• 多数用户选择更短的买票路径
• 大多数用户去过的电影院在3家以内
• …

2.3 定位问题

基于使用场景和使用效率，进一步定位问题所在。

2.4 分析原因

分析出症结，以便推进最终的解题环节。

• 症结1：平台服务与用户决策心理脱节
  现有的流程是线状的：选影片-选影院-选场次-选座-下单。但是用户实际的心理决策是网状的，用户可能在选时间的时候考虑影评好不好，会在选场次的时候考虑价格是不是合理的。
  
• 症结2：认知过载
  理想状态是在传达信息后，在用户感知、接收和决策后，希望得到用户方的正反馈，但是现实往往是用户认为认知负担过重，反馈失效的情况。其中信息传达、颜色的设置最直观的感受是“乱”。决策流程上最直观的感受是“打扰”，提醒用户是否确定要买某时候的票、提醒用户确定退出选座页不保留刚才选的座位，所有的提示的设计，都是采用一种打扰的方式进行询问的。
  

2.5 解题

解题1：场景化探索。

以解决问题为目标，达到优化用户体验的目的，对场景进行预判、探索，把场景分为三个典型的场景：

• 典型场景1：短时决策–例如距离开场时间较短，对价格不敏感，希望找到距离合适的影院，快速完成购票决定。
• 典型场景2：追求体验–对影厅的要求较高，希望找到放映效果最好的影厅。
• 典型场景3：价格敏感–找到符合自己价格预期的影院。

解决：针对第一种场景，选坐页可以快速找到选场次的功能，淘票票提供常去影院、附近影院的选择，减少用户决策时间。针对第二种场景，部分观影者不知道价格更高的IMAX厅、杜比厅的观影效果，价格比普通厅贵了50块钱，那么这个钱值在哪？淘票票使用视觉映射和科普的手段，例如当点击进入杜比厅后，下拉可以呼出信息，了解相关的影厅，给予科普；而且界面设计不同，更贵的影厅视觉效果好，界面上也提供用户更强的视觉冲击。

解题2：用户视角信息重构，进行信息降噪，减少认知负担

认知负担=信息呈现类型x信息量

以上公式可以看出，假设设认知负担为定值，当信息量增多的时候，需要减少信息呈现类型，适当进行信息降噪与信息结构化。降噪是把想要突出的信息更加突出；信息结构化是把同类型的信息以结构化的呈现出来，让用户自然对信息产生亲密性。

对于信息传达，改变之前比较打扰的提示弹窗，现在淘票票会把所有信息都放在页面中，用一种更轻量的方式提示用户，不再打扰用户。信息重构则是把需要用户确认的信息放在最头部，例如退票、改票，其次界面罗列的是优惠信息，最后才是影城卡营销和卖小食的信息区域。新旧改版对比图很好呈现出淘票票有效减少认知负担所做的优化。

3. 新用户—提升年轻用户群对品牌认知

基于调研，淘票票的用户群体趋近年轻化。改版中所制作情绪版、图标、元素、字号、空间结构等视觉语言，注重和品牌元素的结合，产生出新的视觉语言与品牌形象，从而更加贴近年轻人的心理与喜好。

4. 体验度量

根据heart模型进行设置，选出适合9.0版本的衡量维度：S，T，A。以体验目标出发，符合业务目标进行探索。不一样的体验目标使用不一样的度量方法。对于内容而言，需要衡量的是用户的接受度，用户需要看到它，接受它，并且需要知道用户是否觉得有用。而对于核心购票流程，该流程则是比较偏向工具，度量方式则是任务完成度、完成任务时所花费的时长、信息有没有被有效的传达给用户等来衡量的。最后对于视觉方向，用户的想法会比较主观，通过满意度和推荐度来衡量。

现场问答：

提问者1：观影者通常会在朋友圈、豆瓣和推荐来决定要看的影片，基本不会在淘票票上寻找值得看的影片，为什么淘票票会做这方面的探索？为什么要做内容决策这件事？

回答：从想看电影到下单的过程哪个地方淘票票是没有做好的、做到的，根据定性调研，发现一半以上用户都不会在淘票票上进行决策。但是淘票票还是希望尝试一下，希望用户可以在淘票票上完成完整的购票观影体验。从数据显示，用户心智还是不好但是有一些提升。而且豆瓣经历了10年从pc到app，保留了用户的历史等数据，没有办法让用户直接转到淘票票进行观影决策，这也不是淘票票希望看到的。淘票票也希望可以和竞品和合作方去提升观影决策，达到共赢的目的。

提问者2：淘票票改版之后，有一个衡量它的改版效果S、T、A的度，有没有考虑要做NPS？

回答：淘票票一直有在做，从这次改版之后来，淘票票所有用户群指标提升了应该有五个百分点，然后年轻用户的百分点在八个以上。NPS是一个非常关键的衡量用户满意度的指标。

追问：NPS是不是适合淘票票这个产品？还是适合于所以互联网产品？

回答：NPS在集团内它的重视度是很高，基本上阿里系所有的产品都会有指标。

提问者3：我之前是淘票票的用户，曾经用过淘票票做观影决策，看下面的电影评价，结果发现电影评价是虚高的，就是说其实电影没有那么好，但是评论会倾向性的选择一个好的评论放在下面，经过这次经验之后，就再也不用淘票票作为观影决策了。想了解现在淘票票的评论机制，它是怎么个呈现的方式？是不是会优先选择就是比较好的评论放在首评？或者是有一些什么样的计算方式？另一方面对于现在的评论失真的这种情况，有没有想到一些改进的措施？是最近有没有做过一些改版之类的，就是关于这种内容方面的？除了刚才讲的那些界面，视觉方面的，想了解内容方面有没有一些提升？

回答：第一点，用户群的不同。对于影评这个来决策，淘票票可能跟豆瓣用户群有非常大的差异，豆瓣是影迷聚集地，爱电影这帮人的一个粉丝聚集地，圈子比较小，想要进入这个圈子有一定的成本。但是像淘票票它服务的是大众场景，服务的有外卖小哥，也有大城市去打工的用户，也有三四线在国企里那种的员工，淘票票服务的用户是大众的，所以对于评分虚高这件事，不是说它好或者不好，也就是不能单纯的绝对说好还是不好，可能大众的心智就是这样的。用户不像一个资深影迷，看到速度与激情会认为是大烂片，可能反而觉得好，非常值得去看。第二点，关于这种影评的一个分发策略涉及到产品策略，不是很方便讲。但是淘票票在这方面一直有优化的，并且现在也是在持续优化，希望影评可以真正为用户去提供这个观影决策。第三点，淘票票的用户其实不只是c端用户，它还有还有影院还有片方，但是水军应该不会有，至少淘票票平台是非常不鼓励这种情况，而且会有一定的反作弊、返水的机制。

提问者4：因为是以设计推动的一次改版，想了解一下推动的过程？第一就是因为平时改版都是产品的来做的，那这一次由设计来去推动的话，那设计跟产品之间的这个协作关系是什么样的？然后改版历时半年，是淘票票的设计历程中是常态吗？如果不是的话，平常的这个改版的节奏是什么样的？

回答：第一点，设计要不断的去跟产品、运营沟通，去跟不同角色沟通，沟通可能是最重要的一点。当所有人都达成共识了，确实有这样的问题需要改，那全部门所有人就会去团结，去把这个事情搞出来。搞出来之后再去向上一层一层的去向上汇报。汇报的可能要经过很多轮，不断有反馈的意见下来，因为本身视角输入的也不够全，接受到的声音也没有上游接触的多，所以团队会去接受意见，然后重新的进行。一轮review下来大概三四个月的时间，然后再去跟开发团队沟通为什么要去升级设计语言，怎么样去帮开发提效？怎么在下一次10.0改版的时候更容易。第二点，团队第一次历时半年进行改版，之前没有停下脚步来去深耕用户体验，所以有一些坑或者一些弯路。平常的改版中基本上是两周发一个版本，非常小步快跑的。对于设计如何跟产品团队去协作？刚刚也有讲过，达成共识之后，然后把这个事儿做起来，提需求、进版本，从需求池里评估需求优先级进版本。交互设计跟产品经理这个角色没有绝对的一个边界，可能都是去不断的去触碰，只要去配合合作的好，把这个产品去做出来，不用管处在一个什么样的一个岗位。

提问者5：最开始的时候有问到淘票票和猫眼之间的一些对比，想了解在改版完之后和平时的工作中，是怎么会去了解和竞品？怎么去比较？有没有一些关注的量化的一些指标？

回答：不管服务于什么样的产品，都会做竞品调研。会关注市场的变化、竞品的变化。对于设计团队来说，其实主要的是关注的是用户行为、功能和视觉界面。包括上了哪些个新的功能？在不同的渠道是怎么样去运作的？运营思维是什么样子的？淘票票团队有在研究竞品，有在做竞品的一个分析，衡量的指标也主要是满意度、推荐度，因为没有办法去看竞品的数据，只能通过用户反馈去看竞品跟淘票票的差距。

 文章来源:uxren

有些产品经理会陷入这种误区——需求评审做完了，自己就可以放羊不管了。而本文则认为需求评审完，产品经理还要做这六件事。

需求评审完，产品经理还要干的6件事

1. 确认需求评审的遗留问题并同步各方

2. 制定详细&责任到人的项目计划

3. 完成文案设计

4. 按照项目计划，协同各方，往前推进，关键环节必须与各方确认。关键环节包括：

• 1）交互评审
• 2）视觉评审
• 3）推进联调进度
• 4）推进测试进度
• 5）项目showcase
• 6）项目发布

5. 准备项目review

6. 开始下个需求的方案设计和需求文档准备

这六件事具体怎么做？

产品经理A：需求终于评审完了。有种放飞的感觉，可以休假，去浪了！

产品经理B：你说真的吗？为什么我评审完，还一直在被开发、测试、法务、财务穷追不舍？

产品经理C：你说真的吗？为什么我评审完，从来都是我在穷追不舍开发、测试、法务、财务？

产品经理D：你们开玩笑的吧？就我这么惨！我不但要紧追不舍开发、法务、测试、法务、财务，还要被老板、被客户穷追不舍。

产品经理A、B、C：哥们，来讲讲，最喜欢听惨兮兮的故事了。你的伤痛最能抚平我的内心。

产品经理D：好吧。需求评审只讲清楚了产品的骨架、细节，让各方开始投资源。评审完，产品经理还有一堆事要推进，没法放羊。

要跟的事情主要有下面6件：

1. 确认需求评审的遗留问题并同步各方

需求评审总有一些遗留问题要进一步确认，而后同步给各方。我不是圣人，有时候有些问题或者细节没想到，评审的时候，大家提出来了，得赶快明确。

有时候需求评审中还有很大的bug没想到，必须快速解决，要在开发没动工前，都捋顺。要不然变成需求变更，或者上线后被推倒重来，欲哭无泪。

我这种求生欲这么强，也没人罩着的，必须狠命把需求做到95分以上。100分也不太敢说，毕竟众口难调。

2. 制定详细&责任到人的项目计划

产品经理还得身兼项目管理，项目管理从来都是事有轻重、事无巨细，难以假手他人。虽然我会尽可能调动大家的积极性，让大家自驱管理项目，但还得牵扯不少精力。

项目管理的关键点：明确项目计划、关键节点、每个关键节点的负责人、验收方案。

比如什么时候交互评审、视觉评审、联调、showcase、发布？分别是谁主要牵头负责，哪些人需要参与。

为了防止项目延期，每个节点都还得提前赶。真是操碎了心。

3. 完成文案设计

文案从来不是随便写写。文案是和客户交流的重要途径，整几个客户看不懂的文案上去，后面客户咨询搞死人！

文案设计除了客户视角之外，也不是自己想怎么写就怎么写，还要和法务、客服团队沟通。因为文案被客户投诉的案例，又不是没有。

还有啊，我的产品有3种语言，简体中文、繁体中文、英文，虽然每种语言有专门的文案设计师，但得跟他们说清楚，也要花不少时间、精力。

当然，也有很多产品经理，不管文案这种小事。可我觉得文案体现了产品经理最基本的素养，是产品的底子。

4. 按照项目计划，协同各方，往前推进，关键环节必须确认

关键环节有6个：

1）交互评审

一般来说会由交互设计师发起，开发、测试、法务、财务都要参与。

这样能保证大家在说同一件事情，避免我要的是头牛，结果开发给了头驴。

如果设计师项目参与度低，交互评审还得我自己上。哪里缺人，我就得到哪补坑。

2）视觉评审

一般来说，交互和视觉评审会一起。

有时候项目很复杂，或者交互、视觉分工明确，那就得分开了。

通常由视觉设计师发起。同样，如果视觉设计师参与度低的话，我还是得补坑。

3）推进联调进度

联调是很容易扯皮的环节，大家来自不同域、不同职能团队，各有各的小九九，所以得盯着，避免联调成为坑王。

4）推进测试进度

进入到测试就意味着开发的七七八八了，当然有时候为了压缩项目周期，开发、测试会阶段性并行。

除了测试进度，还得关注测试发现的问题，可能开发还得返工，也可能会发现需求评审中大家都没有注意到的问题，得及时补救。

5）showcase

Showcase，说白了就是项目验收。

验收前，得先列出来要验收哪些内容，主流程、分支流程、逆向流程、重大关键节点。Showcase，也有可能发现新的问题，但基本上要避免在showcase环节发现重大问题，不然就得重大需求变更了。

showcase有时候由测试主导，有时候没资源，我得自己上。

6）项目发布

如果一路顺利，就该发布项目了。

项目发布计划虽然也是之前就定好的，但要考虑的方方面面也还挺多的，可以看之前的文章《项目发布要考虑的因素》。

总而言之，要和各方沟通好，要保证项目顺利发布呦。

5. 准备项目review

项目终于上线了，可我得天天得看客户反馈，看数据，跟客户聊，跟业务聊，准备复盘review。

产品狗似乎永远都在准备复盘、复盘中、复盘后反思的路上。

6. 开始下个需求的方案设计和需求文档

项目通常是并行的。在需求评审完后，我已经开始下一个需求的研究、设计了。

开发资源从上一个需求释放出来的时候，产品经理肯定得把下一个需求方案设计好，开始新的需求评审，妥妥的做好资源衔接。资源一旦释放出来，下次想要资源，难上加难啊。

产品也需要持续迭代，让客户感受到，我们的产品在成长、进步，给人希望。

文章来源：人人都是产品经理

区分取消与关闭，可以很大程度上避免丢失用户已操作的内容。在关闭视图之前保存用户的更改，使用文本标签而不是「X」图标，并在破坏性操作之前提供确认对话框。

让人迷惑的「X」图标

很久以前，「X」这个符号是用在地图上，标记「宝藏的藏身地」。但在今天的数字化界面中，「X」符号不再用来标记位置，而是被用来取消进程，或者关闭某个临时页面/弹框。但是如何确定「X」代表的是「取消」 还是「关闭」？有的时候可以确定，有时却模糊不清难以界定。

其实，主要的问题在于「X」图标缺少了文本标签。当同一个图标在不同的界面，却代表不同的含义，该图标的可用性就会受到影响，因为用户判断不了到底是什么含义。

为什么要区分「取消」与「关闭」

当用户单击/点击「X」按钮来关闭模态弹框或视图时，系统会完全取消该过程并清空之前所有操作，这让人沮丧，甚至抓狂。因为用户通常认为「X」图标表示取消或者关闭，所以区分这两种可能性对于交互的成功至关重要。

在某些情况下，区分取消 or 关闭并不重要。当一个弹窗占据你的大部分屏幕时，点击「X」按钮（尽可能快地），既可以关闭该模态，也可以取消它可能触发的任何进程。

但是，如果页面中包含正在运行的计时器，正在播放的音频，正在选择多个选项标签，或其他类型未保存的内容，那就很有必要说明「X」图标所代表的意义。因为用户可能打算让计时器或音频继续运行，或者希望立刻应用这些选好的选项标签，或保存正在进行的工作，同时希望关闭该视图继续其他操作。

例如：丝芙兰在结账过程中，使用模态窗口来展示用户可以添加到购物车的免费商品。在以下示例中，单击「 ADD（添加）」按钮选择商品后， 该按钮直接被变成了「 Remove（移除）」，看起来似乎商品已经被添加到购物车中了。但是，实际上当用户单击右上角的「X」图标后，该商品并不在购物车中。他需要再重复这个步骤，最后点击「Done（完成）」按钮，商品才会被加入购物车。

Sephora：单击右上角的「X」会取消选择这些试用商品整个过程。用户必须先单击「ADD」，再单击「Done」才能将商品添加到购物车。

如何避免丢失用户正在操作的内容

要避免丢失用户正在操作的内容，首先需要确定用户的意图，是取消还是关闭，并提供明确的选项。有以下几种方法：

• 主动要求用户确认他们的意图；
• 使用明确的文本标签而不是模糊图标；
• 显示两个不同的按钮：「X」图标表示关闭视图（可以自动保存页面内容/操作），而「取消」则代表放弃该过程。

1. 要求确认

如果用户在已经执行操作的模态弹框或页面视图中，点击「X」图标，app 则可以在关闭视图之前，直接询问用户是否应用该操作，来确认其意图。此解决方案非常适合会破坏用户工作的破坏性取消操作。例如，过滤器视图可能会被意外关闭，并且关闭会导致用户丢失其选定的选项。

这个问题在移动端界面上很常见，因为过滤器视图占用了很大的屏幕空间，这使用户很难或不能判断是否已经应用了那些选择。为了防止这种潜在的错误，在关闭过滤器视图之前，跟用户确认是否要应用这些选择并关闭视图，抑或是清除这些选择。例如：下图中，当用户选择后，点击「X」图标时，Lowes 会出现如下确认弹框。

左 ：点击「X」图标或返回箭头，所有的选项都会被取消，并将用户带回上一个页面。右：点击「X」后，出现一个确认对话框，确认用户是应用还是取消筛选，然后再返回结果列表页。

同样，当用户关闭正在进行的课程时，语言学习应用Duolingo 会显示一个确认对话框，课程进行中不能中途离开，除非确认「退出」。至少，该 APP 向用户传达了这一限制，同时他们也可以选择「取消」来继续课程。点击「X」按钮将结束当前课程。为了防止出错，结束前会出现一个确认对话框。

缺点：

• 虽然确认对话框在避免「X」图标有歧义方面很有效，但它却添加了额外的步骤；
• 用户在按下「X」图标之前还是不知道它到底做了什么，代表什么意思，因此他们可能会对这个操作感到疑惑。

2. 使用文本标签

不要完全依赖对话框来让用户确认模糊的「X」图标，而是使用明确的文本标签。文本可以消除歧义，并清楚地传达将发生的操作：取消与关闭。

Yelp 的筛选页面在屏幕顶部提供了标有「Cancel（取消）」和「Reset（重制）」的按钮，在底部提供了一个大大的「Apply（应用）」按钮。类似地，Etsy 中的 Filters 视图提供了「Clear（清除）」和「Done（完成）」两个按钮。

注意：Etsy 使用「Done」而不是「Apply」，因为过滤器一经选择就可以被应用，而这里是关于开关切换与否的建议。

（左）Yelp：Cancel、Reset 和 Apply 这三个文本标签既直接又清晰，这样用户就不太可能不小心关闭视图而丢失他们过滤器中的选择。（右）Etsy：Clear 为用户取消提供了一种清晰的方式，而点击 Done 则返回到「产品列表」页，其中的选择已经应用。

3. 关闭并保存

如果必须使用「X」图标而不是文本标签（比如为了以节省空间，或者正在遵循团队的设计语言），请谨慎使用，并在用户完成前保存操作/内容。另外，可以提供一个单独的「取消」按钮，让用户在进程之外有一个紧急出口，并消除「X」在两种含义之间的歧义。

例如：Gmail 会自动保存在非模态窗口中填写的邮件信息到草稿（Drafts）。这样的好处是，用户在需要折叠或关闭该窗口时，仍然保存原来的内容以便于下次继续编辑。将鼠标悬停在消息窗口右上角的「X」图标上时，会显示一段提示：Save & Close（保存到草稿并关闭）。此外，点击窗口右下角的「垃圾桶」图标可以删除该邮件，这个图标离顶部的「保存和关闭」选项很远，可以防止用户误点。

Gmail：Hover 透露，「X」图标是用于关闭窗口而不是删除草稿，它允许用户保存并关闭消息窗口而不会丢失刚刚正在编辑的邮件。

对于长进程或倾向于在后台运行的进程（如计时器），默认自动保存也是一种很好的解决方案。

例如，Glow Baby 中，后台运行喂食或睡眠计时器时，用户还可以浏览 APP 的其他区域。因为这些计时器一般会运行很长一段时间。此功能还能让用户在 APP 中做其他的任务操作，例如记录之前换尿布的时间、浏览文章、逛论坛等。点击计时器视图中的「X」图标也只是关闭窗口并不会取消正在运行的计时器。

Glow Baby：（左）点击运行计时器视图中的「X」图标，在不停止计时器的情况下取消视图，从而允许用户继续使用 APP 记录其他类型的事件、参与社区讨论、阅读文章等。（中）运行计时器的状态显示在屏幕顶部的状态栏中。（右）在计时器暂停时点击「X」图标，弹出「放弃」或「取消」按钮以确认用户的真正意图。

请注意：在关闭前保存中间工作或维护正在进行的过程是主动的，但有时可能会与用户的意图相反。如果用户打算通过单击「X」按钮取消其选择，那自动应用这些选择可能会令人困惑和沮丧。

这就是为什么还必须有一个单独的「取消」按钮，给用户一个出口，而不是强迫他们必须关闭时自动保存。

结论

虽然「X」图标会造成模棱两可，而且经常导致可用性问题，但它不太可能马上从所有接口中消失。设计人员应该注意「X」图标的多重含义，消除「关闭」和「取消」之间的歧义，并提供确认对话框或自动保存等保护性措施，避免丢失任何用户正在操作的内容。

若存在疑问，请记住：先保存，再退出。

小思考

为什么手机验证码登录微信/淘宝时，验证码输入错误，二者都是用的模态对话框提示用户，而不是用 Toast 呢？

• 微信和淘宝的用户群体都很庞大，几乎横跨所有年龄层。Toast 出现又自动消失的交互体验，用户会感到不可控，尤其是对大龄、老龄的用户不够友好。
• 也有悖于 iOS 人机交互指南中提到的「用户控制」这一原则，我想这也是 iOS 设计语言没有 Toast 这种控件的原因之一吧。
• 而模态对话框虽然干扰性较强，但用户可以随时控制，在使用过程中是用户掌握主导权。

补充：Toast 这一控件，原是 Android 系统的控件。但自 Android 5.0 推出原质化设计后，Toast 就被弱化，而是将 Snackbar 作为官方推荐的控件。如今在 Material Design 中更是找不到 Toast 的踪影。主要原因还是 Snackbar 在交互友好性方面比 Toast 要好，例如：支持手势交互、支持与 CoordinatorLayout 联动等。

因为现在大多数的PM/交互/UI设计师，在设计产品的时候都是以iOS为基准 思考产品上的各种功能逻辑、交互状态，而很容易忽略了某些功能在Android里并不能“一稿适应两端”，部分产品差异在安卓上是不一样的。

所以本文就讲下Android和iOS 10大产品/交互差异，希望你在日后的产品设计时，可以考虑到更多层面的知识点（可能在某些安卓高级机型里并不通用）.

01 虚拟商品 支付规则和方式的不同

1. 支付规则

对在于一些虚拟商品的支付上，如vip会员、xx币，xx豆。iOS和Android就存在不同的支付规则：Android基本无限制，无抽成。而iOS限制比较多，而且要抽成大约30%的手续费。

举个例子：同样充值30元，Android端会得到300金币，而在iOS中，只有210金币。正因这个抽成规则的不同（没办法，这是苹果硬性规定的），才会出现各种平台的虚拟货币，在Android和iOS中的充值比例是不一样的，如快手：

所以对于虚拟商品在iOS端的抽成规则，在产品设计时一定得考虑清楚，因为这关系产品的商业和盈利模式。通常有2种解决思路：

A. 让用户承担30%的抽成

a. 同样的价格，iOS用户得到的商品少些

如同样充值30元，Android端会得到300金币，而在iOS中，只有210金币。像快抖音、陌陌等各种货币充值。

b. 同样的商品，iOS用户支付更高的费用

如3个月的vip会员，Android端定价是58元，iOS端则可以设为68元。如优酷、腾讯视频的vip会员价格。

B. 公司自己承担30%的抽成

如iOS端充值30元，公司实收21元，但iOS用户能得到和Android一样的300个金币（理论上是有这个解决思路，但现实中很少有公司去实现，毕竟抽成成本就摆在那里）.

另外还需要注意的是：因为抽成规则的不同，对于同一个ID的账户余额，在Android和iOS端中是不能通用的。因此在产品设计时需要将这个点告知用户，预防用户犯错、以及恶意刷币。

2. 支付方式

Android由于开源的特性，因此对接的都是第三方支付平台，如微信支付、支付宝、银联卡等。

而iOS出于系统的封闭性和安全性考虑，只能调用苹果自己的支付系统：登录APPle ID，然后用授权的支付方式（支付宝、银联卡）进行付款。

02 状态栏交互的不同

“状态栏”也就是我们手机界面最顶部的电池栏，它除了可以在不同背景里切换颜色外，在交互的触发上，Android和iOS中也各不相同。

• iOS：用户在Y轴滚动了很长内容时，点击状态栏可以快速回到初始位置。
• Android：无论用户滚动了多长内容，都是点击无任何效果。

虽然这一交互差异是iOS专有的，但它却启发我们一个新的设计思路：在必要的时候，状态栏可以为产品承载新的交互状态。如网易的LOFTER（iOS端），用户离开音乐播放界面时，状态栏就用于显示音乐信息和操作入口，方便用户在浏览其他内容时可以快速关闭音乐时，极大提升了用户的操作效率。

03 下载方式和状态的不同

这种大多应用于运营的“拉新”场景，为了能新用户得到好处（红包、优惠券、更好看的内容等）。通常会让新用户下载产品APP领取。而由于Android与iOS的下载方式不同，会带来不同的交互状态和产品逻辑。

Android

可以在当前页面（后台）下载，也可以在应用商店下载；过程中可以显示进度，且允许用户暂停下载；下载完成后调起安装页面，用户可以取消安装，也可以自动安装…

正因为Android下载软件的各种便捷性，所以才会带来各种交互状态：未下载、下载中、暂停中、已下载但未安装、已安装。这些都是交互设计师需要特别注意的，每个不同的状态背后都会不同的产品逻辑。

iOS

只能跳转到App Store里下载，所有下载流程和状态都是在那完成的，可以脱离开活动页面，相比于Android的下载方式就简单很多。跳转的方式可以是全屏幕，也可以是半屏。

04 软件更新方式的不同

Android

由于安卓的开源特性，当有新版本时都会提示用户更新，且每个产品内部都带有“版本更新”入口。而更新的方式可分2种：

1. 引导更新：弹出提示让用户更新APP，用户点击“更新”按钮前往应用商店更新、或者在当前页面更新并显示下载进度。
2. 强制更新：也是先提示用户更新，只不过用户点击“更新”按钮，即调起软件安装页面。（前提是产品已在用户处于wifi模式下，将安装包已下载完成）

iOS

而iOS端出于对用户体验的考虑，是禁止向用户提示版本更新信息的。这也是为什么绝大部分的iOS产品，都是没有“版本更新”入口的原因（像QQ、支付宝、百度网盘等大厂产品）。即使有，点击了也直接跳转到App Store查看版本情况。

且下载渠道都固定在App Store里。理所应当的，软件的更新方式也只能在App Store里进行，无法做到与Android的一样做到后台下载、后台更新。

05 文字发送指令 位置的不同

在手机键盘里输入文字时，iOS由于系统的限制，对文字的发送指令只能在键盘上来完成，因此iOS用户的交互操作都全部集中在键盘右下角。

而Android端就灵活很多，不仅可以在键盘上执行发送指令，也可以在输入栏/搜索栏周边新增操作入口。

06 退出浮层列表的不同

长按一张图片后，都会弹出一个列表浮层，因为iOS手机只有一个“Home键”而已，为方便用户退出浮层才增加了“取消”入口。

而Android手机本来就有“返回”虚拟键，安卓用户的退出/返回行为都习惯于通过虚拟键触发，所以多做一个“取消”的意义性不大。

07 删除方式的不同

iOS端一直教育着用户使用“左滑”删除列表信息，所有的删除功能都是支持“左滑”来实现的。

而Android系统大部分只能通过“长按”来触发编辑状态，其中就包括了删除功能。不过现在也有极少数的产品，正在逐渐打破这两端间的“删减”界限，比如网易邮箱（Android）就做到了左滑删除信息。

08 消息推送机制的不同

当我们第一次打开产品、允许了获取消息通知的权限后，所有的信息传输都会基于服务器进行推送。而两端在这块的推送机制又有所不同：

iOS

所有新信息都会实时推送到你的手机里，即使你关闭了软件，还是一样会收到提示。就算使你处于断网状态，信息也会先储存于苹果服务器，等你联网时再一次性把收到的信息推送给你。既释放手机内存，又不会让用户遗漏有新消息。

Android

而安卓则不同，你若退出了产品，数据的推送只有等你再次打开产品时，才会通知你有多少新信息。虽然减少了对用户的干扰性，但也增加了服务器数据储存的压力，还容易耽误用户接收新消息。

09 复制文字后，剪切板状态的不同

也就是我们手机的输入法键盘，在微信聊天内、手机短信里复制了一段内容后，由于Android与iOS的平台特性差异，会给两端用户带来了不同的交互差异。

iOS

复制完文字后，打开输入法键盘会显示来自剪切板的文字内容。用户只需点击，即可将文字复制在搜索栏、输入栏等需要文字填写的操作区域里，无需触发“粘贴”操作。

Android

而有些安卓机（如小米/锤子/乐视等)，无论你复制了什么信息（文字、数字、网址等），都很难实现输入法里的“剪切板”功能。用户需要触发“粘贴”功能，才能输入将刚刚的复制内容。

而对于特定的信息类型：如网址。用户复制网址往往都带有极强的目标性、搜索性，一些浏览器产品会预判用户这一操作行为，将复制的网址前置展示出来，以抵消Android端对于复制文字带来的系统限制。如QQ浏览器（安卓端）就有2种解法方法：

• 方法1：利用安卓系统的消息权限，在手机界面的顶部弹出网址栏提示，无论是在微信还是短信中，复制网址后都能快速地触达目标。
• 方法2：复制网址后打开搜索功能，会将网址自动定位并粘贴到搜索栏中，便于用户查询。

而UC和百度也有类似的解决办法：将复制后的广泛信息（文字/数字/网址/邮箱地址等等）嵌入在搜索框下方，用户点击就能搜索。

这也是一种妥当的解决方法，因为用户可复制的信息类型特别广泛、目标不是很清晰。无法准确判断出用户一定会有搜索诉求。所以才将复制后的信息放在搜索框下面，而不是自动粘贴到搜索框中，既考虑了用户目标，又兼顾了操作效率。

总结

以上就是Android与iOS的差异总结，若有描述得不当请多指教！下面是总结文件。

文章来源：人人都是产品经理

有理有据，有面有料，是一个设计作品的专业体现。之前花了四篇小文（链接在文末），讲述如何提升设计师设计作品的内在含金量和外在形式感，今天，我们将用最后的篇幅，聊聊如何给设计作品创造一个尽可能完美的终局——交互文档的细节。

千里之堤毁于蚁穴，再专业的交互设计，如果在后期交付时频繁出现细节的缺失和补充，其实还是很容易遭受研发和测试同学diss的。甚至有可能因为一个细节的疏忽，导致整体交互方案的崩盘，不得不从头再来。

如果研发过程中发生这样的设计事故，其实是非常影响团队士气和个人专业影响力的。

设计细节篇，分两个维度来阐述，一个是文档外,一个是文档内。

文档外，其实是要回归设计的初衷，很多设计师包括我自己，设计久了，总愿意把自己当作是用户的代言人，尽可能的为用户体验着想，绞尽脑汁的寻求最佳体验的设计，并以此为傲。

这如果是在产品发展的成熟期，功能相对稳定，体验同质化严重，这个时候追求的体验，寻求体验的突破是非常有意义的，可以让产品获得更多的口碑，从而带来更多的用户和收益。

但是如果是在探索期和成长期，过度的追求单一维度的体验，可能反而会成为一种产品发展的桎梏，阻碍产品的成长，而在衰退期追求的体验，则完全背离了公司作为商业组织的利益点，会显得和整个项目组格格不入。

产品生命周期与用户体验要求

所以对于探索期和衰退期的产品来说，设计师要尽可能考虑商业性和技术可行性。用最小的设计代价，快速的迭代，完成产品的目标（验证价值或解决问题）。

如果设计师在这两个阶段太揪细节，可能会因为得不到项目的支持而心灰意冷。

技术可行性和商业收益，不是我们所擅长的领域，通过前面的设计法则和用户埋点也不能准确推算，所以还需及时向技术及商务同学确认，别人家能做的产品形态，咱们家技术框架不一定支持。别人家能做的精简，可能会损害咱们家的主营业务。

涉及到这两点，除非有自上而下的旨意，否则单凭设计之力无异于蚍蜉撼树，很容易让自己费力不讨好。

文档内的交互细节，主要在于文档的完整性和阅读体验，既要面面俱到，又要清晰简洁。

面面俱到是指要尽量包含所有流程、页面及状态，避免遗漏。它体现了一个交互设计师设计思维的严谨性和设计态度。

网上有很多关于交互走查表的模板，非常的全面，但就是因为太过全面，反而让很多新人设计师望而生畏，避而远之，这就失去了交互走查表本身的意义。

我认为，交互走查表其实就是提供给设计师的一份帮助文档，大家都知道在设计的时候，提示要尽可能的简短，要适时出现，要清晰简洁，遗憾的是我看到的交互走查表往往都不满足这一条。

冗长的交互走查表，就像是冗长的帮助文档一样，把责任都推给了设计师，仿佛在说：谁让你不按照我逐条检查呢？

如果出现细节的遗漏，就变成了设计师自己的错。

谁都不想遗漏，但是后期设计时间往往真的就很紧迫，设计师除了细节的补充，可能还有其他很多任务需要做，大家只是想确认一下而已，哪有时间和精力去看那么冗长的“帮助文档”。

所以发挥一下设计师的同理心，根据二八原则，80%设计师可能遗漏的问题都只是认知走查表里20%的内容，这20%的内容也真正意义上影响我们80%的用户和体验，是设计者最为关心的。

那么，我们是不是先把这20%的设计解决好呢？这才是真正急设计师之所急，站在设计师的角度考虑问题。

所以本文精心筛选出最容易被大家所忽略，且大多数设计又必须要考虑的异常分支，为大家整理了一份《设计细节check表》，以确保主体流程的主要设计“面面俱到”。（流程设计、布局设计，以及互动设计，如果大家在前期有遵守对应的设计原则，再加上数据的支持，应该大方向都是正确的。我也希望大家尽量通过前期的理论和数据，去保证流程和整体设计的正确性，而不是要等到最后细节确认的时候，才来审视检验整体，让细节篇，真的是在完善细节。）

设计细节Check表

我把这份《设计细节check表》按照从整体到局部进行了归类：

最大的单元是指每个任务流程的检查，然后是页面单元，因为页面涉及到加载的异常分支比较多，所以单独拆出来和页面状态并列分别阐述。最后是组块单元，主要包括输入类和非输入类的组件操作及反馈。

下面我们逐一来看：

一、流程检查

流程检查主要包括三点：

1. 和其他相似流程的一致性问题

秉承一致性原则，同一个产品，能保持一致的地方，要尽可能保持一致。

在实际项目中，同一个产品，往往有多个设计师，每个设计师都负责相对独立的一大模块，偶尔就会涉及到相似功能的设计，因为是不同人在进行，所以设计出来的形态就可能不一致；

但对于用户来说，使用相似功能的人，往往可能是同一拨人，设计的不一致，体验就会有差异，不仅对于用户来说学习成本高，而且对于项目组来说同时维系两套不同的设计，成本也比较高。

2. 逆向流程标注

如果一个流程的正向流程和逆向流程是完全一致的，一般无需特别说明，但是如果返回时需要跳过某些页面或者状态快速返回，则需要进行特殊标注，否则可能会被研发同学遗漏。

3. 流程进度的保存机制

当遇到特殊情况，程序崩溃，后台杀死，断电等，进度是否能够能自动保存并恢复，如果需要，就需要考虑恢复的时机和形式。

说完流程，再来说单独的页面。谈到页面时，首先要谈的是加载状态，毕竟页面不是凭空就有的。

二、加载状态

加载状态主要要考虑以下几点：

1. 是否预加载

预加载的时机是什么时候，预加载的内容有多少？（对于用户会长时浏览的内容，一般建议预加载，预加载的内容一般会结合内容大小、浏览时长、甚至网络状态综合决定）

2. 加载前的状态

在信息未加载出来前，界面是显示空白引导，还是默认占位符，还是显示上一次的缓存内容？（一般有缓存优先显示缓存，无缓存先显示默认占位符，等内容加载完成后再进行替换）

3. 加载进度显示

是否显示加载图标，进度条，是否可以取消加载？（一般情况下等待超过0.1s，就能够被用户感知到，就建议显示加载图标，以便用户知道程序已经接收到并在响应用户的操作指令。如果等待超过1秒，就建议显示进度条，并提供取消操作，便于用户自主控制）

4. 加载机制

是全部加载，还是分布加载显示？（一般情况下，在2~3屏内的有限内容，或者完全非同类的内容，是可以一次性全部加载的，因为用户可能就是冲着某一类内容进来的，很可能会快速滑动到目标内容。

而对于同类型的图文信息，而且是内容比较多时，一般都会采取分布加载的形式，避免浪费多数用户的流量。

视频播放机制、广告图片加载等，一般还要考虑网络情况，一般WIFI情况下，因为对流量及网速的要求低，所以采用自动播放视频，自动显示图片、播放广告等，更容易被用户所接收）

5. 加载超时处理

是否自动重试加载，何时进行超时提示等。（很多产品在设计时，如果不是完全无网络，仅仅是网络信息不稳定，会尝试自动加载，以避免用户手动操作。如果自动加载超过上限，才会提示让用户稍后再试）

页面加载出来后，就要要考页面本身的状态了。

三、页面状态

需要考虑的异常页面状态主要有以下几种：

1. 无内容，或者内容被删除后的空状态。（一般会有一个默认引导图，告知结果，并附加鼓励操作的行为引导）；
2. 有内容时，且内容比较丰富时，要考虑各种内容及条数的多种组合样式，特别是极端组合样式，要检查一下看起来是否合理，是否影响整体界面样式；
3. 是否需要新功能引导。比如有新功能，希望用户尝试，或这是进行设计重构以后，功能布局发生了变化，要考虑用户是否还能找到原来的功能；
4. 页面时效性。活动类有时效性的内容，还需要考虑超过有效期后是否显示，以及如何显示，一般刚结束，都需要有一个收尾页面，便于用户查看活动结果。活动下线后可能还有一个下线不可访问页面，引导用户向其他活动，或者其他功能页面进行转移。

考虑完整体页面后，最后再来考虑一下页面内的组件状态。先来看一下输入类。

四、输入框/文本框

输入框/文本框要考虑的主要有三点：

1. 默认状态。是否有默认提示，是仅仅是填写提示，还是可以直接提交的示范内容？（现在越来越多的产品，为了减少用户的输入成本，开始在默认框中填入示范文本，考虑一下你的产品是否需要）；
2. 不可用状态，考虑是否需要；
3. 输入状态及反馈。这个要考虑的会多一点，主要包括正确/错误的实时反馈，超过输入上线时的处理方式（截断or提示）、输入非标准字段的包容性，以及输入内容是否实时保存。

最后看一下非输入类的操作组件。

五、文本/图标按钮、连接诶、可操作的卡片/列表

“文本/图标按钮、链接、可操作的卡片/列表”要考虑一下几点：

1. 默认状态。没什么好说的；
2. 悬停状态，是否需要有悬停tips提示，这个一般只有PC端才有；
3. 按下状态，也称点击态。（一般需要设置单独的视觉样式，以给用户明确的视觉反馈，正在响应用户的操作）；
4. 弹起状态，也称已点击或者已查看的状态（对于同类型的多条并列信息，通常建议添加已点击/查看状态，或者返回时，让用户明确点击的的选项，确认浏览的进度位置）；
5. 不可点击状态。说明不可点击的条件即可。

如果设计完成后，初步检查以上五项内容，基本上可以确定主题流程的主要设计内容已经面面俱到了。

文章来源：人人都是产品经理